Expectation or Defect: Deciding Which One It Is

Monday, 14:10, at Stonebridge Insurance. Priyanka joined the claims team three weeks ago and has raised her second ticket about the claims system: "Loading a policy takes forever. Is something wrong with my computer?" Tom times it at her desk, the way the first article in this series says to. It takes nine seconds from clicking the policy number to the screen being usable, three times, nine each time. He times it on the claims lead's machine: nine. He times it on the spare: nine. He looks up the vendor's own guide, which says a policy "typically loads in under ten seconds". Priyanka's last job was at a brokerage where the equivalent screen came up in about a second. She is not wrong that nine feels like forever with a customer on the line. Nothing is broken. Something is still wrong. Tom has a sorting problem, not a repair.

An expectation ticket is one where the thing is running at its own normal speed and the normal is slower than the person hoped. A defect ticket is one where the thing is running slower than its own normal, because something has changed, filled, failed or grown. The two need different work: a defect gets fixed. An expectation gets explained, recorded and, where the normal is unacceptable, raised with whoever can change the normal. Sorting them honestly means comparing the number with the thing's own measured normal, and not with the desk's patience, the requester's hopes or the technician's mood that afternoon. This article is part of our The Vague Slowness Complaint series. This article assumes the ticket already has a number from Turning 'It's Slow' Into a Measurement. Without one the sort cannot be done honestly. And this article will keep saying so.

It covers the one test that does the sorting, the four expectations that look like defects, and the four defects that hide behind "it has always been slow". Next come the ticket where both are true, the conversation when it is an expectation, and recording the decision so it is not re-made every month. A short war story and the expectation-or-defect sheet to copy come last, in that order.

The One Test: Slower Than It Was, or Slower Than Hoped?

The whole sort comes down to one comparison: is the task slower than it was, or only slower than someone hoped? Slower than it was is a defect, because something has changed and the change can in principle be found and undone. Slower than hoped is an expectation, because nothing has changed and there is nothing to undo. There is only a normal that the person did not know about, or does not like. Every other question in this article is a way of getting at that one honestly.

"Than it was" needs a source for what it was, and there are four. The best is an earlier timing of the same task on the same machine, which exists only if a technician wrote one down last time. This is the strongest argument for the seven-line note in the first article. The second is a colleague's identical machine doing the same task today, which stands in for "what this machine should do". The third is the desk's spare laptop at the same desk, the control. The fourth is what the vendor or the application's owner says to expect, which is the weakest. That is because vendors describe the product as it runs on their own equipment on a good day. But it is still a number and not a feeling.

Where none of those exists, the honest answer is "I do not know yet". The honest action in that case is to create a normal now. Time the task on three machines and on the spare. Write all four down, and call that the normal until something better exists. The temptation is to skip this and sort by instinct, and instinct in this situation is just the technician's own expectation wearing a lab coat. A technician who thinks nine seconds is fine and a requester who thinks it is forever are having the same argument from opposite ends. And the only way out is a third party: the number from the colleague's machine, which has no opinion.

The test is applied to the task, not to the person. Priyanka's feeling about nine seconds is real and is not the thing being sorted. The thing being sorted is whether the policy screen on her machine, today, is slower than the policy screen was last month and is on the machine beside hers. It is not. So the ticket is an expectation, and the desk now owes her an explanation rather than a repair. (It may also owe the vendor a conversation, which is a different ticket and a later section.)

The Four Expectations That Look Like Defects

Four kinds of expectation arrive at the desk dressed as faults, and each has a test that takes the costume off. The first is the application that is slow for everyone by design. That is the vendor-hosted system that takes nine seconds to load a policy for every insurer in the country, because that is how it was built and how its servers are sized. The test is the spare laptop and a colleague's machine, both at the same desk, both nine seconds, and if possible the vendor's own stated figure. Nothing on the desk's side can change this number. It goes on the known-slow list. The requester is told. And the figure is kept so that the day the vendor's number gets worse, the desk can prove it.

