A promised follow-up is a debt with a due date, and most support teams keep the ledger in an agent's head. "I'll get back to you Thursday" is written into a conversation, the conversation is snoozed or closed, and the only record that a promise exists is a sentence in a thread nobody will reopen.
This guide gives you a way to track those promises in Intercom with tags, notes and a weekly check, plus a log template you can copy.
Coming soon: Supportman will show which promised follow-ups happened and which went quiet, without a spreadsheet. Get notified at launch.
What counts as a promised follow-up?
Any statement to a customer that says "you'll hear from us again" about something. Five shapes cover almost all of them:
- Answer pending. "I'm checking with the team and will come back with an answer."
- Fix pending. "Engineering is looking at it. I'll update you when it's resolved."
- Action pending. "Your refund has been requested and will be processed this week."
- Decision pending. "I need a manager's approval and will confirm tomorrow."
- Check-in. "I'll follow up Friday to make sure that worked."
The last one is the cheapest to keep and the one that does the most for resolution: it turns silence into an answer. See first contact resolution for why silence isn't the same as solved.
Why do promised follow-ups get lost?
- The agent who made the promise is off shift, on leave, or reassigned when it falls due.
- The conversation was closed after the promise, because closing was the only way to clear the queue.
- The promise depends on someone else (engineering, finance, a manager) and nobody told that person a customer is waiting.
- There was no date, so there's no moment when anything looks overdue.
All four have the same fix: the promise needs an owner, a date and an end condition, written somewhere other than the agent's memory.
The follow-up log
One row per promise. Keep it in whatever your team already opens daily.
| Column | What goes in it | Why it matters |
|---|---|---|
| Conversation link | The Intercom URL | One click to the context |
| Promise type | One of the five above | Lets you see which kind slips most |
| What was promised | One sentence, in the customer's words | Prevents drift between "looking into it" and "fixed by Friday" |
| Owner | A named person, not a team | A team can't be overdue |
| Due | A date | Nothing is late without one |
| Depends on | Who else has to act | Shows blockers outside support |
| Closed by | The message that told the customer the outcome | The end condition: the customer was told, not the task was done |
The last column is the one teams skip. A refund processed and a customer informed are different events, and only the second is the follow-up.
How do you run it in Intercom?
- Add one tag for promises, such as
followup-due. One tag, not one per promise type. Use the log's type column for that. - Leave an internal note when the promise is made. A fixed format keeps it searchable:
Promised: <what> · Owner: <name> · Due: <date>. - Snooze the conversation to the due date instead of closing it, so it returns to the owner's inbox when it's due. Close it only after the customer has been told the outcome.
- Remove the tag when the promise is kept, after sending the message that closes it. Tagged and open means owed.
- Filter by the tag in the inbox to see everything currently owed, by owner and by due date.
If a promise depends on a manager's decision, record the decision where it can be found later. Approvals in Intercom and Slack keep the request and the answer together, but the message back to the customer is still yours to track.
The Monday audit
Ten minutes, once a week, by whoever runs the queue.
- Filter the inbox to the
followup-duetag. - Sort by due date. Everything past due is a missed promise. Count it.
- For each, ask: is the owner still here, is the blocker still open, has the customer written back?
- Reassign anything whose owner has changed.
- Record two numbers: promises made last week, and promises with the customer told by the due date.
The ratio between those two numbers is your kept-promise rate. Hypothetical: 24 promises made, 19 kept on time, 3 late, 2 never closed. The kept-promise rate is 19 ÷ 24 = 79%, and the 2 never closed are the ones to read. The numbers are made up to show the arithmetic.
Treat it as a process measure for the team. If it becomes an agent leaderboard, people will stop writing promises down.
What do you do when one is missed?
Message the customer before they write in. Say that it's late, why, and the new date. A short version:
I told you I'd update you by Thursday and I haven't. The fix is waiting on [what]. I'll write again by [new date], and sooner if it moves.
Then tag the cause: owner unavailable, blocked by another team, no due date set, or closed too early. A month of those tags tells you which part of the process to fix. If the same promise keeps slipping on one issue, that issue belongs in your reopen and repeat review.
What can Supportman do today?
Supportman doesn't track follow-ups yet. Its Friday report shows replied conversations, median first reply and median time to close, and its DSAT alerts surface customers who rated a conversation low, which can be where a missed promise surfaces. Tracking promised follow-ups across conversations is coming soon.
Frequently asked questions
How do I track customer follow-ups in Intercom?
Tag every conversation where you've promised an update, leave an internal note with the promise, owner and due date, snooze the conversation to that date, and review everything past due once a week. Close the conversation only after the customer has been told the outcome.
Do I need a separate tool for follow-up tracking?
Not to start. A tag, a note format and a weekly filter cover most teams. A separate tool becomes worth it when the volume of promises is too high to audit by hand.
Who should own a follow-up when an agent is out?
Whoever runs the queue reassigns it in the Monday audit, or earlier if the agent's absence is planned. The log's owner column is a person, so a change of owner is a visible edit.
What metric shows whether follow-ups are happening?
Kept-promise rate: promises where the customer was told the outcome by the due date, divided by promises made. Count the never-closed ones separately, since they're the ones to read.
When should I close a conversation with a promise pending?
After the customer has been told the outcome, not before. Snooze to the due date instead of closing, so the thread returns to the owner's inbox when the promise is due.