Follow-Up Cadences That Keep Tickets Moving

Ticket 6118 at Northgate Retail is a High. The store manager at the Harbor Street store cannot run the end-of-day till report, and has not been able to for three days. Jonas has worked on it every one of those days. He has read the logs and found a certificate that expired on the till server. He has raised a case with the team that owns the server and tested a workaround that nearly worked. The history is full. At 16:10 on the third day the store manager replies to the ticket: "Any update? Haven't heard anything." Jonas reads that and feels it as an injustice, because he has done nothing but work on her problem. She feels it as neglect, because from where she sits, nothing has happened for three days. Both are right, and the ticket is the thing that failed.

A follow-up cadence is the fixed rhythm at which a ticket hears from the desk, set by its priority and its status, whether or not there is news. It is a promise the desk makes to itself about silence: no ticket of this kind goes longer than this without a message. Cadences are what turn "I was working on it" into something the requester can see. This article is part of our Ticket Aging & Follow-Up Discipline series, which is about the habits that keep a queue honest week after week.

It starts with why silence is the failure rather than slowness, and how a cadence differs from a service level target. Then come cadence by priority and then by status, and what an update must contain to count. Next are the nudge ladder for requesters who have gone quiet and the one for vendors and other teams. Then comes when to stop nudging and what to do instead. A cadence table to copy follows, and how to make the cadence run without relying on anyone's memory. A war story about eleven quiet days sits near the end.

Silence Is the Failure, Not Slowness

Requesters forgive slow. They do not forgive silent. A requester is told on Monday that the fix will take until Thursday. They hear on Wednesday that it is still on track for Thursday. That requester waits calmly until Thursday. A requester who hears nothing from Monday to Thursday, and then gets the fix, has spent three days deciding the desk forgot them. The fix arrives as a relief rather than a service. Same fix, same Thursday, opposite experience. The difference was two sentences on Wednesday.

Silence is also how tickets age. A ticket that is being worked on but never updated looks, from the outside and from the queue, exactly like a ticket that is being ignored. The requester cannot tell the difference, the manager cannot tell the difference, and after a week the technician's colleagues cannot tell the difference either. When the technician is away, the ticket is simply a quiet thing with an old date on it. Nobody picks it up because nothing about it says it needs picking up. The work was real. The record of it was not.

The failure has a mechanism, and it is a kind one. Technicians go quiet on tickets they are working hardest on, because they want to come back with an answer and not with "still looking". Every day without an answer makes the next update feel more like an admission, so it gets put off another day, and the silence compounds. The cadence breaks that loop by making the update a scheduled event rather than a confession. Wednesday's message says "still on track for Thursday", because Wednesday is when the message is due, and nobody has to decide whether to send it.

Cadence Is a Promise About Silence, Not About Speed

A cadence is not a service level target, and the two are easily confused because they both have hours in them. A service level agreement, or SLA, is the written promise of how fast the desk responds to and resolves a ticket. It usually has a first-response target and a resolution target per priority. Those two clocks are explained in Response vs Resolution Targets. The cadence is the third promise, often written into the same agreement under a name like "update interval". It says how long the requester can go without hearing from the desk while the ticket is open. Response is about the first message. Resolution is about the last. The cadence is about every message in between.

The distinction matters because a desk can meet its response and resolution targets and still run every ticket in silence. Reply inside the hour, fix inside two days, say nothing for the forty-six hours in the middle: every target met, every requester chasing. The cadence closes the gap. It also covers the tickets the SLA cannot reach: the ones on hold for a vendor, the ones waiting on a budget. The ones that are legitimately going to take six weeks and whose resolution target breached on day three and has nothing further to say.

Some tools carry the update interval as a real clock with a countdown, so a ticket that goes too long without a public reply shows up as overdue. Others leave it to the desk to remember. A few will e-mail the assignee when the interval is missed; many only badge the ticket. Check whether yours has a target of that kind at all. If it does, check whether it counts internal notes as updates, because some do and that quietly breaks the whole idea. Whatever the tool, the cadence is the desk's promise, and the tool is only the reminder.

