Setting Expectations Before You Start
Customer/User Communication for Support
Chapter 3 · Setting Expectations Before You Start
Chapter 2 covered translating findings after you know what's wrong. This chapter covers something that happens earlier — setting expectations at the very start of an interaction, before diagnosis is even complete, so the user knows roughly what's happening and what to expect from the process itself, not just the eventual outcome.
Why This Prevents Frustration Rather Than Just Managing It
Most user frustration during a support interaction doesn't come from the underlying problem itself — it comes from uncertainty: not knowing how long something will take, not knowing what's actually being done, not knowing whether they've simply been forgotten. Setting expectations early addresses that uncertainty directly, before it has any chance to build into frustration in the first place.
What to Actually Set Expectations About
- What's about to happen next — "I'm going to check X, then Y" — a concrete, near-term picture, not a vague promise to "look into it"
- A realistic timeframe — even a rough one is better than none, echoing `backup1`'s own RTO material: a pre-agreed, honest number beats a confident guess or no number at all, applied here to everyday support timelines rather than disaster recovery
- What's needed from the user, if anything — whether they need to stay available, do something themselves, or can walk away and be updated later
- What "done" will actually look like — so the user can recognize resolution when it happens, rather than wondering whether they need to ask again
Under-Promising vs. Over-Promising
The temptation to give an optimistic timeframe purely to sound reassuring in the moment is real — and exactly the mistake `backup1`'s own Chapter 9 warned against: "real numbers, not reassuring guesses." A broken promise damages trust more than an honest, uncertain estimate ever would, whether the promise was about a data recovery timeline or something as ordinary as "this'll just take a few minutes."
When You Genuinely Don't Know Yet
Early in diagnosis, before the problem is even understood, it's completely fine to say so directly: "I don't have a timeline yet, but I'll update you by [specific time] with what I've found." That's a concrete commitment about when more information will arrive, even without yet knowing the answer itself — which is a genuinely different, more trustworthy statement than either an invented number or total silence.
Worked Example: Two Openings, Same Interaction
| Opening | |
|---|---|
| No expectations set | Technician dives straight into technical work with no explanation — user left wondering what's happening and for how long |
| Expectations set | "I'm going to check your account settings first, then test the connection — should take about 10 minutes, and I'll let you know either way once I've got an answer." |
Both technicians may do the exact same technical work. Only one leaves the user with a clear sense of what's happening and when they'll hear something.
Hands-On Exercises
Explain why this chapter says most user frustration comes from uncertainty rather than the underlying problem, and why setting expectations early is described as preventing frustration rather than just managing it.
📄 View solutionExplain why "I don't have a timeline yet, but I'll update you by [specific time]" is described as a genuinely different, more trustworthy statement than either an invented number or staying silent.
📄 View solutionExplain why a stale, unupdated expectation is described as often worse than never setting one at all.
📄 View solutionChapter 3 Quick Reference
- Uncertainty, not the underlying problem, is the biggest driver of user frustration — set expectations early to prevent it, not just manage it later
- Set expectations about: what's next, a realistic timeframe, what's needed from the user, and what "done" looks like
- Honest, uncertain estimates beat reassuring guesses — a broken promise costs more trust than an honest "I don't know yet"
- When you don't know a timeline, commit to when you'll know more instead
- Update a stale expectation actively — a broken promise compounds the original delay rather than replacing it
- Next: Chapter 4, reading and de-escalating an upset user