Closing the Perception Gap: When Faster Does Not Feel Faster

Friday, 11:45, at Bluewater Bank. Leo has just finished the best piece of work he has done all month. Graham's desktop in branch operations took four minutes and ten seconds from the power button to a usable screen on Monday. It now takes thirty-eight seconds, because the spinning disk that had been in it for six years is on the bench. A solid-state drive is in its place. Leo timed it three times, wrote the before and the after in the ticket, resolved it with a friendly note and went for coffee. The reply is waiting when he gets back. "Thanks Leo, appreciate it. Still feels a bit slow to be honest." Leo reads it twice. The stopwatch is on the desk beside him, and it has not changed its mind.

The perception gap is the distance between what the measurement says and what the person feels, and it runs in both directions. A machine can be within its normal and feel broken. A fix can cut a number by a factor of six and not be felt. Closing the gap is a communication job, done with the number, done kindly, and done before the user has made up their mind rather than after. It is not a job of persuading people that they are wrong, because about the feeling they are not. It is a job of putting the number and the feeling in the same room and letting them explain each other. This article is part of our The Vague Slowness Complaint series, and it assumes a number already exists from the first article. It is about the calm, unconvinced user. When the user is angry rather than unconvinced, the opening minute belongs to The First Sixty Seconds in the frustrated users series. This article picks up afterwards.

It covers why the gap exists, showing the user the measurement, and the honest "this is normal". Next come the improvement that cannot be felt and the status page idea in plain words. It covers the user who will never be satisfied, and the kind boundary. It ends with replying in writing, a short war story, and the perception-gap reply to copy, in that order.

Why the Gap Exists

People do not experience time; they experience attention, and a wait they are watching is longer than a wait they are not. Thirty-eight seconds spent looking at a blank screen with nothing to do is a long time. Thirty-eight seconds spent reading an e-mail on a phone while the machine starts is nothing, and the same person will report the two differently on the same morning. The feeling in the ticket is a true report of attention. It is not a measurement of time, and the first mistake a desk makes is to treat it as one and argue with it.

Variation is felt more than the average. In my experience a task that takes five seconds every time annoys nobody. In my experience a task that takes two seconds most days and twenty on Thursdays gets a ticket, even though its average is lower. The user remembers the Thursday. The desk, timing the task on a Tuesday, gets two seconds and a puzzled expression. Neither is lying, and the stopwatch resolves it only if it is used on a Thursday, which is why the first article asks "when" before "how long".

The blank screen is the worst wait of all, because it carries no information. A progress bar, a spinning indicator, a line that says "loading your profile" all tell the person that something is happening. A grey screen and a cursor tell them nothing, and nothing is interpreted as broken. Graham's thirty-eight seconds included twenty of blank screen while a sign-in script ran. Twenty seconds of blank screen feels longer than four minutes of visible progress. The desk cannot always change the screen. It can always explain what the screen is doing, and the explanation shortens the wait without touching the number.

Comparisons leak in from everywhere. The phone in the person's pocket opens everything instantly. The laptop at home, bought last year for a game, starts in ten seconds. The colleague across the desk got a new machine in the spring. A requester who says "it's slow" is comparing with something. And the something is rarely the same machine last month; it is whichever faster thing they used most recently. The feeling is honest. The comparison is just not the one the desk can act on, and the second article in this series is about sorting that out.

Showing the User the Measurement

The number closes the gap only if the user holds it. Holding it means watching the stopwatch run on their own task at their own desk, not reading a figure in a reply. Put the phone on the desk, let them press start, let them do the task the way they do it, let them press stop. Then the before and the after, side by side, in their task: "on Monday that took four minutes ten; it now takes thirty-eight seconds, and you just timed it." A number the requester produced is not the desk's opinion. It is theirs, and people argue with their own numbers far less than with other people's.

Show one number, not a page of them. The temptation after a good fix is to send the three before-timings, the three after-timings, the disk figures and the start-up list. And the effect of all that on a requester is that they skim it, find the one line that still sounds slow, and reply about that. One task, one before, one after, in a sentence, and the rest in the internal note where the next technician will want it. Never write "as you can see". If they could see it, they would not have written the ticket.

Show it in the task they complained about, not in the one that improved most. A machine that starts five times faster but still takes nine seconds to open the one application the user lives in has, from the user's chair, barely changed. And the desk that reports the start-up figure is reporting its own success rather than the user's experience. Time the application too, and if that number did not move, say so and say why. Usually, that is because the application is the subject of a different conversation, with its owner, that the desk has already started. Honesty about the number that did not move buys more trust than the number that did.

The Honest "This Is Normal"

The hardest reply in the series is the one that says the slow thing is not broken. The shape of it is the one from Expectation or Defect: what it does, what it is sized for, what the options are, with the requester's comparison validated in the first sentence. "You're right that it's slower than the laptop you had at home; this model opens the application in about nine seconds for everyone who has one, which is what it was bought to do; it's on the list for replacement in the next round, and in the meantime the thing that helps most is leaving the application open between calls." Four clauses, one number, no "design", no "fault", and the requester knows exactly where they stand and what to do.

