A promised refund gets taken back. What a platform really loses in that moment.

A promise that lasts two days

On April 9, 2026, a support agent at a large European delivery platform confirms in writing a refund of 22.71 EUR. The order had been paid for and never arrived. The customer accepts immediately.

On April 11, a different agent takes the promise back. The reason given: the customer had first made contact on April 6, outside the 48-hour window. That is not true. The first report was more than three weeks old at that point.

We have the full case, with the chat history and timestamps. It is small. That is exactly what makes it useful. It shows, on a single ticket, what happens when a support system has no memory and every agent is allowed to overwrite the decision of the one before. We call this state operational decay: the processes keep running, but the company’s promises gradually stop meaning anything.

How it unfolded over three and a half weeks

March 18, 2026. Order placed, amount charged, food never arrives. GPS data shows the driver near the address. No doorbell, no photo, no signature. The platform counts a delivery as complete as soon as the driver enters a radius around the address, the so-called geofence. Nobody checks whether the customer receives anything. The system only knows “inside the radius” or “outside the radius”. The absence of an error signal counts as success.

March 19. The customer reports the problem through in-app support. This report later disappears from his history. We will come back to that.

March 19 to April 4. No reaction. The ticket system, a tool bought from a third-party vendor, sorts by age, customer category and amount. A single ticket for 22 EUR sinks to the bottom. That is not malice. It is what a system does when it is tuned for throughput rather than reliability. During these weeks the customer orders from other providers. Switching costs him nothing. The other app is already installed.

April 5. The customer reports the problem a third time. Agent A replies within minutes, politely, by name, with an apology and a question about the delivery address. The address is on the order. The reply contains no reference to the existing ticket. It would have fit any other ticket just as well.

April 7. The customer confirms the address. Agent A asks whether a refund as in-app credit would be acceptable. The customer agrees.

April 9. Agent B takes over the case without the customer being told. He grants the refund of 22.71 EUR as credit. The customer accepts in writing. From this point there is an agreement: the company has promised something and the customer has accepted it.

April 11. Agent C takes over and revokes the promise. The 48-hour reasoning is wrong twice over. First, the initial report was on March 19, not April 6. Second, the window no longer matters once a colleague has already granted the refund. Agent C apparently does not see this or is not allowed to act on it, because the rule in the system marks the denial as correct.

April 11 and 12. The customer asks twice to be escalated to a manager. Both times the escalation is promised. Both times nobody follows up. The customer initiates a chargeback through his bank, which means the bank reverses the payment. He also files a complaint with the platform’s legal and data protection departments. He prepares a complaint to the European Consumer Centre. He no longer orders from the platform.

Why the replies are so polite and so empty

The messages from Agent A and Agent C share the same pattern. Flawless language, the customer’s name, an apology, a template. No sign that anyone read the history. This is what replies look like when a language model drafts them, meaning an AI that writes text. The agent skims, clicks send and moves to the next chat.

We do not know whether that is exactly what happened here. But the pattern matches what is common in large support organisations. One agent handles several chats at once. What gets measured is time per case. Whoever actually reads an old case is slower than the colleagues. The system rewards the quick reply and penalises understanding.

Research on interruptions in knowledge work, for example by Gloria Mark at the University of California, Irvine, shows that constant switching between tasks produces speed together with stress and pressure. An agent jumping between four chats cannot absorb a case with three weeks of history in the time available. He sees ticket number, amount, rule and denial reason. He does not see his colleague’s promise.

The bitter part: the same language model that writes the polite reply could summarise the whole history in seconds and tell the agent that a promise already exists. For that, the model would need to see the history. That connection is missing in most ticket systems.

What the denial costs

The disputed amount stays at 22.71 EUR throughout. The platform’s costs grow with every round.

Three agents worked the case. The chargeback triggers bank fees and handling on the platform’s side, whatever the outcome. The complaint to the legal department ties up lawyers. Each of these items costs more than the amount in dispute. In total, our estimate is that the internal effort came to many times the refund. We do not have an exact figure. It depends on hourly rates and processes we do not know.

Then there is the customer. By his own account he spends around 500 EUR a month on delivery platforms. Even if only part of that went to this platform, a single month of orders is worth more than the refused refund. Over years, the amount at stake exceeds 22.71 EUR by orders of magnitude.

Item	Denial	Immediate refund
Refund	saved	paid out
Handling	three agents, chargeback, legal department	one agent, one action
Customer	lost	stays

So the decision is not frugal. It is expensive. It only looks frugal because the ticket system counts the refund alone and everything else lands in other departments.

Why the system still denies

The agents act correctly within their slice. Agent C sees a rule and a request. He sees neither how much the customer orders nor that a colleague has already agreed. And even if he saw both, the system gives him no authority to deviate from the rule.

That is the basic problem of rule-based support logic. It makes sure every single decision matches the rule. It does not make sure the sum of the decisions matches the company.

Trust does not decline slowly, it tips

Trust in a platform builds over many orders that simply work. That costs the platform nothing. It happens as a by-product. One broken promise is enough to end it. There is no “slightly less trust”. The customer keeps ordering or orders somewhere else.

