The reason on a follow-up
The reason is the part of a follow-up that survives the person who made it. A row without one says somebody owed somebody something and nothing else, which is unusable to a colleague covering on Tuesday and unusable to you in three weeks. A good reason names what was promised, what it depends on, and what would make it unnecessary.
Who reads it, and when#
Not you, at the moment you write it — you already know. The readers are the drain, which puts the reason in front of whoever has to approve the action; the colleague looking at the queue while you are away; the person handling the reply that comes back; and you, months later, when a customer says "you were going to get back to me" and you need to know whether they are right.
That is why the reason is not a category. A dropdown of five labels would be tidier and would answer none of those four readers. The field is prose because the useful content — the condition, the caveat, the thing that was promised — does not fit a label.
What a usable reason contains#
| Thin | Usable | What the second one adds |
|---|---|---|
| Follow up | Ring back with the delivery date once the warehouse confirms Thursday's stock | What was promised, and what it waits on |
| Send quote | Send the revised quotation for the twelve-unit order, with the freight line itemised as they asked | Which quotation, and the change that makes it different from the last one |
| Customer asked | Confirm whether the annual plan can start mid-month; they said they would decide once they knew | The question, and the decision that hangs on it |
| Check in | Check the installation went ahead on Monday; if it did, this is a support case rather than a call | The test, and what to do with each answer |
The pattern in the right-hand column is the same each time: a promise, a dependency and an exit condition. The exit condition is the part most often left out and the part that saves the most time, because it tells the reader when the follow-up should be completed without doing anything.
Four things that are not reasons#
- A restatement of the channel
- "Call them" tells you the channel, which is already a field. It says nothing about what to say when they answer.
- A timestamp in prose
- "Promised Tuesday" duplicates the due time and drops the content. If the date matters as context — the date they promised, not the date you will act — say what happens on it.
- The customer's name
- The person is a field, and a name in the reason is a name in one more place it can go stale after a merge.
- An internal shorthand nobody outside your desk knows
- A three-letter code that means something to you is the fastest way to make a queue unreadable to a colleague.
Reasons written from a call#
When the voice books a follow-up, the reason comes out of the conversation rather than out of a form, and the caller's last lines and the voice's own travel with the booking. That makes the reason checkable: if it does not match what was said, the transcript is right there. It is worth a glance on any call that mattered, because a reason captured from speech is a summary, and a summary can drop the condition that was the whole point.
A reason from a call is also the place where a misheard commitment shows up first — usually as something slightly too general. "Ring back about the order" where the caller said "ring back if the order has not arrived by Friday" is a follow-up that will be executed a day early and for no reason.
Changing one#
The reason is editable while the follow-up is open, and editing it is better than cancelling and re-creating: the row keeps its history, its position in the queue and its place on the person's record. What you cannot do is edit it after the fact to describe what happened — the reason is why the commitment exists, and the outcome is recorded separately when the follow-up is attempted or completed.
Questions#
How long should a reason be?
One sentence that a stranger could act on. Two if there is a condition worth spelling out. Longer than that usually means the detail belongs on the thread or as a memory, with the reason pointing at it.
Does the customer ever see the reason?
No. It is internal — it appears on the queue, on the person's record and in approval queues, all of which are yours. What the customer sees is whatever message the follow-up eventually produces.
Can Connect write the reason for a follow-up I create by hand?
It writes one when it creates the follow-up itself, from the conversation the commitment was made in. On a row you create, the reason is yours — which is the point, because you are the one who knows what you promised.