Follow-Up Messages That Get Replies

Ticket 8827 at Wrenfield Solicitors has three follow-ups in it, sent over two weeks by two different technicians. They read, in full: "Hi Dana, just checking in on this one." "Hi Dana, following up on the below." "Hi Dana, any update on this?" Dana, a conveyancing paralegal with forty files on her desk, has replied to none of them. Nobody at the desk is surprised. Nobody at the desk can say what Dana was being asked. On the fifteenth day Mira takes the ticket and writes a fourth message: "Dana, for ticket 8827: does the error still appear when you open the matter from the meeting-room PC, or only from your own? If I don't hear back by Thursday I'll close this one, and you can reopen it any time by replying." Dana replies in forty minutes. "Only mine. Sorry, didn't realise you needed anything from me."

A follow-up message, or nudge, is a message to someone whose move it is on a ticket, written to get a reply. The ones that work have three parts: a specific question the reader can answer in one line, a date, and a plain statement of what happens next. The ones that do not work have none of those, and they are the most common message a help desk sends. This article is part of our Ticket Aging & Follow-Up Discipline series. It is about the wording. When to send each nudge is the subject of its own article on cadences.

It covers why "just checking in" fails. It explains the three parts and why each one matters, the subject line and the first sentence. It covers the user nudge, the vendor nudge and the manager nudge, each with its own shape. It covers the tone that gets replies, three messages to copy, and the mistakes that kill a reply. It also covers saved replies that do not read like saved replies, and what to do with the answer, or the silence. A short war story about five weeks of checking in sits near the end.

Why "Just Checking In" Gets No Reply

"Just checking in" asks for nothing, so it gets nothing. The reader opens it, sees no question, and infers that the sender wants to be seen to have followed up. Then they close it with a vague intention to look at the thread later. Later does not come. The message has made the reader responsible for working out what is wanted. That means scrolling down through the quoted history to find the last real question. Nobody with forty files on their desk does that. The follow-up has transferred work to the one person least able to take it on.

It also carries no date, so there is no reason to answer today rather than next week. Next week it will be under thirty newer messages. And it says nothing about what happens if there is no answer, so the reader correctly concludes that nothing will. A message with no question, no date and no consequence is not a request. It is a greeting, and people do not reply to greetings when they are busy.

Mira's message worked because it did the reader's work for her. It named the ticket, so Dana did not have to find it. It asked one question with two possible answers, so Dana could reply in four words. It gave a date, so Dana knew it mattered this week. And it said what would happen, with no edge to it. So Dana knew that ignoring it had a cost and that the cost was reversible. Forty minutes. Two weeks of checking in had been, in effect, two weeks of silence with a friendly tone.

The Three Parts

The first part is a specific question: one thing the reader can answer from their chair, in a sentence, without research. "Does the error still appear?" is specific. "Can you let me know where things stand?" is not, because answering it requires the reader to decide what "things" are and summarise them. A good test is whether the question could be answered with yes, no, a date, or a single fact. If it needs a paragraph, split it, or ask the smaller question first. Ask one question per message. A message with three questions gets an answer to the easiest one.

The second part is a date: a named working day, not "soon", "when you get a chance" or "at your earliest convenience". All of those mean never. The date tells the reader how urgent this is in a way no adjective can. It also gives them permission to put it off until then, which is a kindness. Give at least two working days so the reader does not feel cornered. Avoid Fridays, because a Friday deadline is a Monday deadline with extra guilt. Thursday is a good default. State it as a day, not a number of days. "By Thursday" lands. "Within three working days" has to be calculated.

The third part is what happens next: a plain statement of what the desk will do on the date if there is no reply. It also states what the reader can do about it afterwards. "I'll close this one, and you can reopen it any time by replying" is a consequence with a door in it. The consequence must be true, must be something the desk will actually do, and must not be a threat. The point is not pressure; it is honesty. The reader deserves to know that silence has a result, and that the result is not final.

These three parts together do something the "checking in" message cannot: they let the reader finish with the message. Read, answer, done, or read, decide to let it close, done. Either way the reader is released, and people reply to messages that release them. They avoid messages that will still be hanging over them afterwards.

The Subject Line and the First Sentence

The subject line carries the ticket number and the ask. Most ticketing tools thread replies back onto the ticket by matching the number in the subject. And the reader decides whether to open the message from the subject alone. "Ticket 8827: one quick question about the matter error" will be opened. "RE: RE: RE: Problem" will not. If the number has fallen out of the subject somewhere in the chain, the reply may land as a new ticket. That is how a desk ends up with two tickets about one problem and a nudge in each. Check how your tool threads mail. Keep the number where it expects it. Never strip it to make the subject look tidier.

