When it all goes wrong (because it will)

Editor's Notes

1. Hello, flying customer service\nCampaign Monitor context\nPractical outcome, useful document and how to implement it \n
2. 3 parts\nthings you can do before it all goes wrong\nthe main “deliverable” document\n
3. Putting the plan into practice during a crisis\n
4. dealing with the aftermath\nno need to take detailed notes (url at end)\nmgmt speak - service recovery\n
5. (star trek next)\n
6. people who get problems resolved = happier than no problem at all\nfor non-severe, first issue, company not in control of issue\ncan’t create problems in order to fix\nfirst, a map \n
7. this map will be relevant a little later\n(locator next)\n
8. This spot in particular\nzappos next\n
9. Zappos sounds awesome, and they do great things\nCan’t get anything in Australia\nSick of hearing about them.\n\n
10. the work you do before it goes wrong makes a big difference\nwithout the pressure of immediate replies\nneed to know what kind of company you are in\nsome businesses are not about service...ryanair\n
11. \n
12. Haven’t we all felt this way at times?\n
13. if you are starting in ryanair territory your customer service crisis plan will be...different\nboth valid models (what their customers value most is cost?)\nwhere would you rather work?\n
14. email, phone, twitter, facebook, bat signal?\ndepends on product/service, and on your resources\nprimary channels vs funneling in?\n\n
15. decide in advance which person or role will be in charge of which channel\navoid double handling or missing queries\nexample next\n
16. can also have escalation points (devs, management, sys admins?)\nhow and when to contact\nex. pager system\n
17. can’t respond until you know it is emergency\nexact same response 2 hours later is not as effective\nturn from pitchforkers to supporters\nnagios, pingdom, human eyeballs, supplier sources\nautomated checks\n
18. under pressure you can say dumb things, or misleading things\nit’s hard to be clear and concise\nmight have a known list of likely events to work with\n
19. sample structure\n“thanks for reporting this, we are aware” \nnot customers fault\nhelpful detail\nwhat’s being done\n
20. might already have this \nprepared responses, trawl previous examples\nconsistency is efficient and effective\nAugust 2009 - hacker vomiting spam, company ethos important\n
21. \n
22. when it’s all hitting the fan\nmany of our customers never talk to us at all\nthis interaction may define the relationship\nno history of service to fall back on\naction plan needs to be accessible\n
23. receiving spam myself\ngetting the devs involved to track the hack at unreasonable hours\nwho do you need to pull in?\nmy bosses...not so much\n
24. surfing together off a boat, uncontactable for days\nmaking decisions based on their customer service approach\n
25. responsiveness bar very low, esp. in our industry\nnicereply, speed mentioned many times more than any other factor\nearly information keeps things calm\nshared, partial responses, adjusted to specifics\n
26. want to cut things off in the confused / concerned area\navoid messy head explosions\ndifferent channels have different expectations of speed\n
27. goodwill from fast first response wears off\nhow often will you update (depends on issue, customers)\neven if no change, confirmation of continuing work helps\novercommunicate if in doubt\nCM blog post on hack (pushing out instead of reacting)\n
28. if it applies to you\ntendency to be heads down working\nrepresent customer\naccurate, timely information vital\nhire devs for empathy\n
29. don’t hamstring support folk\nwant to be helpful, don’t have tools or information\nleads to crappy service, loss of trust\nhipchat, intranet, email, status page\nosmosis fails in remote teams\n
30. keep track of people who want to be informed\nbest way to get great feedback\nmake sure actually fixed first\nwe reset passwords....\n
31. \n
32. once service restored\ntemptation to minitru and pretend it never happened\ninform everyone who wanted to know it was fixed\n
33. for affected customers, time to say sorry\nfakes: minimising issue, blaming third party, blaming customer\ninstead, a real apology\n
34. don’t bother if you aren’t actually sorry, it will backfire\n\n
35. gives them background as to what happened and why, timeline\n
36. doesn’t try to shut down the conversation\nopen to follow up\n
37. sorts out resulting problems\nhelps them get setup to achieve what they were trying to do\ne.g set up campaign for them to affected subscribers\nexplains what is being done in the future\n
38. how did we do in this crisis?\nwhat worked, what held us up or caused us problems\nwhat tools could we have used?\nwhat great answers came out we could save?\nupdate document for next time\n
39. small teams just know what’s happening automatically\nlarger teams need effort and structure\nnew people = no company history, memory, “who knows what”\nwork on soft skills more than tech skills\nshare examples\n
40. a guide to creating an “in case of emergency” plan for your support team\nhelp make smart decisions under pressure\ncontinually improve service\ncome talk to me later, thanks so much\n