The Problem With Three Knocks (and What Great Support Teams Do Instead)
TLDR
The three-knock model exists to stop stale tickets eating agent capacity, but it treats every silent customer the same. Silence can mean resolved, blocked by a vendor, on holiday, or never received. This piece covers ticket states that match what is actually happening, automation that removes admin without removing context, soft closes that preserve goodwill, and context-aware follow-up using AI.
This article was first written on swifteq.com
In customer support, first touch is always important. But follow-up often gets underestimated when teams talk about what creates a strong customer experience.
At small volumes, the processes around follow-up are trivial. The agent sends the key message, the customer replies, and the issue closes.
At tens of thousands of tickets a month, that model doesn't work anymore. You end up with hundreds, sometimes thousands, of conversations sitting in limbo.
And why they went quiet can vary widely: they could be testing a workaround, waiting on a vendor, fixed but never replied, never saw the email, or escalated internally without communicating that back to the customer.
No matter the reason, this is where and why the three-knock model was invented. It's simple in theory — send a few reminders, and close the ticket if you don't hear back. But customer support leaders have argued for years over whether it is efficient, robotic, customer-friendly, or all three.
The bigger question is not whether three knocks are good or bad. It is how to design follow-up workflows that protect against aging tickets while respecting the needs of every customer and the reason each ticket exists.
What Is the Three-Knock Model in Customer Service?
The Three-Knock Model goes by many different names, but it's a very common customer service approach. It essentially means that when you're responding to a customer support ticket, you'll reach out to the customer three times before closing out the ticket.
Why the Three-Knock Model Exists?
No customer service org can afford unlimited follow-up with unresponsive customers.
Let's say an agent owns 100 active tickets. Rechecking stale ones gets expensive fast. And is it the best use of their time? Usually not.
The breaking point comes when teams spend more time chasing responses than actually solving problems for customers and users.
This gets worse at scale. Imagine thousands of tickets a week, in a department with already tight staffing and tight budgets. That is all too familiar for anyone who has worked in a high-volume environment.
Reminder and closure workflows exist to keep agents focused on engaged customers, not living in old conversations after the customer has moved on. The original goal of the three-knock model was effective queue management.
Challenges with the Three-Knock Model
There are a few big challenges that customer support teams face when using the Three-Knock Model (or any other similar kind of rigid, time- or contact-based follow up model).
Silence can mean different things
An unresponsive customer could mean several things:
- The issue is resolved and they've moved on.
- The customer is testing a workaround.
- They're on vacation.
- They're waiting on a third party.
- They never saw the email.
The list goes on. There are countless reasons, and every customer is different. One customer may need five days to reply, and another may need five weeks. A fixed timeline cannot tell you why they have gone quiet.
Different types of follow up carry different weights
There is a second variable here that matters just as much as the silence itself: what are you following up for?
If you are confirming that a fix worked, silent auto-closure is relatively low risk. The customer can reopen the ticket, and usually, a non-response is the confirmation that the fix worked. The problem went away and they're all set.
But if you need information to keep troubleshooting, silently closing the ticket can block the work. This is troublesome if it's an issue specific to one customer, but even more so if it's impacting others and you need more information to investigate and solve the issue.
If you close this type of ticket, the customer may come back later with the same problem. If they do, now they'd have to reopen an old ticket or start a new one and explain the whole thing again.
Both of these are concerning and can lead to building customer frustrating and eventual churn.
To solve this, you need to standardize the workflow but keep the judgment flexible. Treat follow-up policy as a guideline, not a hard rule.
Use Ticket States That Match What Is Actually Happening
To actually handle this in practice, you need to stop dumping every inactive ticket into one waiting bucket. Different situations need different ticket states. Here's what this might look like in Zendesk:
| Ticket state | What it means | How to treat it |
|---|---|---|
| Open | Active troubleshooting. Agent action is required. | Keep it in the active queue and work it. |
| Pending / Waiting on Customer | The team needs information to proceed, usually from the customer but sometimes from another source. | Define the SLA behaviour for this state explicitly. |
| On Hold | The customer asked for time, is waiting on a third party, has a scheduled test coming up, or is working through an implementation window. | Set a follow-up date based on the reason for the hold. |
| Resolved | The work looks complete, but the customer can reopen it easily. | Keep the conversation and context available for a defined reopen period. |
| Closed | The ticket is archived, no longer active, and considered fully complete. | Remove it from active work and make the closure rules clear. |
Every state represents a different reality, so the timers, reminders, and SLA treatment should reflect that. If you need more granularity and your Zendesk plan allows it, you can use custom ticket statuses to get even more clarity (e.g. waiting on a third party vendor versus waiting on an internal team).
Good Automation Removes Admin Work, Not Important Context
Automation gets a bad rap sometimes, but it's usually because teams implement it poorly.
The bad version of automation sends robotic reminders that ignore the actual conversation, the tone, the intent, and why the ticket was paused in the first place. It creates endless agent alerts that nobody acts on and everybody ignores.
A good version removes admin work without removing important context. Here are a few patterns that work:
- Auto-reminders after a set interval.
- Follow-up or "on hold until" dates that auto-reopen the ticket and pull the agent back in on the right day.
- Routing stale conversations back into active queues.
- Soft-close notifications before closure.
There are two important details to take into consideration as you build this out too.
Business days versus calendar days. Two business days per bump behaves nothing like a flat 48 hours across a weekend. Decide deliberately based on your business model. Do your customers typically reply on weekends? If not, business days may make more sense.
Delivery channel. Not every customer sees in-tool notifications. A reminder that never reaches their inbox is not a follow-up. It is a countdown they cannot see. Let customers choose a preferred channel where possible, ideally matching the channel they used to reach out.
The point is not to engage automation for its own sake. It's to free agents for real troubleshooting with engaged customers, without leaving other customers feeling ignored or left behind.
Soft Closing Tickets Is an Easy Option
Customers should not feel punished for missing an email or replying a little later than you would like. The easiest way to ensure this doesn't happen it to send a note with a soft close. It can be as simple as:
"We haven't heard back, so we'll assume things are moving in the right direction and close this ticket for now. If you still need help, just reply to this email and we'll pick up where we left off."
Done properly, this preserves goodwill, keeps the full conversation history, minimizes duplicate tickets (so you won't need to merge those tickets late), signals that support is still available, and pulls stale tickets out of active queues.
AI Can Make Follow-up Context-Aware
AI can help a lot here, especially by enabling context-aware automated follow up.
Let's go through an example.
On day one, the customer says: "We're blocked by our vendor until the 15th. We'll confirm once they have pushed the change."
A strict time-based automation sends a bump on day three, another on day five, and soft-closes the ticket on day seven. That is three pointless touches, and it makes the team look like they did not read the email.
A context-aware workflow catches the vendor dependency and the date. It suppresses the bumps, schedules one check-in for the 16th, a day after the customer expected to hear from the vendor, and surfaces nothing to the agent in between.
If the 16th passes without a response, then it triggers the soft-close sequence.
The same logic applies when a customer says they are testing a workaround, out of office until Monday, or dealing with an intermittent issue and need a week.
High Ticket Volume Is a Constraint, Not a Free Pass
This is one area where a lot of support professionals disagree. Is high ticket volume a real constraint, or is it an excuse for lower quality systems and processes?
One view is that drowning at 40,000 tickets per month points to a process, tooling, or headcount failure. Volume does not reduce how much customer experience matters, and "we're too busy" can become an easy way to rationalize poor backlog and queue management habits.
The other view is that volume genuinely changes what is possible. A team handling 500 tickets a month can afford manual judgment on every stale ticket. A team handling 40,000 cannot. That's just the reality of the work.
Both sides are worried about something real, and that is that volume doesn't reduce how much CX matters. But, it absolutely changes what you need to do to deliver great customer experiences.
At scale, you can't rely on individual heroics or managers manually reviewing every queue. You're reliant on AI, workflows, and rock solid processes to deliver consistently good experience.
The systems that hold up combine clear ticket states, automated reminders, soft-close flows, frictionless reopening, self-service, and AI-powered copilot tools.
Follow up Based on Real Context, Not a Fixed Number of Knocks
The Three-Knock Model isn't inherently good or bad. It's simply one attempt to solve a real problem: stale conversations can't eat support agent capacity forever. However, the mistake is assuming every silent customer is the same.
The best approach uses automation to absorb repetitive follow-up work while leaving room for context, judgment, and flexibility. It keeps queues healthy, makes it easy for customers to come back, and points agent time toward what actually matters.
And this can work for both low- and high-volume support organizations. Ultimately, not every ticket needs three knocks, but every ticket deserves a follow-up process built with both efficiency and empathy.