Technical topics often tempt Customer Success Managers/CSMs to type up all the info they can think of and launch it at the client's inbox like a cannonball.
This is usually a mistake -- but the mistake isn't writing the draft, it's pressing send.
Here's a better path.
- Write out an email that has all the key points but would still be reasonable to send
- Instead of sending, send a message like this: "Hi client, would you have time to review X on the phone later today, maybe 3pm ET?"
- Use your email as talking points
Assuming the CSM feels comfortable talking with clients, whatever the complicated or bad news is, the call will go better than the email would have.
What do you do with the email you wrote out so carefully, besides use it as talking points? Send it:
- either as a followup to the client confirming what you already discussed
- or to yourself, and give it a label like "Emails I was thoughtful enough not to send" so that you can look back and see how concise you've been
Chocolate chip cookies
Right this moment, how much would you pay for a cookie at a coffeeshop? Let's say the amount is $3.
(I could really go for one, so my personal estimate might be higher. I mean, check out how good that looks.)
How much would you be open to paying the coffeeshop for a subsequent cookie? A third cookie? A fifth?
Probably it would be steadily less than $3. Why? Later cookies have lower value.
Well . . . for now at least. If you come back to the coffeeshop tomorrow, you could be ready for more!
A related principle applies in Customer Success: people love hearing when you ship a feature they wanted. But tell them about a third feature or a fifth? Their eyes will glaze right over.
(Speaking of glaze, if cookies aren't your thing, how about these glazed scones?)
Sure, sometimes an engineering team works in bursts. Progress can come all at once. Then, the temptation for Customer Success is to "catch up" by reporting things to clients exactly when they happen.
This doesn't mean that as a Customer Success team you can't be strategic about who to announce features to, and when.
- Notice each client's rhythm of hunger for new features
- Keep a stash of "feature snacks" to give clients
- Treat yourself to a literal or figurative cookie (or scone)
What if there were two words you could add to any email to get your team to weigh in quickly?
There are: DEFAULT DO
How default-do works
- Write up a final version of what you'll be doing (your "default do")
- Tell teammates you're about to do this thing
- Do the thing
I use default-do every day to keep Faraday moving:
- Blog posts!
It doesn't matter what it is: if I'm confident it's the right thing to do, I'll tell my team I'm about to do it, pause, then just do it.
Don't wear it out. If you don't really want feedback, don't ask, and if you need it, your default isn't "do," it's "don't."
One overlooked way to connect with and help a customer is to reference the other software they use.
The tricky part here is remembering. Here are a couple ways you can work the stack-track into your CS routine.
The screenshot method
When your user shares their screen to walk through an issue, you may catch a glimpse of their OS chrome: take screenshots early and often. Right away you can determine my:
- Operating system (Mac OS X)
- Web browser (Chrome)
- Office chat (Slack)
Is this my life story? Not quite. But now I have clues to solve browser bugs (Chrome), suggest new integrations to the product team (Slack), and determine the user's technical level (Sublime and Terminal—a possible developer in this case).
The tab method
You can see here that I run on Gmail, Google Calendar, and Salesforce. Take a screenshot or just note them down.
Want to bend my ear? How about a question like this.
So, you're on gcal and salesforce. Any frustrations?