The second is the laptop that is old, and it is the one desks most often get wrong in both directions. Age is not a defect. A five-year-old machine that opens the application in twelve seconds, exactly as it did when it was new, is doing its job. It is slower than a new machine. The requester beside a colleague with a new machine will notice. And the right answer is the refresh list rather than the fault list. The test is the earlier timing or a colleague's machine of the same age and model. If the old machine matches its own kind, it is an expectation. If it is slower than its twin, something has happened to it and it is a defect as well as old. The refresh list is where the ageing fleet becomes a case for replacement. And the last article in this series is about building that case from the tickets.

The third is the user who moved from a faster job, which is Priyanka's ticket exactly. The comparison in the requester's head is with a different organisation's equipment, software and budget. And it is a fair comparison for the requester and a useless one for the desk, because the desk cannot reach the other organisation's servers. The test is the colleague's machine and the earlier timing. The conversation afterwards has to validate the comparison without pretending to be able to act on it. "You're right that it was faster where you were. Here it takes about nine seconds for everyone, and here is why." New starters raise more of these tickets in their first month than the rest of the building raises in a year. They are the best source of honest information about what good looks like elsewhere. Write their numbers down.

The fourth is the task that grew. Examples are the spreadsheet with ten years of rows that takes a minute to recalculate, and the mailbox that has never been archived. Another is the monthly report over a table that gets bigger every month. The machine has not changed and the application has not changed. The task has. It is slower because there is more of it, and the test is to make the task smaller and time it again. Examples are the report over one month instead of ten years, or a copy of the spreadsheet with the old years removed. If the smaller task is fast, the task is the cause. The fix belongs to whoever owns the data, usually the requester or their department. And the desk's job is to show the number and open the archiving conversation, the one the mailbox article in the e-mail series has for its own case. Nobody has ever been pleased to hear that the spreadsheet is the problem. It is still the spreadsheet.

The Four Defects That Hide Behind "It Has Always Been Slow"

The sort can fail the other way, and it fails there more quietly. A defect gets filed as an expectation because somebody said "it has always been like that" and nobody checked. "Always" is the least reliable word in a slowness ticket. It means "for as long as I have been here", or "for as long as I can remember", or "since the last time I complained and was told it was normal". Each of those has a start date, and the start date is often the date something changed.

The first hidden defect is the disk that filled. A machine with a nearly full disk gets slower gradually, over months, so that no single day feels like the day it broke. By the time it is unbearable the requester has normalised it. The test is the twin machine. The same model with a disk that is half empty opens the application in a third of the time. The second is the agent that changed. A security tool, a management tool or a backup client was updated or reconfigured. It now does more work in the background than it used to. The tell is "since when", if anyone asks it, and the twin machine that has not had the change yet. These two causes, and the others that live inside the machine, are the subject of the third article in this series, on the slow computer. It covers them in the order they are cheapest to check.

The third is the server that is quietly starving. An application was fast when it had the server to itself. It has slowed as the server took on other jobs, or as its own database grew past what its memory could hold. Every user sees it, so it looks like an application that is slow by design. And the only way to tell the two apart is a timing from before, or the application owner's own monitoring. The fourth is the normal that drifted. A task took four seconds, then six, then nine over two years, each step too small to notice. The test is the earlier timing, which is why timings are written down even for expectation tickets. An expectation can become a defect without anyone announcing it, and a desk with no history will never see the step.

The rule for "always" is therefore a question, not an acceptance: "always since when, and compared with what?" If the requester started eight months ago, the desk looks for a timing or a colleague from before that. If nobody has one, the desk creates the normal today and sorts the ticket as an expectation provisionally, with a line in the note saying so. The desk re-sorts it the moment an earlier number turns up. Provisional is an honest word. "No fault found" is not, and a later section is about why.

When Both Are True

Some tickets are an expectation and a defect at once. These are the ones that go wrong when the desk fixes the defect and says nothing about the expectation. The old laptop with the full disk is the classic. The disk is cleared. The stopwatch goes from forty seconds to fourteen. And the requester, who had hoped for the four seconds their colleague's new machine manages, reports that the fix "didn't really work". The desk did good work and got a complaint for it, because fourteen was never going to feel like success to someone who had been promised nothing in particular.