The first sentence restates the question. Many people read mail on a phone, where the first line is all they see before deciding whether to deal with it now. Do not open with "Hope you're well" or "Following up on my earlier message". Open with the ticket and the ask. The context, if any is needed, comes second, in one line. The quoted history comes last, trimmed to the last exchange. That way, a reader who does scroll finds the relevant bit and not three weeks of signatures. Many tools trim quoted history automatically. If yours does not, trim it by hand. If the tool quotes everything regardless, say in the first line what the reader needs so they never have to scroll.

Three lines is a good length for the whole message, excluding the sign-off. Question, date and consequence, one line each. A nudge that runs to a paragraph has usually started explaining the technical history, which the reader did not ask for and will not read. If there is something they genuinely need to know in order to answer, put it in a second short paragraph after the question, never before it.

The User Nudge

The user nudge goes to a requester whose move it is. The desk has asked a question or sent a fix to try, and heard nothing. Its tone is warm, its question is small, and its consequence is a close with the door open. The three rungs, three days, seven days and fourteen days after the original question, each carry the same question restated. The consequence changes as the rungs go by, from "I'll keep this open for you" to "I'll close this on Thursday unless I hear from you". The timing of those rungs, and when the ladder stops, is set out in Follow-Up Cadences That Keep Tickets Moving. Here the point is what each rung says.

The first rung is the lightest: the question again, a day, and a line saying the desk is holding the ticket for them. "Is the error still appearing? If you can let me know by Thursday, I'll pick it straight up. No rush if it's sorted itself out, just say." It assumes the best, which is that the requester was busy or the problem went away. It makes either answer easy to give. Most replies come at this rung, if the question is small enough.

The second rung repeats the question and makes the consequence concrete, kindly. "Still happy to help with this; I just need to know whether the error is still appearing. If I don't hear back by next Wednesday I'll assume it's resolved and close the ticket. You can reopen it any time by replying to this." The requester now knows two things they did not know before: the ticket has a deadline, and the deadline is not the end.

The third rung is the close notice, and it is the one most desks get wrong by making it sound like a reprimand. It is not. "I've asked a couple of times and not heard back. That usually means it's sorted or no longer needed. So I'll close ticket 8827 on Thursday. If it's still a problem, reply to this at any time and it reopens with everything we've done so far." That message assumes a good reason for the silence, gives a date, and leaves the door open in the same breath. Then, on Thursday, the desk does exactly what it said. The close is a reply rather than a silent status change. The whole subject of closing without chasing forever, including the confirmation window after a fix, lives in User Confirmation Without Chasing Forever.

One habit makes every user nudge land better: name the requester's own words. If Dana's original ticket said "the matter won't open from the meeting room", ask about "the matter not opening from the meeting room", not about "the application error". The requester recognises their own problem instantly. They know this message is about them, which is more than most mail in their inbox can say.

The Vendor Nudge

The vendor nudge goes to a supplier, a support line, or an internal team that owns a system the desk does not. It is a different animal. The move is theirs by agreement. They handle many cases, and the reader is a stranger. It leads with the reference number, because that is what the reader will search for. It states what was promised and when, because that is the fact being chased. It gives the impact in one line, because impact is what moves a queue at the other end. It asks for one specific thing by one date. And it says, without heat, what happens if the date is missed, which is usually that the desk escalates within the vendor.

Facts, not feelings. A vendor nudge that opens with how frustrated the desk is will be read as a complaint and routed to the person who handles complaints. That person is not the engineer. Consider a nudge that reads "Case 44-2187: you committed to a firmware build by Monday 9th. It is now Wednesday 11th. Fourteen staff are sharing nine working devices meanwhile. Please send the build or a revised date by Thursday 12th. After that I will raise this with our account manager". It will be read as a case update by the engineer who owns it. Engineers answer case updates. The desk is not angry. The desk is keeping a record, and the vendor can tell.

Every vendor nudge is also mirrored to the requester, in the requester's terms. The requester does not get the vendor's case number. They get "chased the supplier today. They missed Monday's date. I've asked for the build or a new date by Thursday. I'll update you Thursday either way". The requester cannot see the vendor case. The nudge to the vendor is the work. The line to the requester is what stops the ticket looking abandoned while the work happens. The mechanics of raising and escalating a case with a supplier are the subject of the article on escalating to vendors and other teams. The nudge is the message that moves it along between escalations.

Internal teams get the same shape with the names changed. They often need it more, because the desk tends to go soft on colleagues. "Hi, any news on the certificate?" to the server team is "just checking in" wearing a lanyard. "Ticket 6118: you said the certificate would be renewed by Tuesday. The Harbor Street store still cannot run end-of-day. Can you confirm it's done or give me a time today? If not I'll ask Ravi to take a look." Same colleague, same courtesy, and an answer by lunch.

The Manager Nudge