Cadence by Priority

Priority sets the basic rhythm, because priority is the desk's statement of how much the ticket matters. How often somebody hears from you is the most visible expression of that. The intervals below are working-time intervals for a desk that works office hours. A desk with a 24-hour schedule compresses them for the top two priorities and leaves the rest alone. Five priorities, five rhythms, and the rhythm is for open, actively worked tickets. Status adjusts it, as the next section explains.

An Emergency means the kind of ticket where a building, a site or a core system is down for many people. It is updated every hour while it is open. The update goes to the requester and to whoever is coordinating the response. Hourly feels excessive until you have been the person on the other end of an outage, at which point it feels like the minimum. The update can be one line. "Still down, cause identified as the storage controller, vendor engineer on site at 14:00, next update 15:00" is an hourly update, and it takes forty seconds to write.

Urgent, where one team or one critical person cannot work, is updated every four working hours, so at least twice a day. High, where work is seriously degraded but possible, is updated once every working day. Medium, the ordinary ticket where something is wrong and there is a workaround, is updated every three working days. Low, where the request is a convenience or a question with no deadline, is updated weekly. These intervals are generous on purpose. A cadence that the desk can keep on its worst day is worth more than a tighter one that gets kept on good days and quietly dropped on bad ones.

Notice that the Medium and Low intervals are longer than most requesters would choose and shorter than most desks would choose if left alone. That is where they should be. A three-day interval on a Medium means that a requester never waits more than three working days to hear something. That is the limit of most people's patience before they start wondering whether the desk is still there. That interval also means the desk is not writing daily updates on sixty tickets that have not changed since yesterday. The cadence is a floor, not a target. More often is always allowed.

Cadence by Status

Status changes the cadence because status says whose move it is. The rhythm of a ticket that is the desk's move is different from the rhythm of one waiting on somebody else. A status is the ticket's current state from a short fixed list. The ones that matter here are the open and working state, Awaiting Reply, On Hold, and Resolved. Awaiting Reply means the desk has asked the requester something. On Hold means the desk is waiting on something outside the conversation. Resolved means the desk believes the work is done and is waiting for the requester to agree. What each of those should and should not be used for is argued out in Pending User vs Pending Vendor vs On Hold. This article takes them as given and asks how often each one should hear from the desk.

Open and being worked: the priority cadence applies in full, as above. This is the state where silence does the most damage, because the requester knows the ticket is with the desk and is waiting for the desk. Every quiet day is a day they attribute to neglect. If the technician is actively working the ticket and has nothing new to say, the update says that, and says when the next one will come. "No change since yesterday; still waiting on the server team's reply, chased them this morning. I will update you tomorrow by 12:00 either way." That is a complete update, and it costs nothing.

Awaiting Reply: the desk has asked the requester a question and the move is theirs, so the priority cadence pauses and the nudge ladder takes over. The ladder is described in the next section, and its rungs are three working days, then seven, then fourteen, then a close with the door open. The ladder, not the priority, sets the rhythm here, because the priority of a ticket the requester is not answering is a question in itself. A High that the requester will not reply to for a fortnight was not, in the end, a High.

On Hold for a vendor or another team: the cadence to the requester drops to the Medium rhythm or the priority rhythm, whichever is slower. There is usually nothing new to say. The cadence to the vendor follows their promised date. The requester still hears from the desk every three working days at least, and the message is honest about what is being waited for and when the desk expects to hear. On Hold for a known date, such as a delivery or a change window, needs no nudges at all. The update is the note with the date on it, and a message to the requester saying what the date is. There is a reminder for the desk one day after the date in case the thing did not arrive.

Resolved: the desk has sent the fix and asked the requester to confirm. The ticket now sits in a confirmation window, the period during which a reply reopens it and silence closes it. The window has its own small cadence, one reminder in the middle and a close at the end. The whole subject of getting confirmation without chasing forever belongs to User Confirmation Without Chasing Forever. For the cadence table, Resolved is one reminder and then done.

What Counts as an Update

