Skip to content
Customer Support & Commerce

The customer asks one thing. The answer depends on what the business has already done.

Support becomes operational when the right response depends on the current order, booking, entitlement or service state—not only on the words in the message.

Support decides what to tell the customer and when an exception should be escalated.
Order #10482
  1. 01
    Customer“Please cancel this.”
  2. 02
    StoreUnfulfilled
  3. 03
    WarehousePicking
  4. 04
    SupportRequest received
  5. 05
    States disagreeSafe action unknown
Example workflowCustomer
Same pattern, different businesses

One mechanism. Four recognisable moments.

Select a business to see how the same underlying failure changes shape.

E-commerce

A cancellation reaches a moving order.

The storefront and warehouse describe different realities.

See the industry workflow
  1. 01
    StoreUnfulfilled
  2. 02
    WarehousePicking
  3. 03
    ActionReview
Where it breaks / what changes

See what changes when the workflow holds together.

The message is only half the question. The live business state decides the answer.

Today

The moment loses context, time or ownership.

Support decides what to tell the customer and when an exception should be escalated.
01Request arrives
02One system checked
03Other state hidden
04Agent investigates
05Answer delayed
06Exception grows
What this family can include

Focused systems for the moments that matter.

Each pattern addresses one important handoff and keeps the final decision with your team.

01

Order-change safety

Check what is still operationally possible before changing the order.

02

Exception routing

Send the issue to the owner who can actually resolve its current state.

03

Entitlement / state checks

Put policy and customer-specific eligibility beside the request.

04

Support context

Assemble order, service and prior-conversation history for the agent.

05

Human escalation

Make irreversible or unusual actions explicit human decisions.

See the workflow details
Where it shows up

The status the customer sees is not the status the operation is in

Customer-facing systems carry a broad status — unfulfilled, booked, scheduled, open — that covers two very different realities: a job still sitting untouched in a queue, and a job that is minutes from being finished. The operating side knows the difference. The support desk usually does not, because that state lives in a warehouse system, a dispatch board, a practitioner’s diary or a carrier feed, and it reaches the desk late if it reaches it at all. So the reply goes out against the wrong picture, and the correction has to travel backwards through people.

The queue is ordered by arrival, not by what a wrong answer costs

Most support queues are a single list sorted by time. A question about a product’s material and a request to stop a parcel that is about to leave the building sit next to each other, look about the same length, and get worked in the order they landed. But one of them can be answered wrong at no cost, and the other has a closing window attached to it — a cutoff, a dispatch time, a cancellation policy, a technician already driving. Nothing in the inbox marks the difference, so the expensive one waits behind the cheap one.

The person answering has to be right about five records at once

“Can I change this, and does the price I was quoted still stand?” arrives looking like one question. Settling it properly means knowing what was bought or booked, how far along it already is, what the terms say about changes at this stage, whether the alternative is available at all, and what a colleague already promised on an earlier message. Those facts sit in different systems with different owners, and the person holding the conversation is often the newest on the desk, with a queue behind them. So they answer from the screen in front of them, and a commitment the business did not approve becomes something in writing it has to honour.

Each handoff asks the customer to start the story again

A request that cannot be settled at the desk gets passed on — to operations, to the warehouse account manager, to dispatch, to finance, to whoever owns the exception. What travels is usually a forwarded message and a one-line summary; what stays behind is the reason, the history and what the customer was already told. Each hop re-opens the question, and each hop is somewhere the request can quietly stop moving. From the customer’s side it looks like being asked the same thing by three different people, with a longer gap between each one.

Taking an answer back costs more than the request ever did

The cost of a support desk is rarely in the messages it sends. It is in the answers it has to reverse: the refund and the return label after a parcel shipped anyway, the second visit after a job was booked on the wrong information, the goodwill credit issued to settle an argument the business started by saying yes too early. Each reversal is small enough to absorb quietly and large enough to matter in aggregate, and it usually surfaces weeks later as a cost line with no name against it. The intent of the systems in this family is that those reversals become visible as they happen, and rarer because the reply went out against the real state in the first place.

What the system can handle

System support

  • Reading an order, booking or job’s current stage in the system that actually holds it
  • Recording how stale that reading is, so it is not relied on blindly
  • Classifying an inbound request by what it would change, rather than by how it was worded
  • Pulling the customer’s orders, visits, tickets and payments into one view before a reply is written
  • Checking a request against the cutoffs, policy windows and terms that apply to it
  • Flagging when the customer-facing status and the operating status disagree
  • Drafting the reply with the request’s real stage already in it
  • Keeping one record of who was told what, by whom, and when

Your team decides

  • Approving anything that cannot be undone — a recall, a refund, a cancellation, a credit
  • Deciding what the customer is promised, and in what tone
  • Granting exceptions to policy, and deciding who absorbs the cost
  • Handling escalated, angry or public complaints
  • Deciding when a request needs a phone call rather than a written reply
  • Any judgement that is clinical, contractual, legal or safety-related
  • Setting the policy the checks are written against, and changing it
Relevant work

See what exists today.

Explore related products, case studies, internal builds and clearly marked system concepts.

Start with the workflow

Have a workflow worth making dependable?

Show us what happens today. We’ll help you decide whether a focused system is worth building.

Review a Workflow