The gap between something happening and someone noticing

At 4:47 on a Friday afternoon a payment fails. The card expired three weeks ago and nobody told the customer, because nobody knew. The billing system knows. It writes a line in a table, marks the invoice unpaid, and that is the end of its involvement.

On Monday at 9:20 somebody opens the failed payments screen and finds that line sitting with eleven others. They send an email.

The failure took a fraction of a second. The response took sixty four hours.

Nothing was broken. No system went down. Every piece of software did exactly what it was built to do, which was to record the fact and wait.

The event is almost never the damage

When something goes wrong, the review afterwards studies the event. Why did the card fail. Whether we should ask for a backup card. Whether the retry schedule is right. All reasonable questions. The question that rarely gets asked is how long it sat.

That same failed payment, retried automatically four seconds after the decline, is a non event. The customer never learns it happened. No email, no awkward message, no chance to reconsider the relationship over a weekend. The identical technical failure, discovered on Monday, is a lost customer.

The failure did not change. The delay did.

This holds almost everywhere. A stock level that crosses a reorder point is harmless if something acts on it in the same minute, and expensive if it surfaces in Thursday’s report. A shipment that misses its window can be fixed before the truck leaves and cannot be fixed after. A message from your largest account is a routine question at ten past nine and a problem at four in the afternoon, and it is the same message.

Almost every organisation measures the events. Very few measure the gap.

Why the number does not exist anywhere

There is a practical reason nobody has it. The event has a timestamp in a database. The response often has one too, in a different system, or in somebody’s sent folder, or nowhere at all. The gap between them crosses the boundary between software and a person, and nothing owns that boundary. No report is built on it because no single system sees both ends. So it goes unmeasured, and unmeasured things get assumed to be fine.

Getting the number for your own business

This takes an afternoon and no tooling. Do it on paper.

Pick your five most common operational events. Not the dramatic ones. The ordinary ones that happen daily or weekly. Write each as a plain sentence. A card is declined. A shipment misses its promised date. A customer crosses their usage limit. A supplier confirms a delay. A quote request comes in through the site.

Write down when the fact first exists. Not when a person learned it. The moment it became true and got recorded somewhere in your systems. This is usually earlier than people expect.

Then write down when a response actually happened. Pull five real examples from the last month for each event. Not the policy, not the best case, not what should happen. What the timestamps say.

Be honest about nights and weekends. This is the step people skip, and it is where the number lives. If an event happens at six on a Friday evening and the first response is Monday at nine, that is sixty three hours. It is not “next business day”. Business hours accounting is how a sixty three hour gap gets recorded as one day. Use wall clock time throughout.

Note who is in the loop. If the honest answer to “who responds to this” is “whoever notices”, the gap is longer and more variable than any single example shows, and the number to write down is the worst one, not the average.

You now have five lines, each with an hour count on it. At least one of those numbers is usually a genuine surprise to the person who wrote it.

Telling the expensive gaps from the harmless ones

Not every gap costs anything, and closing all five would be wasted effort. Two tests separate them.

The first is about shape. For each event, ask what happens to the cost while it sits.

Some costs are flat. Answering in one minute and answering in one week produce the same outcome. A record filed monthly, a report someone requested with no deadline, an internal note. Leave these alone. The delay is free.

Some costs rise steadily. A customer waiting on an answer gets a little more annoyed every hour. An inventory imbalance grows. A quote request cools. Each hour costs something small, and the total is the gap multiplied by the rate.

Some costs sit at nearly zero and then jump at a specific moment. This is the shape that matters most. A failed payment costs nothing until the subscription cancels. A shipping correction is free until the truck leaves at six. A hold expires. A window closes. For these, the average response time is irrelevant. The only question is whether your response lands before the cliff or after it, and that has a yes or no answer you can check.

Start with the cliff events. The payoff is defined, and you can tell whether you got it.

The second test is about judgement. Look at what the person actually does when they finally respond. If they open a screen, confirm the situation matches a rule everyone already agrees on, and do the obvious thing, then the delay bought you nothing. It was pure waiting. If the response genuinely requires weighing something, reading a history, making a call that reasonable people could make differently, then the gap is buying you real judgement. That does not mean it should stay long. It means the goal is to get the person the full context sooner, not to remove them.

Our own Shopify apps, xupsell and xbundle, respond to what a store is doing in seconds rather than when a merchant next opens a dashboard. That came from treating the gap as the thing worth measuring in the first place.

What to do with the list

Rank the five lines by frequency multiplied by cost, not by which number is biggest. A four hour gap on something that happens two hundred times a month usually beats a sixty hour gap on something that happens twice.

Then take the top one and choose exactly one of three outcomes. Close the gap, so something responds within seconds under a rule you wrote down. Shorten it, by putting the information where a person already is instead of in a screen they have to remember to open. Or accept it, and write down that you accepted it and why.

That third option is a real answer and it is badly underused. A documented decision to wait is a completely different thing from nobody having ever looked.

Run the exercise again in three months. Gaps drift in one direction. When a team gets busy, the first thing that stretches is the response time to anything not currently on fire.

Most people do not need convincing that a faster response is better. They need to see the number. If yours surprises you, that is worth a conversation. Book a call if you want to think it through out loud.