An update is a public message to the requester that says what has happened since the last one, what happens next, and when they will hear again. Three parts, and all three are required for the message to count against the cadence. "Working on it" is not an update; it has none of the three. "I have found the cause, which is an expired certificate on the till server. I have asked the server team to renew it and they have promised it by tomorrow 10:00. I will confirm with you by 11:00." That is an update. It is also more words than the technician has written to the requester in three days of hard work.

Internal notes do not count. A note that nobody but the desk can see keeps the history honest and is worth writing, but the requester is not reading the history. If the technician has written five internal notes and zero replies, the ticket has been updated zero times as far as the cadence is concerned. Internal notes exist precisely so that the desk can write things the requester will not see, and that is exactly why they do not satisfy the cadence. The update is the reply.

Status changes do not count either. Setting a ticket to On Hold tells the requester nothing unless a message goes with it, and in most tools a status change alone sends the requester nothing at all. Check yours, and even if it does send something, do not ask a one-word notification to carry an update. The requester sees a ticket that has gone quiet; the desk sees a ticket that has been correctly classified. The message that accompanies the status change is the update. The status change is bookkeeping.

The Nudge Ladder for Requesters

A nudge is a follow-up message to someone whose move it is, asking for a specific thing by a specific date. The ladder for a requester who has gone quiet has four rungs. A nudge at three working days, a second at seven, a third at fourteen, and then a close with the door open. Each rung is a public reply, and each one restates the question so the requester does not have to scroll. Each one says what happens if there is no answer by the next rung. The wording that gets replies, and the three message templates, are the subject of Follow-Up Messages That Get Replies; here the concern is timing.

Three days for the first rung, because people are busy and a question asked on Monday may honestly not be seen until Wednesday. Seven for the second, because a week is the natural unit of a requester's attention and the second nudge should land at a different time of the week from the first. Fourteen for the third, because by now the requester has had three chances and the message changes tone. Not "could you let me know" but "I will close this on Friday unless I hear from you, and you can reopen it any time by replying". Then the close, on the day the third nudge said. The reply says what the ticket was, that it closed for lack of a response, and that a reply brings it back.

The close is not a punishment and the ladder must never be written as one. A requester who does not answer has usually solved the problem another way, left the role, or decided it did not matter. All of those are fine, and the desk cannot know any of them without asking. The ladder asks three times, politely, and then stops asking and says so. A ticket that reopens on the requester's reply costs nothing to close and nothing to bring back. Most tools reopen it automatically; the rest do it with one status change by whoever reads the reply. This is what makes the fourth rung safe.

For a High or above in Awaiting Reply, compress the ladder: one day, three days, then a phone call before the close. A High that the requester is not answering is either not a High or a requester who cannot get to their mail. The phone call finds out which. A one-person desk with a hundred requesters can keep the full ladder on Medium and Low only if the tool is doing the remembering, which is the subject of a later section.

The Nudge Ladder for Vendors and Other Departments

Vendors and internal teams get a different ladder, because the move is theirs by agreement rather than by courtesy, and because they have usually promised a date. The first rung is the promised date itself: if the vendor said Thursday, the desk chases on Thursday afternoon, not Friday. The second rung is two working days after the first, and it names the miss: "You committed to Thursday, it is now Monday, please give me a revised date today." The third rung, two working days after that, goes to a different person: the vendor's account manager, the internal team's lead, or whoever the escalation contact is. The desk keeps nudging after that, but who nudges changes, and that is covered below.

Every vendor nudge carries the reference number, the original promise, the current impact in one line, and the specific thing being asked for. Vendors handle hundreds of cases; the nudge that gets answered is the one that saves them the lookup. Every vendor nudge is also mirrored to the requester as an update: "Chased the supplier today, they missed their Thursday date, I have asked for a revised date and will tell you tomorrow." The requester does not need to hear from the vendor. They need to hear that the desk is on the vendor. The mechanics of raising and chasing a case with a supplier, and what to do when the supplier does not move, are in the article on escalating to vendors and other teams.