Say it in person or by phone the first time, and in writing afterwards. "This is normal" in an e-mail, with no voice behind it, reads as "go away", however carefully it is drafted. The same sentence said across a desk, with the stopwatch on the table and the twin machine's number beside it, is a conversation between two people looking at the same fact. The written version then confirms what was said. That gives the requester something to refer to and puts it in the ticket for the desk. The written version alone is a gamble, and the desk usually loses it.

Never close an expectation ticket with a code. "No fault found", "working as designed" and "closed, no action" are three ways of saying that the desk looked, found the user's experience uninteresting, and stopped. They also teach people not to raise the next ticket, which the desk will mistake for the problem going away. An expectation ticket is resolved with the explanation written in it and the requester told what the normal is and why. The thing is added to the known-slow list so that the next requester can read it before they write. If the requester replies to the resolving message to say it is still not right, that reply should reopen the ticket. In QuerySolv a requester's reply to a resolved ticket does reopen it, as it does in many tools. That is the right behaviour here, because a perception gap is not closed by the desk declaring it closed.

The Improvement That Cannot Be Felt

Some improvements are real, measured and invisible. And the desk that does not announce them has, as far as the building is concerned, done nothing. A search that drops from two and a half seconds to one and a half has been improved by the better part of half. Nobody will feel it, because a second is below what attention notices in a task that was never painful. A server upgrade that takes every task on an application down by a third produces the same silence. The trend shows it; the tickets stop. The people who stopped raising them have no idea why, and will tell the operations director next quarter that nothing has been done about the slow system.

Tell people before they look. An improvement announced with its number, "the parts search took about four seconds and now takes about one; you may not notice it, but it adds up to a couple of minutes a day for the people who use it most", is an improvement that exists. The same change announced with no number, "we've made some performance improvements", is an invitation to reply "I haven't noticed any". And the change not announced at all is credited to nobody and remembered by nobody, which is the war story later in this article.

Keep the announcement short and the claim exact. One task, one before, one after, who it affects, and nothing about how hard it was. People do not care how hard it was. They care whether the thing they do forty times a day got quicker. The honest answer, for an improvement they cannot feel, is "a little, and here is the number". A desk that over-claims an invisible improvement loses the credibility it will need for the next visible one, which will be judged against the claim and not against the stopwatch.

The Status Page Idea in Plain Words

A status page is one place, visible to everyone, that says which services are known to be slow or down right now. It says what is being done, and when it was last updated. Large organisations run a dedicated one. A small desk can do the same job with a knowledge base article that everyone can read. Or it can use a pinned message in the chat tool, or a banner on the request form. The job is the same at any size. A person who wonders whether the slowness is just them can find out in ten seconds without raising a ticket. The known-slow list from the second article in this series lives on the status page, beside the current incidents. So "the claims system takes about nine seconds to load a policy" and "the parts catalogue is slow this morning while the vendor works on it" are read in the same place.

The honest timestamp is the whole value. A status page that says "all systems operating normally" and was last touched in the spring is worse than no page, because the first person who finds it wrong will never trust it again. A line that says "updated at 09:40, next update by 11:00" is believed even when the news is bad. Give the page an owner and update it at a fixed cadence during anything that affects more than a handful of people. And put the last-updated time at the top in large type. The build, the channels and the cadence are the subject of A Status Page for a Small Organisation in the outage communication series. Here the point is only what the page does for the perception gap. It tells people that the slowness is known, shared and being worked on, before they write "is it just me?" in a ticket.

Where to keep it is a smaller decision than it looks. If you run QuerySolv, a knowledge base article can be visible to everyone rather than to agents only. In that case, the known-slow list and the current notices belong in that kind of article where any requester can find them from the portal. In any tool, the test is whether a person who has never raised a ticket can reach the page in two clicks. A page the desk can find and the users cannot is a desk note with ambitions.

The User Who Will Never Be Satisfied

Every desk has one person for whom no number will do. And the kind boundary is drawn around what the desk will do, not around the person. The desk will measure every slowness ticket they raise, fix every defect it finds, and record every expectation honestly. It will put their machine on the refresh list where it belongs and tell them where it sits. It will raise their application with its owner with the evidence attached. The desk will not replace a working machine every quarter, disable the security agent, or buy a faster application for one person. It says so plainly and once, in writing, with the reasons. Everything inside the boundary is done cheerfully and every time. Everything outside it is a no with an alternative, which is a skill the saying-no series teaches in Offering an Alternative Instead of a Wall.

Check first whether they are right about something small. The person who raises a slowness ticket every month is annoying in the way a smoke alarm is annoying. Some of them are the smoke alarm. They are the one who notices the drift from four seconds to nine that everyone else absorbed, or the Thursday that the desk never timed. Before deciding someone is never satisfied, time their complaint on the day and at the hour they complain about, once, properly. I have been wrong about this more than once, and the stopwatch was the thing that told me.