The order is: sort first, tell the requester the expectation, then fix the defect. "Your machine has a nearly full disk, which is slowing it, and I'll clear that today; it's also one of the older models, so even cleared it will open the application in about fifteen seconds rather than the four Sam's does, and it's on the list to be replaced in the next round." Now fourteen seconds is a win, because the requester was told what the target was before the stopwatch ran. Told afterwards, the same sentence sounds like an excuse.

Both-true tickets are also where the desk learns the most about the fleet. A machine that is both old and full is a machine the refresh list should have reached already. An application that is both slow by design and running on a starving server is two conversations with two owners. Record both halves separately in the note, because the trend in each is a different signal. The defects tell the desk what to fix. The expectations tell it what to buy or renegotiate.

The Conversation When It Is an Expectation

Telling someone that the slow thing is normal is the hardest sentence in this series, and most of the ways it goes wrong are ways of avoiding saying it. "Working as designed" says it in the vendor's words, which is to say in nobody's. "No fault found" says that the desk looked and then stopped looking. "That's just how it is" says it without the why. Each of them ends the ticket and teaches the requester not to raise the next one. That feels like a win on the queue and is a loss on the fleet. The requester who stops reporting is the one who would have noticed the drift.

The sentence that works has three parts: what it does, what it is sized for, and what the options are. "Loading a policy takes about nine seconds here, for everyone; it's a hosted system and that's the speed the vendor runs it at for all their customers; the options are to raise it with the vendor through our account manager, which I'll do and which may take a while, and in the meantime to open the next policy while the customer is still giving you their details, which the claims lead says is what she does." Three parts, no "design", no "fault", and the requester leaves with the normal, the reason and something to do. The format for the proactive update, including the honest estimate when the vendor conversation is going to take months, belongs to Setting Expectations at the Desk Level. The slowness version is the same shape with a number in it.

Validate the comparison before explaining the normal. Priyanka was right that the brokerage's system was faster. A reply that skips straight to "nine seconds is normal here" tells her that her experience is being overruled by a figure. "You're right, that is slower than you're used to" costs one sentence and changes the rest of the conversation. The reply itself, and the harder cases where the number does not persuade, are the subject of Closing the Perception Gap. Here it is enough to say that the expectation conversation is a conversation and not a verdict.

The expectation ticket also deserves a real resolution, which means it is resolved with the explanation written in it, not closed with a code. If the requester replies to say the explanation does not match what they see, that reply should reopen the ticket. In QuerySolv a requester's reply to a resolved ticket does exactly that, which is the right behaviour here. An expectation the requester disputes with a new observation is a ticket that may have been sorted wrong. Most tools can be set to behave the same way. Check yours, because the alternative is a disputed expectation that quietly becomes a second ticket with the word "still" in it.

Recording the Decision

An expectation sorted once and recorded nowhere is sorted again next month by a different technician, who may sort it differently. The decision goes in two places. The first is the ticket, as an internal note: the number, the comparison, the sort and the explanation given, one line each. The second is the known-slow list, a short article in the knowledge base. It names each thing that is slow by design or by age, the number to expect, the reason, and what has been done about it. The idea is a cousin of the known-error list in the problem management series, in Known Errors and Workarounds. And it does the same job. It stops the desk rediscovering the same fact and lets a technician answer the next ticket in a minute with a link.

Make the known-slow list visible to requesters, not only to the desk. A requester can read "the claims system loads a policy in about nine seconds. This is the vendor's speed, raised with them, and the workaround is to open the next policy during the call". A requester who can read that before raising a ticket often does not raise it. And the one who does arrives already knowing the normal, which turns the conversation into a check rather than an argument. If you run QuerySolv, a knowledge base article can be visible to everyone or to agents only. The known-slow list belongs in the first kind. Whatever tool you use, the test is whether a requester can find it without asking.

Tag the ticket so the sort can be counted. Use whatever the tool offers: a category, a tag, a word in the title or a field on the form. Mark expectation tickets as expectations and defect tickets by their cause, because the count of each is a different signal. A rising count of defects says something is breaking. A rising count of expectations says the fleet is ageing, the vendor is slipping or the data has outgrown its home. And each of those is a case to be made with numbers, which is where the last article in this series goes. A desk that closes both kinds as "slow, fixed" has thrown the signal away and kept the noise.