Internal teams deserve the same ladder and often get a gentler one, out of politeness, which is a mistake. The server team is a vendor with a shorter walk. If they promised Tuesday and it is Thursday, the nudge names the miss and asks for a date. If the second nudge gets nothing, the third goes to their lead with the business impact attached. Politeness between teams is a good thing. Silence between teams, dressed as politeness, is how a High sits for a week while two people each assume the other is on it.

I once left a case with a supplier for nineteen days on the strength of the words "we are looking into it", which I had accepted as a date. It was not a date. It was a sentence.

When to Stop Nudging

Stop nudging a requester after the third rung, and do what the third rung said: close with a reply, door open. Continuing past three is not persistence; it is a desk sending messages into a mailbox that has told it, three times, that nobody is home. The ticket is better closed with a clear line in the history than open with a fourth and fifth nudge aging in it. The requester is better served by a message they can act on whenever they are ready than by a weekly reminder they have learned to delete.

Never stop nudging a vendor; change who nudges and what is said. After the third rung the ticket's technician keeps the cadence to the requester, but the chasing moves up. The desk lead chases the vendor's account manager. If that fails, the IT manager chases whoever signed the contract. The message changes from "please give me a date" to "this is now affecting fourteen people and has missed two committed dates; we need a named engineer and a date today". The nudge is no longer a reminder. It is a record being built, and the vendor knows it.

For an approver or a decision-maker inside the organisation, the ladder is two rungs and then a default. The first nudge asks for the decision with the options laid out. The second says what the desk will do if no decision arrives by a date. That default is chosen to be the safe option, usually "nothing changes and the ticket closes as not approved". Then the desk does that. A decision that nobody will make has been made, and the ticket records it. That is a better outcome than a ticket that waits in On Hold for a meeting that is never scheduled.

One more stop: stop nudging when the nudge has become the work. A Low ticket that has been nudged three times, closed, reopened by the requester with "still want this", and nudged three more times is not a follow-up problem. It is a request nobody intends to fulfil and nobody intends to refuse, and the honest move is to say which, once, in a reply. The cadence keeps tickets moving. It cannot make a decision for a desk that is avoiding one.

A Short War Story: Eleven Quiet Days at Harbourview Clinic

Harbourview Clinic, a medical practice with sixty staff and a desk of two, had a High ticket from reception about the label printer that produced patient wristbands. It had started printing every third band blank. Nadia diagnosed a failing print head on day one and ordered the part on day two with a five-day lead time. She set the ticket On Hold with the part number in an internal note and moved on to the other twenty-eight things. The part arrived on day eight and sat in the post room, because the note was internal, the hold had no date, and nothing reminded anyone. Reception had heard nothing since day one. They bought a desktop label printer from a high-street shop on the practice's card on day nine. They spent two days failing to make it talk to the clinical system. On day eleven they complained to the practice manager that IT had "gone silent on a patient-safety issue". Nadia fitted the print head on day twelve, in fifteen minutes. The cost was the unwanted printer, two days of a receptionist's time, and a day of Nadia's time undoing the second printer's software. There was a conversation with the practice manager that was not about the print head. The lesson was the cadence by status: a ticket On Hold is still a ticket the requester is waiting on. "I ordered the part" is only an update if the requester hears it.

The work on that ticket was done on day two. The failure was that nobody who mattered was told, and the part sat in a box for four days with nobody expecting it.

The Cadence Table

The table below is the whole of this article in one place, with the defaults for an office-hours desk of one to ten people. Copy it and change the intervals to ones you can keep on your worst week. Write the changed version into the SLA document or the team's one-page workflow. Put the table where the queue is read. The intervals are in working days unless stated as hours, and "update" means a public reply with what happened, what is next and when the requester will hear again.

Two notes on reading it. The Awaiting Reply column is a ladder, not an interval: the numbers are the days after the question was asked at which each rung happens. The two On Hold columns both require the requester to be told what the hold is for and when the desk expects news. This happens at the moment the ticket goes on hold. It is the update that most often gets skipped because the technician is busy writing to the vendor. Write to the requester first. They are the one who cannot see the vendor case.

The Nudge Ladder on One Card

