How to talk to customers when the whole conversation is written

"We'll look into it and get back to you shortly."

That reply leaves support queues thousands of times a day and it does almost no work. Two words are why. "We" is nobody in particular, so nobody is visibly on the hook. "It" is whatever the customer wrote about, which means the sentence would fit any ticket in the queue and proves nobody read this one. The customer can't tell whether their message reached a person or a process.

Most advice on how to talk to customers is written for somebody standing in front of one: make eye contact, watch your speaking pace, greet them within thirty seconds. That's useful on a shop floor and inert in a queue, where the customer is a name and a timestamp, every round trip costs hours instead of seconds, and everything you type can be re-read, forwarded and screenshotted six months later. This is about that version of the job, mostly email and mostly phone, which is where small teams still do the bulk of their talking.

The short version, before the detail: read their message for four things (the ask, the constraint, what they already tried, the emotion), name the actual things instead of pointing at them, say "I" for what you're doing and "we" for what the company promises, ask one question rather than five, and refuse clearly before you soften it.

What changes when the whole conversation is written

Three things are different, and almost everything else follows from them.

You have no tone channel. In person you get pace, volume, a shrug, a laugh. In a thread you get word choice and punctuation. The warmth you think you're transmitting mostly isn't arriving, and the irritation you think you're hiding often is.

Every round trip costs hours. Spoken, a misunderstanding gets repaired in four seconds. Written, an ambiguous sentence means the customer replies to ask what you meant, and the answer lands tomorrow morning. Anything that buys an extra exchange is expensive in a way it simply isn't out loud.

It's permanent. Your reply gets re-read when the customer is calmer, forwarded to their boss, pasted into a review, screenshotted. Write for the second reading, not just the first.

None of this changes what good service is. It changes what it takes to execute it, which is the layer this page is about: the words inside one reply, the order of the turns, and what happens to both when the address is shared. If you want the standard underneath all of it, that's what excellent customer service actually means.

Read the message first: four things to find before you reply

Most bad replies aren't writing failures. They're reading failures. Before typing anything, find these four things in what the customer sent:

1. The ask. What do they actually want to happen? It's often not the thing in the subject line.
2. The constraint. A date, a budget, a contract, an event they're preparing for. This is what makes an answer usable or useless.
3. What they already tried. Telling someone to do the thing they just told you they did is the fastest way to look like you didn't read it.
4. The emotion. Are they curious, inconvenienced, or done with you? You don't have to name it back. You do have to know which one it is before you pick a register.

Here's what that looks like on an ordinary message:

"I ordered the replacement cable on the 3rd and it still says processing. I already tried the tracking link in the confirmation email and it doesn't load. I need it before Friday because we're shipping the unit to a customer."

The ask is a delivery date, not a status page. The constraint is Friday, and it's the whole point. They already tried the tracking link, so sending it again is out. And the emotion is mild pressure rather than anger: they're not upset with you, they're upset about Friday.

A reply that handles all four is short. Confirm the order and what's holding it, answer the Friday question directly, skip the tracking link, and say what you're doing next, in that order.

That last part has a rule of its own worth stealing from outside support. The US federal plain language guidance for government writing, which exists because vague official prose wastes everyone's time, puts it plainly: "Active voice makes it clear who should do what. It eliminates ambiguity about responsibilities." "The order will be investigated" tells the customer nothing about who's investigating or when. "I'm chasing the warehouse this afternoon and I'll email you either way by 5pm" tells them both.

Be concrete: the language change with the most evidence behind it

If you change one habit, change this one. Concrete language means naming the actual thing instead of pointing at it.

Grant Packard and Jonah Berger tested this on real service interactions in a 2021 Journal of Consumer Research paper on linguistic concreteness. Concreteness, for their purposes, is a matter of degree rather than a switch: how far a word "refers to an actual, tangible, or 'real' entity, describing objects and behaviors in a manner that seems more specific, familiar, and perceptible to the eye or mind." Their field data was 185 customer service phone calls at an online apparel retailer and 941 email exchanges at a Canadian retailer, plus experiments to test cause.

The sizes are worth knowing because they're larger than you'd guess for something this small. In the call data, a one standard deviation increase in concreteness was associated with an 8.9% increase in customer satisfaction, and in the email data the same shift corresponded to more than $10 extra in average customer spending over the following 90 days. Scope, in the same breath: that's retail service rather than B2B software support, the field results are correlational, and the causal evidence comes from the lab experiments rather than the two retailers.

The mechanism is the useful part. Concreteness works because customers read it as evidence that the employee was listening, or in the authors' words "attending to and understanding their needs." You can't convincingly claim you read someone's message. You can prove it by using their nouns.

In practice:

The right-hand column isn't longer. It's the same length with the placeholders filled in.

One limit the same paper found, and it's the reason the reading section comes first: when the employee's reply missed what the customer actually needed, concreteness stopped helping and the effect on perceived listening turned negative. Specific language about the wrong thing is worse than vague language, because it proves you weren't listening rather than just failing to prove you were.

Say "I", not "we"

