Protecting the Schedule: Buffers, Appointments and Backing

Monday, 09:28, at the Bellweather Logistics depot. Sofia has four visits in the desk's shared calendar today, each with a ticket number in the title. She has the dispatch office at half nine for a scanner cradle, and the warehouse mezzanine at half ten for the label PC. Then come HR at half eleven for a new starter's laptop handover, and the transport office at two. Between each pair there is a fifteen-minute gap that she did not put there by accident. At 09:52 the cradle is swapped and tested, and the note is written. Greg, the dispatch supervisor, has produced three further things: a monitor arm, a shortcut that vanished, and "the new lad's login". Sofia logs all three from her phone, reads the numbers out, and says the sentence she says every day: "I'm due on the mezzanine at half ten, so these will come through the queue." Greg says "fair enough". At 09:58 she is walking. At 10:30 she is on the mezzanine. The label PC, which stops a packing line when it fails, is being looked at when the packing line was told it would be.

The visit schedule is the plan for a technician's desk-side visits across a day: which ticket, where, when it starts, when it ends, and the gap before the next one. Buffer time is that gap, held deliberately empty. It is what makes the rest of this series possible, because capturing an add-on takes thirty seconds that have to come from somewhere. A day with no gaps has nowhere to take them from. This article is part of our While You're Here series. This article is about the schedule as a thing the desk protects on purpose, rather than a hope that visits will be short.

This article covers what the visit calendar is and is not, then sizing a visit honestly. Next come buffer time and what it absorbs, and the next appointment as the honest reason. We cover saying the constraint at the start of the visit, not the end, then the manager's backing when a user complains. We finish with the calendar and the queue, a short war story, and the visit schedule to copy.

What the Visit Calendar Is, and Is Not

The visit calendar is a shared calendar, usually the one the team already has, with one entry per desk-side visit. Each entry carries four things in its title: the ticket number, the location, and the planned start and end. "4471 dispatch office 09:30-10:00" is a complete entry. Anyone on the desk can open the calendar and see where everyone is and when they will be back. That is the same information the desk lead used to get by shouting across the room and the user used to get by not getting it at all. The calendar is not clever and does not need to be; a wall planner would do. The point is that the plan exists somewhere other than the technician's head.

The calendar is not a second queue, and this is the mistake that breaks it. Visits come from tickets. The queue decides which tickets need a visit at all, based on the ticket and its priority; the calendar decides only when the visit happens. A user who asks for "someone to come and look" gets a ticket, and the ticket gets triaged. If a visit is the right response, the visit gets a slot and the user gets the time. A desk that lets users book visits directly, or lets technicians add visits to the calendar without a ticket, has built a second intake with no triage on it. That calendar fills with visits for things a remote session would have fixed in five minutes.

Each calendar entry points at its ticket and each ticket points at its entry. The entry has the ticket number in the title; the ticket has a note saying "visit booked, Monday 09:30, user told". That is the whole of the integration. It means that when the user asks on Friday "is someone still coming on Monday", whoever answers can see the answer in the ticket. If you run QuerySolv, the ticket's event history will show the note being added and the time. In that setup, the question "did anyone tell her" is a glance rather than a hunt. The same is true of any tool that keeps a full history on the ticket.

Sizing a Visit Honestly

A visit is sized from its finish line, not from its symptom. The finish line comes from the visit card the first article in this series describes. "Scanner cradle not charging" is a symptom; "cradle replaced, scanner charges, two test scans complete" is a finish line. A technician who has swapped a cradle before can put a time on it: twenty minutes, say, with a couple extra for the walk. Sizing from the finish line forces the question "what will I actually do there" before the slot is booked. That is also the question that reveals the visit that does not need to happen.

Use ranges from your own desk's history, not from hope, and round up. A fictional desk might find, from a few months of visit notes, that a straight swap of a known part takes twenty to thirty minutes including the walk. It might find that a diagnosis of an unknown fault takes thirty to forty-five with the real risk of needing a second visit. It might find that a laptop handover with a user who has questions takes forty-five to sixty. Those are the desk's numbers and yours will differ. The point is that they come from what visits took, not from what they ought to take. A visit sized at the optimistic end is a visit that starts the next one late before any add-on has arrived.