A Short War Story: The Booking Screen at Fairhaven Hotels

At Fairhaven Hotels, a group of six hotels with a desk of two, a technician called Jonas took three tickets in a month from Beatrice. The new revenue manager said the booking system was unusably slow. By the third ticket he had replaced her laptop with the best machine in the spares cupboard. He had spent six hours moving her profile across and told her it should be much better now. The booking system's rates screen took twenty-two seconds to load on the new laptop. That was what it had taken on the old one and what it took on the general manager's machine and at the front desk of every hotel. That was because the system was hosted by its vendor and that was the speed the vendor ran it at. The previous revenue manager had learned to open the rates screen before making coffee and had stopped mentioning it two years earlier. The desk had taken that as the problem going away. Beatrice, who had come from a chain whose system took three seconds, had been told none of this. Her fourth ticket asked, reasonably, why the new laptop had made no difference. The cost was six hours and a laptop that had been earmarked for the finance lead. It also cost the revenue manager's confidence in the desk, which took most of a year to recover. Sorting the ticket before fixing it would have taken fifteen minutes with the spare and a stopwatch, and the fix would have been a sentence.

The Expectation-or-Defect Sheet

The sheet below is filled in once the ticket has a number, and it takes about five minutes. Section A restates the number and finds the normal. B is the comparison. C is the sort with the four expectations and the four hidden defects as prompts. D is the conversation and the record. The sort line at the bottom of C is the one that goes into the ticket's note word for word. A technician reading the ticket in a year should be able to see which comparison the sort rested on and whether it was provisional.

EXPECTATION OR DEFECT — THE SORTING SHEET
Ticket: ________   Task: ______________________   Number from intake: ____ s   Device: ______________

A. THE NORMAL (what this task should take, from the best source available)
   Earlier timing, same machine, same task: ____ s   on: ________   by: __________
   Twin machine (same model, same age, same task): ____ s   whose: ______________
   Spare laptop at the same desk: ____ s
   Vendor's or owner's stated figure: ____ s   source: ______________
   No source available: normal created today from ____ machines: ____ s   sort is PROVISIONAL

B. THE COMPARISON
   Slower than it was (earlier timing or twin is faster) ............ yes / no / unknown
   Slower than hoped only (matches earlier timing and twin) ......... yes / no
   A smaller version of the task is fast (narrower range, fewer rows) yes / no / not tried
   Since when, per the requester: ______________   What changed then: ______________

C. THE SORT
   Expectation, because:
     [ ] slow for everyone by design (hosted or vendor speed)
     [ ] the machine is old and matches its own kind
     [ ] the comparison is with a previous employer's system
     [ ] the task has grown (data, rows, mailbox, date range)
   Defect, because:
     [ ] slower than its twin or its earlier timing
     [ ] the disk is nearly full / an agent changed / the server is shared or starving
     [ ] the normal has drifted: earlier timing ____ s, today ____ s
   Both: defect to fix: ______________   expectation to explain: ______________
   SORT LINE FOR THE NOTE: "____ s today vs ____ s [twin / earlier / spare / vendor];
     sorted as [expectation / defect / both]; [final / provisional]"

D. THE CONVERSATION AND THE RECORD
   Told the requester BEFORE any fix: what it does ___  what it is sized for ___  the options ___
   Validated the requester's comparison in one sentence .............. [ ]
   Expectation added to the known-slow list, visible to requesters ... [ ]
   Vendor or owner conversation opened, with the number .............. [ ]   ref: ________
   Refresh list updated, if the machine is old ....................... [ ]
   Ticket tagged: expectation / defect: ____________   cause: ______________

Tom filled the sheet at Priyanka's desk in the time it took her to finish a call. Section A had three nines and the vendor's "under ten". Section C ticked the first expectation box and the third. Section D got a sentence that began "you're right, that is slower than you're used to" and ended with the claims lead's trick of opening the next policy during the call. The known-slow list gained its fourth entry. The vendor conversation is still open, which Tom had told her it would be. She has not raised a third ticket, which is not the same as being satisfied, but is the honest version of it.

Frequently Asked Questions