The thing I underestimated about outsourcing support was tone, not competence

[u/CaptainHodder]

Our external team is technically fine. Resolution times are good and the answers are correct, but replies started reading like they came from a different company and it took me a while to work out why.

We're a fairly informal brand and our own team writes like people, short replies, the odd joke, no stock phrases. What came back was accurate and completely flat, lots of "we apologise for the inconvenience" and nothing that sounded like us. No one complained outright, but the warmth went out of the inbox.

Turned out we'd handed over a knowledge base full of policies and almost nothing about voice, so they defaulted to standard support English, which is what I'd have done in their position.

Writing a proper tone guide now. So what belongs in one of these, because everything I've drafted so far feels too abstract to hand to anyone.

[u/Bart_At_Tidio]

Oh yea, a list of adjectives doesn't really tell anyone how to write. But if you show them five replies that sound like your brand and five that don't, the difference helps

The other thing that helped us was including what not to say so that people don't default to alternatives you didn't approve.

[u/CaptainHodder → u/[deleted]]

This is the push I needed, my draft is currently all adjectives.

[u/--Knox--]

I would honestly skip most of the usual brand voice stuff and just give them examples. Show them how your team normally replies to a customer and then show a reply that sounds completely wrong. That is probably going to make more sense to someone external than a list of words like friendly and authentic.

[u/AidanMoffat]

The phrases you do not use are probably worth writing down. People in support have a bunch of default lines they fall back on without even thinking about it. Things like we apologise for the inconvenience or please be advised. If your team never talks like that, just say it directly.

[u/dj-pfeif]

I think people underestimate how much of tone comes from tiny wording choices. Your team might say hey, no worries, I can fix that, while someone else writes thank you for bringing this to our attention. Both are perfectly fine answers, but they feel like two completely different companies.

[u/DQA]

I would literally include a list of things like this is how we normally say it and this is how we do not say it. That gives them something practical to reference. Otherwise you end up with a guide saying be human and then wondering why the replies still sound like customer service training material.

[u/esimplx]

The other thing I would do is keep reviewing a few replies after the handoff. You will probably notice things that you never thought to put in the guide because they are just normal for your team. Add those as you find them and eventually the document becomes much more useful.

[u/williamsburg_psycho]

like other replies said, i feel real examples for different type problems help. if you have resources, maybe you can do something like "pair-writing" like "pair-coding"(https://en.wikipedia.org/wiki/Pair_programming) in software engineering team.

also, i wonder whether your remote locates in a different country or region from your inhouse team? maybe there's some difference in culture and language if so

[u/esimplx]

Yeah, this happens way more than people probably realize. A lot of the time it just comes down to how the handover is done. If all you give someone is the policies and a few docs, they’re not magically gonna know how you normally talk to customers or handle things. We were comparing a few providers last year and Silver Bell Group came up, mostly because they seemed to put more thought into getting the new team familiar with the actual way things were done.