Instructions are read under stress
By the time someone is being walked through a process in chat, they are usually already frustrated.
They have tried something that did not work, they may be short of time, and they are now switching
between your instructions and the screen they are trying to fix. Everything about how you write
changes under those conditions.
The main consequence is that a long, complete, well-organised message is worse than a short one.
A visitor reading five steps at once will hold the first, lose the rest, do something slightly wrong,
and come back with a question that is now harder to answer because you no longer know where they
are.
The second consequence is that precision matters more than usual. Words like “just”,
“simply” and “quickly” do nothing except suggest that anyone struggling is
slow, and they are worth removing from instructional writing entirely.
One step, then wait
The single most effective habit is sending one step at a time and waiting for confirmation. It feels
slower and is almost always faster, because you find out immediately when something does not match
rather than three steps later.
Waiting also gives you information you cannot otherwise get. If the visitor says the button is not
there, you have learned something specific about their version, their permissions, or their account
state, and you have learned it before they have done three more things on top of a wrong assumption.
Ask for confirmation in a way that is easy to answer. A question that can be answered with what they
see — what does it say now, what options do you have — is better than one answered yes or
no, because people say yes when they are not sure and want to keep moving.
Where a process genuinely has to be listed in full, send the overview first and say how many steps
there are, then walk through them one at a time. Knowing there are four steps rather than an unknown
number changes how someone feels about starting.
Describe what they will see, not just what to do
The instruction that fails most often names an action without naming the landmark. “Click
settings” assumes they can find settings; “in the top right, next to your name, there is a
gear icon” tells them where to look. The second version costs you eight words and saves a round
trip.
Describe what should happen after each step as well, because that is how someone knows they have
done it correctly. If clicking the button opens a panel, say so. If the page will reload and look
briefly blank, say that too — a visitor who is not warned will assume it broke and undo it.
Use the words that appear on their screen, exactly, including capitalisation where it helps. If your
interface says Billing details and you write payment settings, you have invented a small puzzle at the
exact moment the person has the least patience for one. When the label differs across versions, say
what it might be called instead.
Know when to stop typing
Some processes cannot be usefully walked through in a chat window, and recognising that early is a
skill in itself. If you are three exchanges in and still establishing what the visitor is looking at,
more instructions will not fix it.
The signals are consistent: repeated mismatches between what you describe and what they see, a
process with more than about six steps, anything involving a screen you cannot picture, or a visitor
who is clearly not comfortable with the interface. At that point, switch tools rather than persisting.
Asking for a screenshot is the cheapest switch and resolves most confusion instantly, because you
stop guessing at their screen. Co-browsing or a short call is the next step for genuinely complex
setups. And sometimes the right answer is to do it for them where your permissions allow, or to send
written steps they can follow later when they are not under pressure.
Say why you are switching, briefly, so it does not read as giving up. “A screenshot will be
faster than me describing it” is a reason, and it keeps the visitor cooperating rather than
feeling like a problem.
What to measure
Watch how many exchanges these conversations take and where they stall. A repeated stall at the same
step is almost always an interface or documentation problem rather than a visitor one, and it is worth
fixing at the source.
Track how often instructional chats end with the visitor confirming success. Conversations that
simply stop are frequently unresolved, and counting them as resolved will flatter your numbers while
producing repeat contacts.
Keep the steps you find yourself typing repeatedly. Anything explained more than a few times a week
belongs in a saved response and probably in a help article, and it should be written once properly
rather than improvised each time.
Step-by-step help usually turns on an identifier the visitor gave you several messages ago. Your console keeps those within one click rather than a scroll-back, with the caveats set out in the details your console lifts out of a chat — including why you read a reference number back before you act on it.