Delivery platforms spend heavily on new customers, on vouchers, ads and referral programmes. The platform in this case has quite likely paid more to acquire this customer than it is now refusing him. To replace him, it has to pay that again and then wait months until the new customer orders as regularly as the old one did.

More agents do not make it better

The usual answer to growing support volume is more people. The case shows why that alone does not help.

In a team of three, everyone knows everyone else’s cases. In a team of three hundred, nobody knows anyone’s. Every change of agent is a handover. Every handover loses context unless the system carries it. Here there were three agents and three different decisions: A asks, B resolves, C cancels the resolution. That is not escalation. That is chance.

Beyond a certain team size the handover losses outweigh the gain in capacity. Where that line sits depends on the tool and the rules. What is certain: putting more people into the same system pushes it lower.

The alternative is not more staff but a system that holds the context. A language model with access to the full history, the customer’s value and the rules can recognise in seconds that a promise already exists. Not because it is smarter than a person. Because it is not juggling eight chats and reads the whole history at once.

The report that vanished

One detail deserves its own section. The report from March 19 has disappeared from the customer’s history in the app. He can no longer open it.

There are three possible explanations. First, automatic archiving: tickets without activity are removed from the active view after a set period. The customer no longer sees them, internal support still does. Second, a system change or update in which old tickets were not fully carried over. Third, deletion by rule, for example to save storage.

For the customer the cause does not matter. The result is the same in all three cases: the platform invokes a deadline and at the same time cannot show when the communication began. The customer can, with screenshots and confirmation emails.

Three points matter here.

Right of access. Under Article 15 GDPR the customer can request a copy of all data the company holds about him. If the March 19 report is missing from that copy, the company has to explain why. If it was deleted, there needs to be a legal basis. If it still exists, it has to appear in the response.

Proving the deadline. Whoever invokes a deadline against a customer generally has to be able to show when it started. A system that no longer shows the first report cannot do that. How a court weighs this in a specific case depends on the applicable law. The point stands: the company is arguing with data it no longer has.

Traceability. The GoBD, the German rules for keeping tax-relevant records, do not automatically cover every support ticket. The idea behind them applies to all business communication though: whatever you will later need to justify a decision, you must be able to keep.

The technical fix is simple. Every message, every ticket and every status change is appended and never deleted, known as an append-only log. The customer sees his complete history at any time. Storage for text messages costs next to nothing, even at millions of tickets a year. We build systems like this on our own servers at Hetzner in Germany, because then we decide what is stored and for how long. How data protection and such systems fit together is covered in our article on GDPR as a supposed innovation blocker.

Four causes that keep repeating

This case is not an outlier. We see the same pattern in projects again and again when support runs on a bought-in ticket system that is tuned for throughput.

No memory. Each agent sees a ticket, not a relationship. A rule, not a story. An amount, not a customer who has been ordering for years.

Rules without customer value. A 48-hour window makes sense for occasional customers with a risk of abuse. For a regular customer it makes no sense. The rule does not distinguish because it does not know the customer. The data would be there, but the decision logic has no access to it. We describe the same problem for sales data in our article on CRM systems as data graves.

No finality. If A promises and C can revoke, there is no commitment. Every promise is an interim state.

Wrong metrics. Measure support by handling time and ticket throughput and you get fast denials. An agent who denies a ticket in five minutes looks better than one who invests twenty minutes and keeps the customer. The wrong thing is being measured, much like with meetings whose cost nobody sees.

What support logic that keeps its promises looks like

Three rules are enough to make the case above impossible.

Promises are final. As soon as an agent grants a refund and the customer accepts, the case is marked as settled in the system. A downstream agent can no longer change it. Only a manager can, with a documented reason.

Customer value has a say. Before a refund is denied, the system calculates: what does this customer order per year and how likely is he to leave after a denial? If the expected loss clearly exceeds the amount, the refund is approved without further review. You set the threshold yourself.

The history stays. No automatic archiving, no deletion after a set period. The customer can see all of his communication at any time. If you keep your data transparent, you never have to rely on deadlines you cannot prove.

To be honest about it: whether you can implement these rules in your existing ticket system depends on the tool. Many allow custom rules and locks, some do not. If you run the logic yourself and use the ticket system only as a data store, you have that freedom. If you depend entirely on the vendor, you wait for the feature to arrive some day. What that dependency costs over the years is worked through in our article on the SaaS subscription trap.

What you can check in your own setup

Five questions to ask of your own support system. You do not need an engineer, just access to the system and one real case.

1. Can an agent cancel a colleague’s promise without anyone having to approve it?
2. When an agent opens a ticket, does he see how much this customer ordered in the past year?
3. Can a customer see his complete communication with you, even months later?
4. What happens technically when an agent writes “escalated to management”? Does the ticket land with a person or back in the pool?
5. What is your support team measured on? If handling time is the only number, you know what you get.

If two or more answers are uncomfortable, a closer look is worthwhile. If you want help with that, get in touch. Looking at one concrete case is often enough to see where it breaks.