The order is not lost; the trail is

Imagine a Monday morning. A customer wrote on Friday: she bought from the online store, was charged, and the package has not arrived. Customer service opens the order and sees "in process." It asks operations, which sees the merchandise picked. It asks logistics, which says the shipping instruction never reached it. It asks finance, which sees the charge made and the invoice pending. Four areas, four versions, all reasonable, and none of them can answer the simplest question in commerce: where is this order?

Meanwhile, someone with good intentions proposes what seems the prudent thing: "send it again." And that is where the real problem begins.

This article is addressed to those who run e-commerce, operations and technology in retail. It defends an idea that seems minor and is not: in omnichannel commerce the order rarely disappears; what disappears is the trail. The merchandise exists, the charge exists, the instruction went out or it did not. What is missing is a single version of the story, with evidence, that any of those areas can read and that the others accept. From there the text sustains three ideas:

1. Not knowing where an order stands costs, and the greater cost is not where it is measured. It is measured in calls; it is also paid in duplicate cancellations, refunds and trust between areas.
2. Leadership should demand three things: a single verdict per order, the evidence of what was sent and of what each system answered, and a clear indication of what not to do.
3. Blind retrying is a decision, not a reflex. Sometimes it repairs; sometimes it charges twice.

Everything that follows is generic on purpose. What is described happens to any operation that sells online and depends on more than one system, whatever its size or line of business.

Why nobody can answer quickly

Think about the path an online sales order travels. It is captured in the channel where it was bought. Payment is authorized. Inventory is set aside. The point that will fulfill it is assigned. It is prepared, shipped with the logistics operator, delivered, and in parallel it has to be invoiced. An order may cross several systems, bought in different eras, from different vendors, and built not to talk to one another any more than strictly necessary; how many and how complex varies by operation.

Each one knows its own part exactly. Payments knows whether it authorized. Inventory knows whether it set aside stock. The logistics operator's system knows whether it received the shipping instruction. It is uncommon for any of them to know the whole story, because the whole story is precisely what happens between them: at the junction where one system hands something to another and expects the other to receive it.

That is the first reason answering takes time. The answer does not live in one place. To put it together, someone has to log into several systems, ask for permissions they may not have, interpret records written by different teams and, on top of that, compare timestamps. And timestamps are their own trap: each system notes the moment in its own way, with its own time zone, its own rounding and its own idea of which instant counts. Without a common clock, the order of events misleads, and whoever reconstructs it by hand may conclude the opposite of what happened.

The second reason is more uncomfortable: there are steps that answer "done" without having done the work. A service accepts the request, returns a confirmation, and the work is left half done or not done at all. From the outside, everything looks healthy. There is no error, no alarm, no dashboard in red. The order did not visibly fail: it was silently left half done. And a silence is not investigated until someone, weeks later, asks about the money.

The third reason is the branches. An order does not only move forward; it is also canceled, partly canceled because an item was missing, returned, exchanged. Each branch drags its own paperwork along —a credit note, a refund, an inventory adjustment— and it is precisely there that there is the least scrutiny, because dashboards are usually designed for the happy path.

And the fourth is tax-related: the invoice runs in parallel with delivery, not behind it. An order may reach the customer and be left without an invoice, or the other way around. For whoever operates, they are two stories that look like one; for whoever audits, they are two stories that must match.

It is worth saying something about the most frequent diagnosis: "we need more integration." Sometimes it is true. But often the integrations exist and work; what is missing is the ability to read what they say continuously and put it on a single timeline. Connecting systems is one thing; being able to tell what happened between them is another. They are different jobs, and many operations have invested in the first long before considering the second.

What not knowing costs

Talking about cost requires care, because on this subject many figures circulate that look like data and have little provenance. It is worth starting there.