The second habit is smaller and stranger. When you're the one doing something, say so in the first person.

Packard turns up again here, with Sarah Moore and Brent McFerran, in work published in the Journal of Marketing Research in 2018. Baylor's Keller Center summary of that research reports that they "analyzed over 1,200 customer-firm email interactions" and found that a firm agent's use of "I" pronouns is linked to increased customer purchases, while "we" and "you" are not. Agents writing "I" came across as more empathic and as acting on the customer's behalf.

One number from this work gets quoted a lot and needs its hedge attached. The researchers' summary says their first study's data "suggested that applying this simple change could be linked to a revenue increase of up to 7%." Read the verbs: suggested, could be linked, up to. That's a projection from field data, not a lift anyone measured in a trial. The pronoun finding is solid, the 7% is an estimate, and anybody quoting it as a result is overselling it.

Why it works is the same reason concreteness does. "We'll take a look" describes an organization. "I'll take a look and come back to you by Thursday" describes a person with a name, and it makes the next action attributable to somebody.

"We" is still right for things the business is committing to rather than you: pricing, policy, what happens at renewal, anything the customer could reasonably hold the company to later. So "I" covers what you're about to do, "we" covers what the company stands behind. Which raises an obvious problem in a shared address, where the "I" who promised Thursday might be on vacation Thursday. More on that below.

Talking with customers, not at them: the questions that do the work

"Talk with customers" is usually treated as a softer way of saying "talk to customers." It isn't the same skill. One is about answering well. The other is about asking well, and asking is what gets you the information that makes the answer possible.

Huang and colleagues built a useful taxonomy of this for a 2017 paper in the Journal of Personality and Social Psychology, It Doesn't Hurt to Ask: Question-Asking Increases Liking. Coders sorted every question across 368 transcripts of online get-to-know-you conversations into six types, and follow-up questions, the ones that pick up on what the other person just said, were the most common at roughly 40% of all questions. Why follow-ups matter is the transferable bit: a follow-up is only possible if you asked something, listened to the answer, and wanted to know more. It's the question type that can't be faked.

Two things have to be said honestly about borrowing this. The conversations were get-to-know-you chats and speed dates, not support tickets. And on sheer volume the paper points the opposite way from where I'm about to go: participants told to ask at least nine questions were better liked than participants told to ask at most four. So take the follow-up mechanism from the research and treat what comes next as a working rule from the queue, not a finding.

The rule is this: in a thread, ask one question, not five. That's a constraint the researchers weren't testing for, because nobody in their study had to wait until tomorrow for an answer. Five questions in an email is five chances for the customer to answer three of them, and now you need a third message. In a live chat or on a call, where follow-ups cost nothing, ask away. In asynchronous writing, pick the single question whose answer changes what you do next.

A good clarifying question in a ticket usually has three properties. It names why you're asking ("so I can tell which of two fixes you need"), it's answerable in one line, and it doesn't ask for anything already in the thread. "What version are you on?" is fine. "Can you describe the issue in more detail?" is asking the customer to do your reading for you.

When the same answers start repeating across tickets, that's signal rather than noise, and it's worth doing something structured with what customers tell you instead of answering the same question forever.

How to say no without buying a second round trip

Every guide on this topic says the same thing: never say no, use positive language, focus on what you can do. That advice is half right, and the missing half costs you a day.

Start with what's defensible. Michael Yeomans, Julia Minson, Hanne Collins, Frances Chen and Francesca Gino went looking for the linguistic markers that make disagreement land, and published Conversational receptiveness in Organizational Behavior and Human Decision Processes in 2020. Their four-item recipe, verbatim, is that receptive responses "often include: positive statements, rather than negations; explicit acknowledgement of understanding; finding points of agreement; and hedging to soften claims." In the study that tested it, 771 participants were split between a control condition and one that read that recipe, and the recipe group's responses were rated more persuasive by ideological opponents, a result the authors call surprising "both to us and to the participants."

Two caveats ship with it. They studied political disagreement between strangers and disputes between Wikipedia editors, not customer service, so this is an analogy rather than a finding about your queue. And the part nobody quotes: their own participants rated the intervention "harder to execute in a future interaction with a disagreeing other" and reported being "somewhat less likely to use the receptiveness strategy again." It works and it's effortful. Both are true.

Now the part the standard advice gets wrong in writing, and this is a practitioner rule rather than anything the researchers tested. Hedging is on that list, and hedging is exactly where written refusals fall apart. If you soften a no until the customer genuinely can't tell whether the answer is no, they will write back to find out, and you've bought a second round trip on a question you already answered. "That's not something we currently support" reads as a maybe. It gets a reply asking when.

So invert the order. Give the refusal in a clear sentence, then put the softening around it rather than on top of it:

"No, I can't backdate the invoice to March. I know that's annoying with your quarter closing. What I can do is issue a credit note and a corrected invoice today, and send both to you now so your accountant can decide how to book them. Want me to do that?"

