The customer sees one promise. Your systems need to keep it.
An illustrative operating design for ecommerce and retail teams selling through websites, marketplaces and stores in the US and UAE.
Illustrative proposed operating design · Fictional records · Not a deployed customer implementation or measured result
Records
Approved product, stock and order state.
Decision
Context and permission establish what may happen.
Outcome
Accepted action, physical readiness and an accountable exception owner.
Before: one request, several incomplete answers
A customer asks whether two lamps can be collected tomorrow. The website says available. The store has four units, but one is damaged and one is already committed to a marketplace order. A second marketplace message uses an older product code. Another customer asks to change an address after a parcel was prepared. Marketing reports still include yesterday's refunded order.
No loss or productivity percentage is asserted. The visible problem is that each team has a partial answer. The owner needs a dependable promise, an accepted order and a clear exception path. The question is not whether an AI can write a convincing reply; it is whether the reply agrees with the stock and fulfilment state.
Architecture: records, authority and completion
| Component | Responsibility in the proposed design | Evidence exposed in the walkthrough |
|---|---|---|
| Product reference | Approved item, variant, pack, market copy and active version | Source record used by the customer answer |
| Order/stock authority | Current order state and the system allowed to commit stock | Reservation result, order reference and latest status |
| AI task layer | Interpret request, retrieve context, draft action and identify missing information | Structured draft with source references and uncertainty |
| Rules and permissions | Enforce commercial and action boundaries independently of prose | Allowed/held decision and named escalation route |
| Looqus specialist operation | Resolve ambiguity, failed synchronization and incomplete cases within authority | Action record, correction and completion check |
| Client decision owner | Approve exceptions beyond agreed authority | Recorded approval or rejection |
| Reconciliation | Compare order, stock, refund and reporting states | Mismatch queue with owner and resolution evidence |
The implementation must identify the authoritative system for each fact. Actual connectors, refresh frequency, hosting and permissions would be agreed during scope; this walkthrough does not represent deployed integrations.
How it runs: the two-lamp request
1. Identify the product and requested market without treating a translated phrase as an approved product match.
2. Retrieve location stock and existing commitments. Four on hand minus one damaged minus one committed leaves two available in this scenario.
3. Check collection hours, preparation capacity and the customer's requested date using that location's operating calendar.
4. Prepare the proposed reservation. The process may commit it only under agreed authority through the supported stock/order system.
5. If two requests compete, only accepted system results determine which holds stock. A stale read is not a reservation.
6. If the write times out, check status using the same operation identity before retrying. Do not create a second order to obtain certainty.
7. Ask the store to verify the physical item and preparation state. A reservation is not “ready to collect.”
8. Send the appropriate customer confirmation only after its prerequisites are met and within the approved communication rules.
9. Reconcile the channel record, authoritative reservation and store state. Looqus owns unresolved mismatches until corrected, explicitly handed over under an agreed exception, or closed with a documented limitation.
If one lamp is missing during the physical check, the proposed system does not quietly substitute a model. It holds readiness, supplies the specialist with verified alternatives and requires the customer's agreement where the offer changes. The finished job may be a confirmed alternative or a clearly communicated cancellation, not always a sale.
US/UAE differences belong in operating records
Compare local timezone, store calendar, channel/product references, currency display, language review, delivery/collection coverage and the source of approved commercial terms. UAE English/Arabic wording should use maintained product facts and qualified review for ambiguous requests. US locations likewise require location-specific hours and service coverage. Do not infer tax, privacy, return-law or marketplace obligations from the country label; use the client's approved rules and current qualified advice where needed.
No automatic cross-border fulfilment promise. Physical stock in one market is not sellable in another merely because a shared dashboard shows it. Customs, shipping eligibility and market-specific product restrictions would require a separately approved design.
Acceptance: what the process must prove
| Test case | Required outcome | Evidence that counts |
|---|---|---|
| Two available units, one request for two | Exactly one accepted reservation for two | Authoritative reservation and order references |
| Concurrent requests exceed availability | No combined accepted commitment beyond sellable units | Recorded accepted/rejected results under concurrency test |
| Same request arrives again | Existing result recovered; no duplicate order | Stable request identity and order lookup |
| Unknown product code | Held with a specific clarification request | Source mismatch and assigned resolver |
| Write response lost | Status checked before any retry | Lookup result and retained operation identity |
| Reserved item missing physically | No ready confirmation until resolved | Store discrepancy and customer decision if offer changes |
| Refund posted | Store and selected reporting basis reconcile | Refund identity, amount and date treatment |
These are proposed acceptance conditions, not passed tests. Actual testing would record human intervention as well as successful actions, separating unattended completion, specialist-assisted completion and the final business outcome.
After state: a promise with evidence and an owner
What the completed process would make visible. Every open promise has a state and owner; every accepted reservation has system evidence; every exception has a next action; every reported sale can be reconciled under a stated definition. That is the intended after-state, conditional on implementation and acceptance.
The intended evidence chain for the fictional request includes: interpreted request, approved product, sellable quantity, accepted reservation, physical readiness, customer confirmation and reconciled record.
Begin with an operating scope you can evaluate
Start with one category, one fulfilment location and a bounded channel set. Include specialist coverage, unresolved-case handling, permissions, data quality, monitoring and ongoing maintenance in the cost discussion. Count full delivery cost against completed outcomes and the actual financial consequence; an hour released is not automatically payroll saved.
Use the working guides
Decide what your first AI process must proveReconcile the reports before moving the advertising budgetKeep one stock promise across website, marketplace and store
AI does the work.
We own the outcome.
Discuss the records, decisions and specialist work needed to complete the job your business depends on.
Book a call