Technicians size visits short for a kind reason, which is that a short visit sounds like good service when the time is being offered. "I'll be there at half nine and it'll take twenty minutes" is a nicer sentence than "forty minutes", and the technician who says twenty believes it. The user, though, does not remember the twenty; they remember that the technician was still there at ten past ten and that the next person's phone was ringing. Size it honestly, say the honest number, and finish early. Nobody has ever complained that the technician left before they said they would.

Buffer Time and What It Absorbs

A buffer is ten to fifteen minutes held empty between the planned end of one visit and the planned start of the next. It is not spare time. It has a job, and the job has five parts. There is the walk, which is longer than anyone thinks in a building with a lift. There is the note, written at the desk before leaving, which the walk is not a substitute for. There is the capture of whatever add-ons arrived, at thirty seconds each. There is the single genuinely two-minute fix the two-minute rule permits. And there is the slippage of the visit itself, because a twenty-minute swap sometimes takes twenty-six. Add those up on an ordinary visit and the buffer is used. On a visit with four add-ons and a lift that is somewhere else, it is used twice.

The buffer is the first thing a busy desk removes and the last thing it should. The argument for removing it is arithmetic: four visits with fifteen-minute buffers is an hour "lost", and an hour is another visit or two. The arithmetic ignores what the buffer was absorbing, which does not disappear when the buffer does. That work moves into the next visit's start time, and then the next. So the day's fourth user waits for the sum of everything the first three absorbed. The table below shows the same four visits with and without buffers, on a day where each visit runs eight minutes over and produces two add-ons. The numbers are invented for the example, and they are also exactly what happens.

Notice that the day with buffers finished its morning visits later and still arrived on time at every one, because the plan told the truth about how long things take. Notice too that the buffer is not filled with other work. A technician who sees fifteen empty minutes and books a "quick" visit into them has turned the buffer into a fifth visit with no buffer of its own. The day is back where it started. The buffer is for the five things above and for standing still for a minute, which, on a desk, is also a thing with a job. The series on the interruption load says why in more detail than fits here.

The Next Appointment as the Honest Reason

The reason a technician gives for not doing the add-on is the next appointment. It works because it is true, specific and about another person. "I'm due on the mezzanine at half ten" is a fact the user can check against the clock. It names a place. It implies a person on the mezzanine who was promised a time. Users, in my experience, do not want to be the reason someone else was let down any more than the technician does. Compare it with "I'm not able to do that in this visit", which is true, vague and about a policy, and which invites the question "why not" that the appointment never does.

The next appointment is also a reason the technician can give without defending it, which matters because the technician should not be defending the desk's rules alone at a user's desk. A rule is argued with. An appointment is simply there. The user who says "can't they wait five minutes" has to be told, kindly, that they could, and that the person after them could too. They also need to be told that this is how a day arrives at four o'clock with someone's appointment missed altogether. Most users, hearing it put that way, hear the version of themselves at four o'clock and stop pushing. The appointment is doing the work the technician's authority cannot.

Two things the reason is not. It is not a claim that the next user is more important; it is a statement about order. If the user asks "who's more important than me", the answer is "nobody, which is why I'm going when I said I would". And the reason is not an estimate of when the add-on will be done, which the technician cannot see from a desk and should not guess at. The honest shape of that promise, naming the next step rather than the finish, is in Setting Expectations at the Desk Level. It is the same promise whether the request arrived by e-mail or at the technician's elbow.

Saying the Constraint at the Start

The constraint is said when the technician arrives, not when they are trying to leave, and the difference is the difference between a frame and an excuse. "Morning, I'm here for the cradle, ticket 4471; I've got until about ten o'clock on this one and then I'm due on the mezzanine." That sentence, said at 09:30 with the toolkit still closed, sets the shape of the visit before any add-on has been thought of. The user now knows there is a ten o'clock. When the monitor arm comes up at 09:52 the technician is not introducing a constraint; they are referring to one the user already accepted. Said at 09:58 for the first time, the same constraint sounds like the technician wants to leave, which they do, and which is beside the point.