When the pattern is real, write it down and bring the manager in gently. The ticket history, with its timings and its expectation conversations, is the record. A short note to the requester's manager turns a private argument into a shared understanding. It says "here is what we have measured and done, here is what we will keep doing, and here is what we have said we will not do". Most managers, shown the numbers, back the desk and have a quieter word of their own. Never mock the person, in the ticket or in the team chat, and never let the boundary become a reason to measure their tickets less carefully. The boundary is what lets the desk keep being kind.

Replying in Writing

The written reply after a slowness ticket has four parts, in order: what was measured, what it means, what changed or what will not, and what to do next time. "I timed the start-up three times before and after: it took about four minutes on Monday and takes about forty seconds now, which you timed yourself this morning. The old spinning disk was the cause and the new drive has fixed it. The twenty seconds of blank screen after sign-in is the branch sign-in script running, which is the same on every machine in the branch; I've raised with the infrastructure team whether it can show a message while it runs. If the start-up goes back over a minute, reply to this ticket and I'll come and time it again." Four parts, a number in each of the first three, and an invitation in the last.

The invitation matters. A reply that ends "please let us know if you have any further issues" ends the conversation. A reply that names the number to watch for and says what to do if it appears keeps the requester inside the measurement. They now know what slow means, in seconds, for this task. And they will time it before they write, which is the moment the perception gap begins to close on its own. The reply template at the end of this article has the four parts as a form, with the three variants a slowness ticket needs. Those are after a fix, when it is normal, and when the improvement is one they will not feel.

A Short War Story: The Invisible Upgrade at Ironbridge Tooling

At Ironbridge Tooling, a technician called Nadia and her colleague gave up a weekend to move the order-processing database onto faster storage. That followed a month of tickets saying the system was slow. On the Monday every task in it was between a third and a half quicker on the stopwatch. The numbers were written in the change record and nowhere else. Nobody noticed. The tickets stopped, which the desk took as success. The people who had raised them, finding the system merely slow instead of painful, got on with their work. Three weeks later the operations director asked in the monthly meeting when IT was going to do something about the order system. The finance lead agreed that it had been slow for months. Nadia, who had the before-and-after figures in a folder, discovered that having them was not the same as anyone knowing. The cost was a weekend's credit lost and a budget conversation that went worse than it should have. It included a desk that was asked to justify a fix it had already made. An improvement that is not announced with its number has, as far as the building is concerned, not happened.

The Perception-Gap Reply

The template below is the written reply for a slowness ticket, in three variants that share the same four parts. They are what was measured, what it means, what changed or will not, and what to do next time. Variant A follows a fix and carries the before and after. B is the honest "this is normal", with the requester's comparison validated first. C announces an improvement the requester will not feel. Each is five or six sentences; fill the blanks with the numbers from the intake card and nothing else. And send it after the conversation, not instead of it.

THE PERCEPTION-GAP REPLY — THREE VARIANTS, FOUR PARTS EACH
Ticket: ________   Task: ______________________   Before: ____ s   After: ____ s   Normal: ____ s

A. AFTER A FIX
   1. What was measured:  "I timed ______________ three times before and after. On ________ it took
      about ____ seconds; it now takes about ____ seconds, and you timed it yourself at ______."
   2. What it means:      "The cause was ______________, and that is fixed."
   3. What has not changed: "______________ still takes about ____ seconds, which is the same on every
      ______________, because ______________. I have raised that with ______________."
   4. Next time:          "If ______________ goes back over ____ seconds, reply to this ticket and
      I will come and time it again."

B. WHEN IT IS NORMAL
   1. The comparison, validated: "You're right that this is slower than ______________."
   2. What was measured:  "______________ takes about ____ seconds on your machine, ____ on the
      machine beside yours and ____ on our spare; that is the speed it runs at for everyone."
   3. What it is sized for, and the options: "It is ______________, which was bought/chosen for
      ______________. The options are ______________, which I have started, and in the meantime
      ______________, which the people who use it most find helps."
   4. Next time:          "This is on the known-slow list at ______________. If it goes above
      ____ seconds, reply here, because that would be a change and I would want to see it."

C. AN IMPROVEMENT YOU MAY NOT FEEL
   1. What changed:       "On ________ we ______________."
   2. What was measured:  "______________ took about ____ seconds and now takes about ____."
   3. What it means:      "You may not notice it, because ____ seconds is a small change on any one
      go; it adds up to about ______ a day for the people who use it most."
   4. Next time:          "If anything feels slower than before, reply here with the task and
      roughly how long it took, and I will time it with you."

Leo used variant A, after walking over with the stopwatch and letting Graham time the start-up himself. That came out at thirty-eight seconds and a slightly surprised expression. Then he explained the twenty seconds of blank screen, which Graham had been counting as "the computer not working". It was the branch sign-in script doing its job. Graham's next reply was two words long, and the second word was "thanks". The stopwatch had been right all along; it had just needed somebody to hold it.

Frequently Asked Questions