The most repeated statistic is the weight that "where is my order?" questions have within the total of customer-service contacts. On vendor blogs you find ranges from 10 to 25%, from 25 to 40% and even 50 or 60% in peak season. An analysis published in August 2026 by a shipment-tracking vendor reviewed those figures and reported that it could not locate a published study supporting them; in addition, it is rarely defined what counts as a "contact," in what channel, in what period or over what denominator [1]. It is a sensible reading, and that is why this article does not offer you a percentage for "how many calls are about this." The one that matters is that of your operation, and it can be estimated with a bounded sample: take the calls and messages from a recent period, classify them by reason and count how many are asking, at bottom, where an order stands.

Nor is there a universal figure for the cost of each contact. A frequently cited reference is a 2019 Gartner survey of customer-service leaders; according to a third-party summary that cites it (we could not open the original release), channels with an agent cost on average 8.01 U.S. dollars per contact, against about 0.10 U.S. dollars for self-service [2]. These are averages from years ago, from another market and another channel mix, and they are not validated for Mexico or for retail; they serve to give the order of magnitude —a contact handled by a person costs much more than one that resolves itself—, not to budget. Other recent compilations give ranges that vary widely depending on the unit (per contact, per ticket, per resolution) and almost none refers to an original study [3]. The practical conclusion is the same: measure your cost per contact with your payroll, your hours and your tools, and not with those of an article.

What does have independent backing is something broader: delivery matters. The Baymard Institute, which maintains a public list of reasons for purchase abandonment, reports that 20% of U.S. online shoppers who abandoned a cart did so because the delivery seemed too slow [4]. It is not a "where is my order" figure, and it is not from Mexico; it is a signal that the time and certainty of delivery weigh on the purchase decision. Whoever cannot say with certainty when an order will arrive can hardly promise it credibly.

With those caveats, where is the cost? Five places, which almost never appear together in the same report.

1. Customer service, which is the visible part. Each inquiry about a stalled order consumes a person's time. If the answer requires that person to ask another area for help, the cost multiplies: it is no longer one contact, it is two or three people pulled away from their own work. And the customer who calls again because "they told me they'd let me know" is already thinking about not buying again.

2. Duplicate cancellations. When in doubt, someone cancels the order and enters it again to "unblock" it. If payment was authorized and inventory set aside, the new order may set aside stock again, and the previous one may stay alive in some system that did not receive the cancellation. The result is merchandise committed twice, or two shipping instructions for a single purchase.

3. Refunds and credit notes. An order that was charged and not delivered ends up, sooner or later, in a refund. If a tax receipt already exists, it is worth validating with the tax and legal areas the applicable treatment before canceling, substituting or adjusting the transaction. It is administrative work that is rarely attributed to the origin —the order without a trail— and almost always charged to "adjustments."

4. Closes that do not add up. The silent failure from the previous section is discovered at the monthly close: a sale without an invoice, a refund the customer never received, a charge without a shipment. Detecting it at the close costs more than detecting it at the moment, because the person who knew what happened no longer remembers and the records have already moved.

5. The sharing out of blame. This is the cost that is not seen in any spreadsheet and the one that wears people down the most. When nobody has common evidence, each area defends its part: "on my side it went out fine." And each is right within its own system. The meeting to clear up who failed consumes hours of expensive people, and ends in agreements of the "we have to look into it" kind, which nobody looks into again. What is expensive is not the stalled order; it is the discussion without evidence that comes after.

There is a useful question for your next leadership meeting: how much time passes between an order stalling and someone being able to say, with evidence, who it depends on for it to move forward? If the answer is "it depends" or "hours," you already know where to look.

Scenario (illustrative, no client; the order is fictitious). Order EXAMPLE-ORDER-0042 was bought in the online store, with home delivery and two items. On day 1 at 10:02 the payment was authorized and the inventory set aside. That afternoon the point that would fulfill it was assigned and it was prepared. On day 2 at 18:40 the shipping instruction was sent to the logistics operator. Nobody received an error. Four days later, the customer writes. Without a trail: customer service sees "in process"; operations, "picked"; logistics states it does not have the order; finance sees the charge and the pending invoice. Calls are made, records from several systems are reviewed, each with its own clock. Within a few hours someone proposes canceling and entering it again. Whoever does so may release inventory that was already set aside and trigger a second charge that will later have to be refunded, while the original order stays alive in a system that did not find out. With a trail: the same order number produces a sheet with the verdict on top —"stalled at shipping; it falls to your operations team: the instruction was sent and the logistics operator never answered"—, the journey by stages, what was sent and what each system answered, and a final line that says what is missing, who it depends on and what is not advisable to do: do not cancel or re-enter it, because the payment is already authorized and the inventory set aside, and a new order could duplicate them. Customer service can tell the customer something concrete within minutes. Operations confirms with the logistics operator and authorizes the resend, with a record of who did it. Nobody argued about who failed: the evidence was already on the table. The difference between the two versions is not the failure, which was the same. It is what could be known about it.