The constraint is said a second time, earlier still, when the visit is booked. The message confirming the appointment carries the time, the length and the scope in two lines. It is the first place the user learns that a visit is for one ticket: "Sofia will be with you Monday at 09:30 for ticket 4471, the scanner cradle; the visit is booked for thirty minutes. If there's anything else, raise it as a ticket now or mention it on the day and she'll log it for you." Users who have read that sentence arrive at the visit with the add-on already half-expecting to become a ticket. Some of them, remarkably, raise it in advance. The confirmation line is in the template at the end, because it is the part of the schedule the user sees.

Technicians resist saying the constraint up front because it feels brisk, and there is a way to say it that is not. Lead with the ticket and the user's problem, then the time, then the next place, in a tone that treats all three as ordinary, because they are. The user does not experience "I've got until ten" as a rejection when it arrives before anything has been asked. They experience it as a technician who has a plan, which is a reassuring thing to encounter in a building where many people do not.

When the User Complains: The Manager's Backing

Somebody will complain, and the complaint will reach the desk lead in roughly these words: "your technician refused to help with a two-minute job". The first thing the desk lead does is open the ticket. If the technician has done everything in this series, the ticket answers the complaint before anyone has to argue it. It shows that the visit started on time and the finish line was met. It shows that the add-ons were logged at 09:52 with numbers, and the next visit started on time too. A complaint about a technician who logged three tickets in thirty seconds each and left for a packing line that was waiting is a complaint about the rule, not the person. The desk lead treats it as one.

The desk lead backs the technician in one message, to the complainant and copied to whoever the complainant copied, with the rule quoted and the ticket numbers in it. "Sofia was at the dispatch office for ticket 4471 from 09:30 and left at 09:58 for a booked visit on the mezzanine. The desk's rule is that a visit is for one ticket and anything else is logged on the spot; the three things Greg mentioned are 4482, 4483 and 4484, all in the queue and the first already assigned. If the rule itself is a problem for dispatch, I'd be glad to talk it through." Four sentences. No apology for the rule, no quiet exception, no suggestion that the technician should have "used judgement", because the technician did, and the judgement was the rule's. A desk where the lead apologises for the rule in private has no rule, and the technicians find that out by the second complaint.

Backing the technician does not mean the complaint is always wrong, and the lead separates the manner from the rule. If the ticket shows the add-ons logged and the visit on time, the rule was followed. If the complainant says the technician was curt about it, that is a separate conversation about how the sentence was said. That conversation is had with the technician, kindly, and not by way of granting the add-on. The one no the whole desk stands behind, including the lead when the complaint arrives, is the subject of A No the Whole Team Can Stand Behind. The schedule is one of the places it is tested most often, because the complaint arrives while the technician is still on the mezzanine.

The Calendar and the Queue

The schedule and the queue stay honest with each other through two habits. The first is that a visit is booked from the ticket and noted in it, so the queue knows which tickets are waiting on a visit and when. A ticket that says "visit booked Monday 09:30" is a ticket that is being worked. It should not look stale on Friday's aging report just because nobody has typed in it; the note is the activity. The second is that the day's add-ons go back into the queue as ordinary tickets, where they are triaged against everything else. Some of them will turn out to need visits of their own. Those visits go on the calendar in their turn, sized honestly, with a buffer.

The desk lead reads both, and reads them for load rather than for blame. A technician whose calendar shows four visits a day and whose captured add-ons run to ten a week is carrying a known amount of work. The lead can see it without asking. If you run QuerySolv, the queue shows who has claimed what. So the lead can see that a technician out on visits is also holding six open tickets without anyone being surveilled. The same is true of any tool with clear ownership. What the lead does with that picture is a question for the series on measuring load, and the honest answer is usually "fewer visits or more buffer", not "faster visits".

Whether the schedule is holding is measured by one number, which is how many visits started within five minutes of their booked time. The measure is read as a property of the plan rather than of the people. A desk arriving on time at nine visits in ten has a plan that tells the truth. A desk arriving on time at six in ten has visits sized short, buffers removed, or add-ons being done on the spot, and the captured tickets will say which. The last article in this series is about reading those tickets, and on-time arrival is one line of its report.