The manager nudge goes to someone who has to approve, decide or choose before the ticket can move. It needs its own shape. Managers do not avoid decisions because they are lazy. They avoid them because the decision arrives as an open question with no options and no default. Answering it means doing the thinking the desk should have done. The manager nudge does the thinking. It presents the options, usually three, with the cost and consequence of each in one line. It recommends one and names the default the desk will apply on a date if no decision arrives.

The default is the part that works. "If I don't hear by Thursday I'll go with option B and close the ticket as not approved" gives the manager choices. They can approve with one word, choose differently with two, or do nothing. Doing nothing gets a safe outcome that they were told about in advance. Nobody has to schedule a meeting. The default must be the safe option, the one that changes nothing and spends nothing. That way, silence never causes a change the manager did not sanction. The desk is not deciding for the manager. It is declining to let the ticket wait forever for a decision nobody is going to make, and saying so politely.

Lead with the cost of waiting, not the technical detail. A manager reading "the finance team is forwarding mail to each other by hand, about an hour a day between them, until this is decided" understands the decision's weight in one line. A manager reading two paragraphs about mailbox permission models does not. They will come back to it later, which is the failure mode. Making the business consequence of a ticket visible to the people who decide is a skill of its own. It is treated in Making Business Impact Visible. The manager nudge is where it earns its keep.

Tone: Warm, Short and Without Apology

The tone of a follow-up is warm, brief and unapologetic, and the third is the hardest. Desks apologise for following up ("sorry to chase", "apologies for the reminder"). Every apology tells the reader the sender thinks the message is an imposition. That gives the reader permission to treat it as one. The desk is not imposing. It is keeping a promise it made when it accepted the ticket. Drop the apology and the message gets shorter and firmer at the same time.

Warm means assuming a good reason for the silence and saying so. "No rush if this has sorted itself out" and "I know you're busy, so one quick question" both tell the reader they are not in trouble. Being in trouble is the thing the reader fears when a ticket they ignored comes back. Short means three lines. Without apology means no "sorry", no "I hate to bother you", no "I know you have a lot on". The last of those is condescending and the first two are false.