The no is unmistakable, the acknowledgement is real, the alternative is something the sender can actually deliver, and there's one question at the end rather than three. Note what the reply doesn't do: it doesn't tell the customer's accountant how to treat a credit note, because that's the customer's call and a guess dressed as reassurance is exactly the kind of soft claim that generates the next email.

If the customer is already angry rather than just disappointed, that's a different problem with a different approach, and it starts before the refusal. So does knowing when to stop: if you're two replies into a no that isn't landing, handing the thread to whoever can actually change the answer beats a third rewording of the same refusal.

How to speak to customers when it isn't writing

Some of your conversations still happen out loud, and what changes on a call is mostly about memory.

The customer can't re-read you. They can't skim ahead, they can't see your structure, and they have to hold your answer in their head while you're still talking. That means one idea per breath, no nested conditions, and a recap before you hang up: what you're doing, what they're doing, and by when. If you catch yourself saying "so basically" for the third time, you've already lost them.

The other rule is simple and gets broken constantly: never give a number or a date only verbally. Prices, dates, case references and anything that sounds like a promise get repeated in writing afterward. Not because the customer is untrustworthy, but because three days later neither of you will remember it the same way.

Which points at the thing that actually matters for a team. A call that isn't written back into the thread didn't happen as far as everybody else is concerned. The next person to open that ticket sees a customer who's been waiting two days and no record of the conversation where you promised them a quote. The note doesn't need to be long: what they asked, what you promised, and the date you promised it by.

If what you want is the spoken half in more detail, including openings, holds and closings for the calls that repeat, that's customer service scripts rather than this page.

When the conversation changes hands

Here's the failure mode that no amount of good writing fixes on its own. A customer emails, gets a reply from one person, answers their question, and the next reply comes from somebody else who asks the same question again. Or worse: the second person contradicts the promise the first person made.

The customer notices this immediately, and they don't read it as a staffing quirk. They read it as nobody paying attention, which undoes every concrete noun and every well-placed "I" in the thread above it.

Three things prevent it, and none of them are about writing style. Read the whole thread before replying, not just the newest message. Keep one owner per conversation until it's closed, so the "I" in the thread means the same person tomorrow. And record promises where the next person will actually look, which means in the thread itself rather than in somebody's head. That's largely what a shared inbox is for, and a shared inbox tool like TriageFlow shows who's already replying to a conversation before a second person starts typing into it.

What the standard advice gets wrong in a written queue

Most of the tips on this topic were written for face-to-face service and then copied into articles aimed at people working a queue. Here's what survives the move and what doesn't.

Two things deliberately aren't in that table. Greetings, sign-offs and the whole question of how formal to be belong to how to format an email. And reusable text is a separate topic worth getting right on its own: canned responses are fine, as long as somebody fills in the concrete details before sending.

Checking whether any of this is happening

None of the above is visible from a dashboard. Response time and ticket volume tell you nothing about whether the replies were any good, which is why teams can hit every target and still read as careless.

The cheap version of a quality check takes twenty minutes a month. Pull ten sent replies at random, not the ones anybody escalated, and score each one on five things:

• Does the first line name the specific thing the customer wrote about?
• Is there a vague noun ("it", "the issue", "your request") where a real one belongs?
• Does the reply answer the ask, or only acknowledge it?
• Is there a named next step with a date, and a person attached to it?
• If a promise was made, is it written in the thread where the next person will see it?

Score them out of five, look at the distribution rather than any individual reply, and re-run it next month. You're looking for which of the five fails most often, because that's the one worth coaching. Doing this on your own sent mail first is also the fastest way to find out whether you personally do the thing you're about to ask the team to do.

Frequently asked questions

How do you start a conversation with a customer?

In a queue, you usually don't. They start it, and your equivalent first move is what your opening line does with their message. Lead with the specific thing they wrote about rather than a greeting plus a status update, and they'll know within one sentence that a person read it.

What should you never say to a customer?

Skip the list of fourteen banned phrases. Two habits cost you real time: "we'll get back to you shortly" (nobody is on the hook, and "shortly" means nothing), and any refusal hedged so far that the customer has to write back to find out whether it was a no. Both generate an extra round trip.

How do you talk to customers professionally?

In writing, professional means specific and unambiguous, not formal. Stiff, distant language often reads as less professional rather than more, because it's usually vaguer: "your request is being processed" is more formal than "I'm sending your replacement today" and tells the customer considerably less.

How do you talk to an angry customer?

Differently, and mostly before you get to the words. Anger usually means something already went wrong more than once, so the first job is finding out what was promised earlier in the thread and whether it happened. Handling difficult customers covers the rest.

What's the best way to talk to customers over email?

Email is the channel where all three constraints bite hardest, so the routine is: read for the four things, answer the ask in the first two sentences, name the specific things rather than pointing at them, use "I" for whatever you're about to do, and end with one question at most. Everything else on this page is detail underneath that.

How do you talk to customers with no experience?

Use a routine instead of instincts. Find the four things in their message, answer the ask directly, name the next step and the date, and re-read your draft once looking only for words a stranger couldn't interpret. It's a smaller skill than it looks, and it's mostly reading.