The ladder is the part of the cadence people forget mid-week, so here it is separately. It is in the shape of the note a technician leaves on a ticket the moment they set it to Awaiting Reply or On Hold. Fill in the dates when the question goes out, and the rest of the cadence runs itself: each date is a touch due, and the sweep catches any that are missed.

NUDGE LADDER — FILL IN WHEN THE QUESTION GOES OUT
Ticket: #______   Priority: ________   Status set: ____________  on ________

REQUESTER (Medium / Low)                 REQUESTER (High and above)
  Rung 1  +3 working days:  ________       Rung 1  +1 day:        ________
  Rung 2  +7 working days:  ________       Rung 2  +3 days:       ________
  Rung 3  +14 working days: ________       Rung 3  phone call:    ________
  Close with reply, door open: ________    Close with reply:      ________
  Each rung restates the question and states the next rung's date.

VENDOR / OTHER TEAM
  Promised date: ________    Reference: ____________  Contact: ____________
  Rung 1  on the promised date (afternoon):           ________
  Rung 2  +2 working days, naming the miss:           ________
  Rung 3  +2 working days, to escalation contact:     ________
  After rung 3: desk lead chases; then IT manager chases. Never stop.
  Requester updated after every rung:  [ ] 1  [ ] 2  [ ] 3

APPROVER / DECISION
  Rung 1  options laid out, decision asked by:        ________
  Rung 2  default stated, applies on:                 ________
  Default if no decision: ______________________________________

Making the Cadence Run Without Memory

A cadence that depends on technicians remembering is a cadence for a desk with one technician and twelve tickets. Past that, the tool has to carry it, and there are three places a tool can help. The first is an update-interval clock per priority, with a visible countdown and a breach that reaches the assignee. Then a ticket going quiet is a thing the tool notices before the requester does. The second is a dashboard that separates "waiting on you" from "waiting on the customer". Then the desk's-move tickets and the nudge-due tickets are two short lists rather than one long one. The third is a date on every hold, so that a ticket parked for a delivery surfaces again on the day after the delivery was due.

Most tools have some of these and few have all three. An update-interval target is common in tools with a full SLA engine and rare in simpler ones. Where it exists, check whether a breach reaches the assignee by e-mail or only badges the ticket. Expect that a breach on an unassigned ticket reaches nobody, which is one more reason every ticket has an owner. A dashboard that splits waiting-on-you from waiting-on-customer is also common; if yours shows only a total, two saved filters do the same job. A reminder on a held ticket's date is the rarest, and on most desks it is a habit rather than a feature. The date goes in the note, and the weekly sweep reads the notes.

One difference between tools changes how the intervals are set, and it should be tested rather than assumed. Some tools pause the SLA clocks while a ticket is On Hold or Awaiting Reply. Some pause on one of those statuses and not the other. Some never pause, and exclude only non-working hours and holidays. Put a ticket on hold over a weekend and read its due time on Monday, and you will know which kind you have. In a tool that never pauses, the cadence mostly benefits. A ticket in Awaiting Reply that goes quiet past its update interval shows up as overdue. That is exactly when the next rung of the ladder is due, and the nudge is the public reply that satisfies it. It does mean the update interval for Low and Medium must be set no tighter than the first rung of the ladder. Otherwise every held ticket breaches on day two. In a tool that pauses, the ladder has to be carried by the desk's own dates, because the tool has stopped watching. Either way, write into the SLA document only the exclusions the tool actually applies.

Whatever the tool does, the sweep is the backstop. A weekly pass through every ticket untouched past the threshold will catch any rung of any ladder that the tool and the technician both missed. A cadence with a sweep behind it fails gracefully, by a week, rather than by a month. The cadence is the plan. The sweep is what happens to plans.

Ticket 6118 at Northgate Retail, meanwhile, got its update at 16:25 on day three, four sentences long. A second one the next morning said the certificate had been renewed and asked the store manager to try the report. She replied inside ten minutes: "Works. Thanks for keeping me posted." Jonas had kept her posted exactly once, and that was all it took. The cadence is not more work. It is the same work, with the door open so people can see it being done.

Frequently Asked Questions