A Short War Story: The Three O'Clock at Stonebridge Insurance

At Stonebridge Insurance, a technician called Lucas was given a day of six visits back to back. The desk lead who assigned the day had read the empty gaps in the calendar as waste, and the day went the way such days go. The first visit ran nine minutes over. The second produced two add-ons he did on the spot to stay helpful. The third started twenty minutes late to a user who mentioned it. The fifth visit was to a claims handler called Dawn whose laptop would not connect to the claims system. By the time he reached her, it was ten to four instead of three. Dawn had given up waiting and taken a client call on a borrowed machine, reading from paper. The call went badly because the figures she needed were on the laptop that would not connect. The client escalated to her manager. The manager wrote to the desk to ask why an appointment at three had been honoured at ten to four with no message in between. Lucas's tickets showed every visit as "completed" and none of the add-ons, because nothing he had done on the spot had been logged. So the desk lead could not even show that the day had been overloaded, only that it had been late. The rebooked visit took twenty minutes the next morning. The lesson the desk lead wrote in her own notes was that the gaps she had removed had not been empty. They had been holding the day up, and the person who found out was the fifth user, with a client on the line.

The Visit Schedule

The schedule below is a day's plan for one technician. It includes the confirmation line the user receives, the arrival sentence, and the two checks the desk lead makes at the end of the week. Fill in the visits from tickets only, size each from its finish line using the desk's own ranges, and leave the buffers empty. The empty lines are the point. The confirmation line goes to the user when the visit is booked, and the arrival sentence is said at the door. The week's checks are read for the plan's honesty, not the technician's speed. A day that fits on this page without crossing out a buffer is a day that will mostly arrive on time.

THE VISIT SCHEDULE — ONE TECHNICIAN, ONE DAY
Technician: ______________   Date: __________   Desk's visit sizes: swap ____ / diagnosis ____ / handover ____

VISIT 1   Ticket ______   Location ______________   Finish line: ______________________
          Planned ____:____ to ____:____   Buffer after: ____ min (held empty)
VISIT 2   Ticket ______   Location ______________   Finish line: ______________________
          Planned ____:____ to ____:____   Buffer after: ____ min (held empty)
VISIT 3   Ticket ______   Location ______________   Finish line: ______________________
          Planned ____:____ to ____:____   Buffer after: ____ min (held empty)
VISIT 4   Ticket ______   Location ______________   Finish line: ______________________
          Planned ____:____ to ____:____   Buffer after: ____ min (held empty)

RULES FOR THE PAGE
  Every visit comes from a ticket; the ticket notes the booked time and that the user was told.
  Size from the finish line, with the desk's ranges; round up.
  Buffers are not booked into. They absorb the walk, the note, the captures and one two-minute fix.
  A visit that cannot fit with its buffer moves to another day; it is not squeezed in.

CONFIRMATION LINE (sent when the visit is booked)
  "______________ will be with you ________ at ____:____ for ticket ______, ______________;
   the visit is booked for ____ minutes. If there is anything else, raise it as a ticket now
   or mention it on the day and it will be logged for you."

ARRIVAL SENTENCE (said at the door)
  "I'm here for ticket ______, the ______________. I've got until about ____:____ on this one,
   and then I'm due at ______________."

WEEK'S CHECKS (read by the desk lead; properties of the plan, not the people)
  Visits that started within five minutes of the booked time: ____ of ____
  Buffers booked into: ____    Add-ons captured: ____    Add-ons done on the spot and logged: ____

The complaint about Sofia arrived on the Tuesday, from Greg's manager. Rhys, the desk lead, replied in four sentences with three ticket numbers in them and an offer to talk about the rule. The manager had not known there was a rule or that the three things were already in the queue. The manager's reply said that this was fine and that the monitor arm was not urgent anyway. Sofia could have told anyone that on Monday at 09:52 and, in a sense, had. The label PC on the mezzanine was back on the line by eleven. Nobody on the packing line knew it had ever been at risk of waiting for a monitor arm. That is the only measure of a protected schedule that matters: the people it protects never find out they needed it.

Frequently Asked Questions