Never use the nudge to make a point. A follow-up that says "as I mentioned in my previous three messages" is a reprimand with a question attached. The reader will answer the reprimand, usually with silence. If the earlier messages went unanswered, the earlier messages were the problem, and the fix is a better message, not a sharper one. (Mira's message did not mention the three before it. Dana apologised anyway.)

A Short War Story: Five Weeks of Checking In at Tollgate Foods

Tollgate Foods, a food distributor with a cold store and about eighty staff, had a vendor case open for the software that logged cold-store temperatures. The software had stopped recording overnight readings and left the compliance team taking readings by hand every two hours through the night shift. Kwame, the desk's one technician, had written to the vendor five times in five weeks. Every message began "Hi, just checking in on case 7718" and ended "let me know if you need anything from us". Every reply had been a variant of "the team is looking into it". In week six Kwame rewrote the nudge. It had the case number in the subject and the date the vendor had first said "next week". It stated the impact: two staff on a night shift doing manual readings for a compliance record. It had a specific ask: a patched build or a confirmed return to an older version by Friday. A line said that on Friday the desk would raise it with the account manager named on the contract. The vendor's engineer replied the next morning with the older version and instructions. The overnight logging was back by Thursday. The cost was five weeks of two people's night-shift time, roughly two hundred manual readings. The cost also included a compliance manager who had started pricing a replacement system. The lesson is the one the templates below are built on. A nudge is a question with a date and a consequence. And "let me know if you need anything from us" is an offer to do the vendor's job for them.

Kwame's sixth message was shorter than any of the first five. It was the first one that asked for anything.

The Three Messages

The three messages below are the user nudge at its second rung, the vendor nudge, and the manager nudge, written as plain text with blanks. That way, they can be saved as reply templates in whatever tool the desk uses and edited before each send. The parts in brackets are the ones that change every time. And the one rule of using them is that the question in brackets is always rewritten for this ticket, in this requester's words. A template with the question left generic is "just checking in" with better formatting.

The user nudge, second rung, for a requester who has not answered a question or confirmed a fix. Use it three to seven working days after the original question, with the question restated and the date two or more working days out.

THE USER NUDGE — SECOND RUNG
Subject: Ticket #______: one quick question about [their words for the problem]

Hi [first name],

Still happy to help with [their words for the problem]. I just need one thing
from you: [the specific question, answerable in one line].

If you can let me know by [weekday], I will pick it straight up. If I don't
hear back by then I will assume it is sorted and close the ticket, and you
can reopen it at any time by replying to this message.

Thanks,
[name], [desk name]

The vendor nudge, for a supplier or an internal team that has missed a promised date or gone quiet on a case. Use it on the promised date or the day after, and again two working days later with the escalation line changed to the next contact up.

THE VENDOR NUDGE
Subject: Case [vendor reference] / our ticket #______: [one-line ask] by [weekday]

Hello [name or team],

Case [vendor reference]: on [date] you committed to [what was promised] by
[promised date]. It is now [today] and we have not received it.

Impact on our side: [one line: who is affected and what they cannot do].

Please send [the specific thing needed] or a revised date by [weekday, time].
If I have not heard by then I will raise this with [account manager or
escalation contact] so that it gets the attention it needs.

Regards,
[name], [organisation], [phone]

The manager nudge, for an approval or a decision the desk cannot make. Use it when a ticket has waited more than a few days for a decision. Have the options already worked out and the default chosen as the one that changes nothing.

THE MANAGER NUDGE
Subject: Decision needed by [weekday]: [one-line description] (ticket #______)

Hi [first name],

Ticket #______ needs a decision from you before it can move. While it waits,
[one line: the cost of waiting, in business terms].

The options as I see them:
  A. [option]  -  [cost / consequence in one line]
  B. [option]  -  [cost / consequence in one line]
  C. [option]  -  [cost / consequence in one line]

I would recommend [A/B/C] because [one line]. A one-word reply is enough.

If I don't hear from you by [weekday], I will go with [the safe default,
usually the no-change option] and close the ticket as [not approved / on
hold until ______], and you can reopen the question at any time.

Thanks,
[name], [desk name]

Mistakes That Kill Replies

The table collects the habits that turn a good nudge into a greeting. Most desks run three or four of them without noticing, because they are polite habits. Politeness is not the problem; vagueness is. Read the fix column as a checklist against the next follow-up you send.

The last row is the one that undoes all the others over time. A desk says "I will close this on Thursday" and does not close it on Thursday. It has taught every requester who noticed that its dates are decorative. And the next nudge, however well written, will be read in that light. Carry out the consequence. It is the only part of the message that is tested.

Saved Replies Without Sounding Like One

Most ticketing tools let a technician save a reply for reuse. And many let the desk share a set across the team. The three messages above belong in that set. The danger is that a saved reply saves the sender the thinking as well as the typing. And a nudge that has not been thought about is a nudge that will not be answered. Two rules keep saved replies honest. The question is always rewritten for the ticket, in the requester's own words, before sending. And the first name and the date are filled in by a person, not left as a placeholder. "Hi [first name]" has been received by every requester at least once. It tells them exactly how much attention the message got.

Read the message once before sending, as the reader. Does the first line say what is wanted? Is there a day in it? Does it say what happens next? Could the reader answer in under a minute from their phone? If any answer is no, the template has been sent rather than used. Thirty seconds of reading saves two weeks of silence, which is the whole arithmetic of this article.

Check, too, that the message actually went. Some tools show a plain warning on the ticket when a mail could not be sent. Others fail quietly into a log nobody reads. A nudge that bounced because the requester's address changed, or because the vendor's case mailbox rejects attachments, is a nudge that did not happen. And the desk will sit for a week believing it is waiting on someone who never heard from it. Find out how your tool tells you a message failed, and look there before concluding that silence means the reader is ignoring you.

What to Do With the Reply, and With the Silence

When the reply comes, act on it the same day, even if the action is only to say so. Dana's four-word answer deserves a reply within the hour: "Thanks, that narrows it down. I'll check your profile this afternoon and update you by 16:00." A requester who finally replied and then hears nothing has been taught that replying was pointless. The next nudge to them will fail for reasons that have nothing to do with its wording. The reply also updates the status, back from the waiting state to the desk's move. That way, the ticket does not sit in Awaiting Reply with an answer in it.

When the silence comes instead, do what the message said. If the user nudge said the ticket closes Thursday, close it Thursday, with a reply that says so and repeats that a response reopens it. If the vendor nudge said the desk would raise it with the account manager, raise it with the account manager, copying the original case and the dates. If the manager nudge said option B applies by default, apply option B, close the ticket as not approved, and tell the requester what happened and why. Each of those is a small act of keeping the desk's word. Over months they add up to a desk whose dates are believed. That is the only kind whose nudges get answered.

The close after a user nudge is a reply, never a bare status change. A status change alone tells the requester nothing in most tools and leaves them to discover the close by finding the ticket gone. The reply states what was asked, that no answer came, that the ticket is closed, and that one reply reopens it. Why a close must always be a message, and what goes wrong at desks where it is not, is the whole of Avoiding the Silent Close. A nudge that ends in a silent close has undone its own good manners at the last step.

Ticket 8827 at Wrenfield closed two days after Dana's four-word reply, with a profile fix and a note in the knowledge base. Three "just checking in" messages, two weeks, nothing. One question, one day, one honest line about what happens next, forty minutes. The difference was never Dana's attention. It was whether the message gave her something to do with it.

Frequently Asked Questions