What leadership should demand

When leadership perceives the problem, the usual reaction is to ask for "a dashboard." It is understandable and, on its own, insufficient. A dashboard summarizes; the question that hurts is of a different nature: this order, today, what happened to it? For that, it is worth demanding three concrete things, and refusing to consider the matter resolved until they exist.

A single verdict per order

There is a difference between having data and having a conclusion. Systems produce data: events, statuses, messages. Someone has to turn them into a sentence that says what stage the order is at, what is missing for it to move forward and who it depends on. That sentence is the verdict, and it is what should be on top, first, before any detail.

The important word is one. If customer service sees one verdict, operations another and finance a third, the original problem is intact: it just changed shape. The verdict must be the same for all the areas that are arguing; since systems can disagree, it is worth defining who validates the conclusion and to whom it is escalated when they do not match. And it must distinguish at least three situations that are not the same:

• Went out. The step was completed and requires no attention.
• Depends on someone else. What fell to your team was done and now it is a matter of waiting for a provider or another system. It asks for patience, not action.
• Action needed. Something did not advance and requires a decision by a person.

That distinction matters more than it seems. An operation where everything stalled looks equally urgent ends up attending to nothing with judgment. Telling what asks for patience from what asks for a decision is, in practice, what frees up hours.

Demand also that the verdict say who it depends on, and that this "who" can be your own team, a provider or a system. It is not an administrative detail: it is what turns the blame meeting into an assignment of work.

The evidence of what was sent and what each system answered

A verdict without evidence is an opinion with better presentation. The second demand is that, for each stage and each system involved, you can see what was sent and what was answered, side by side, on the same clock.

Why side by side? Because a frequent failure is not "the system returned an error"; it is that the answer never arrived, arrived incomplete or arrived with a "done" that did not correspond to what was asked. Only by seeing both columns can you tell an instruction that went out and was not answered from an instruction that never went out, and those two situations are fixed in completely different ways.

This evidence fulfills three functions that are worth separating:

• Operational: whoever decides the next action knows what each system did, without guessing.
• Reconciliation: finance and operations argue over the same document, not over two memories.
• Audit: months later, when someone asks why an order ended up the way it did, the answer does not have to depend on someone remembering, provided that the information is retained and protected in line with your policies and does not replace the formal records that audit, finance or compliance require.

A word of caution. An order's journey carries data about your end customer: names, addresses, contacts. A sheet that shows everything to everyone solves the operational problem and opens a privacy one. Demand from the start permissions on who sees what and criteria for what is shared outside the company, with the security and legal areas in the conversation from the beginning. This is not a later embellishment; it is part of what makes the solution usable.

And a clarification on scope: the evidence reaches as far as the connected systems reach. An honest sheet says which systems it read and which it did not. If a stage depends on a system that does not deliver information, the right thing is for the sheet to mark that gap, not to fill it with an assumption.

What NOT to do

The third demand is rarely made and can save a great deal: that next to the next action, the sheet say what is not advisable to do.

The typical case is the retry. Faced with a stalled order, the reflex is "send it again." And sometimes that is exactly right: if the shipping instruction never went out, resending it is the appropriate thing. But other times the instruction did go out and it was the destination that did not answer; resending then may produce two shipments, or a second charge, or a second inventory reservation.

This is not an intuition. Payment platforms have spent years designing for this risk. Stripe's documentation, for example, explains that in its v1 API an idempotency key allows a request to be retried without executing the same operation twice, and that those keys can be removed once they are at least 24 hours old, after which reusing the key generates a new request [5]. It is an example that every safe-retry mechanism has conditions and an expiry of its own; outside them, repeating the operation may execute it again. That window exists in a payments service that was designed for it; in a chain of heterogeneous systems, which were not necessarily designed that way, there are plenty of reasons not to assume that retrying is free.

That is why it is worth demanding three rules of conduct for your operation, whatever the tools:

1. Retry only with evidence of what happened to the first attempt. That is, with the evidence from the previous section.
2. Define, according to risk, who authorizes actions that move money or inventory and where a record is kept of who and when. Automation can suggest; a correction that can charge or release merchandise deserves, as a starting rule, human confirmation and a trail.
3. Do not treat the new order as the default correction of the previous one, unless it is known what stayed alive in each system.

If today your operation cannot meet those three rules, it is not for lack of discipline in your people; it is because the trail that would make them possible does not exist.

What a trail does not promise

It is worth being clear, so that your committee does not buy the wrong expectation.

• It does not fix badly designed processes. If the fulfillment process has a fundamental defect, seeing it clearly helps you decide, but does not correct it.
• It does not replace your systems. A good trail reads what your systems already exchange. If your underlying problem is that a system is obsolete, that is another conversation.
• It does not decide for you. It points out what is missing and what comes next; the decision to act, especially when it moves money or inventory, stays with a person.
• It reaches as far as the connected systems reach. What happens in a system that was not read is not seen; a good solution marks it instead of hiding it.
• It does not eliminate the failure; it shortens the time between the failure and its attention. Some orders will stall. The difference is how long it takes to find out and how much it costs to clear up.
• Other people's figures are not yours. Neither the percentages from blogs nor the costs per contact from another industry replace a measurement in your operation.

Five questions for your next committee

1. How long does it take today, end to end, to tell a customer where their order stands? Time five real cases from the last thirty days, from the moment the customer asks until they are answered with certainty.
2. How many areas must get involved to reconstruct a stalled order? If it is three or more, the sharing out of blame is built into the structure.
3. Is there a document that customer service and operations accept as the same truth? Or does each bring its own screenshot?
4. What is done today when in doubt: is it retried, is the order canceled and entered again, or does everyone wait? And, above all, does anyone know how many times that reflex generated a second problem?
5. Which step fails silently? That is, how many orders from the last close were discovered through a complaint from a customer or from finance, and how many through a notice from the system itself?

If two or more answers are "I don't know," there is a clear case for measuring before investing. That is good news: it means the first step does not require buying anything.

Where to start this week

Pick one order that cost you a week of emails. Just one. Ask whoever handled it to put together, on a single page, the timeline: what was sent to each system, at what time, what each one answered, and at what moment it was known that something was wrong. Then answer three questions in writing:

• How many people and how many systems were needed to put that page together?
• How long did it take?
• Was there any moment when someone proposed retrying or re-entering? With what information?

With a single order you will see clearly a part of where the trail is lost in your operation. That sheet works with any tool, or with none, and it is the best possible specification of what you need to ask for.

What Hábil does

Hábil works in the space between the systems of a retail operation: e-commerce, inventory, fulfillment, shipping and invoicing. If your assessment confirms that the trail of your orders is lost at the junctions, the proposal is described in Order traceability for retail: type in an order number and see, on a single sheet, what happened to it, what was sent and what each system answered, what is missing and who it depends on for it to move forward. The scope, the systems that are connected and the controls are reviewed against your case.

And if the problems go beyond a single order —the order model, orchestration across channels, the possible outcomes of a purchase—, the page Retail omnichannel software describes how we approach it.

The first conversation, at no cost, can start with one order. Pick one that cost you a week of emails and we will review together where the trail is lost in your operation. Write to us on WhatsApp; to protect your customers, do not share order numbers or personal data through that channel: we will agree on the channel for the case during the conversation.

Each reference carries its confidence: high (primary source read), medium (source read that cites another that could not be opened) or low (secondary compilation, only as an order of magnitude).