figure out what's wrong with support and fix it

[chadwhitacre]

Our support flow is baaaaad. I have 61 emails in my support queue and I don't hardly know where to start. What's wrong and how do we fix it?

cc: @bruceadams @pjf

[bruceadams]

I don't have a far-reaching answer. I did look, on SupportBee, through all of the support tickets that looked like they might be active. I have a sense of ordering: which ones I'd prefer that you look at first; which ones I think are straightforward and which I think are messy.

One minor tweak I can imagine being helpful uses SupportBee's user interface. I could ⭐ a few tickets that I would like @whit537 to look at first. That would help avoid the wall of issues problem, although moves away from @whit537 using his email client for handling support. I expect the ⭐ annotations will only be visible within SupportBee.

[chadwhitacre]

@bruceadams Sure, let's give the stars a shot.

[pjf]

I'm not sure I have access to SupportBee; although I've been at Confoo the last week and have quite a backlog available.

The immediate things I feel to check are:

• How many people are doing support? In most organisations, many support queries can be handled by first line support who don't need specialised privileges or high levels of training. If we don't have lots of people doing front-line support, then we want them.
• Do we have a multi-level support structure? @whit537 shouldn't be responding to support tickets unless they've already been flagged as needing special attention. If nobody's flagging them, we need more low-level support. If too many of them are being flagged, then we need more high-level support people, or we need to fix whatever issue is generating that number of support requests.
• Do we have a support wiki? That's useful for people doing support (because they can find and update answers), but also useful in reducing workloads (because end-users can also find and potentially update answers, too).
• What's our bus-factor for high-level support? If it's just @whit537 then we need to get another high-level person trained up, and ideally have notes from that training so we can repeat the process.
• Do we have an anonymous "how useful was this support" functionality, that ideally triggers when a ticket is closed? That means we can track if we're actually providing useful support, and can also indicate which people are doing a great job at support, and which ones could do with additional coaching.

As for which tickets to look at first, if you want "fairness" then we'd probably go for tickets which are blocking people from using the service, especially if it's something that involves a withdrawal; we do not want gittip looking bad when it comes to making withdrawals. After that, fairness would dictate that oldest tickets get handled first.

Going forward, I know that people are crazy-happy if their support requests get responded to super-quickly; so responding to the 5 minute old support ticket can provide much more happiness and good publicity than the 12 hour old support ticket. Of course, you don't want tickets going stale, so prioritising tickets older than a certain amount (I'd suggest 24 hrs) makes perfect sense here.

~ Paul

[chadwhitacre]

Do we have a multi-level support structure?

Barely. @bruceadams is level one, and I'm level two.

If too many of them are being flagged ...

This is the problem.

... then we need more high-level support people

One consideration is that anything beyond basic support generally requires access to money systems (Balanced, PayPal, Coinbase), and that's a significant trust barrier. I'm ready to trust @bruceadams with access to those systems. Maybe we bump @bruceadams to level two, bring @pjf on at level one, and move me to level three?

... or we need to fix whatever issue is generating that number of support requests.

There's some of that as well. #1976 knocked out a big one for us. Totally unscientific, but #126 and #54 are the other two biggies.

[pjf]

Maybe we bump @bruceadams to level two, bring @pjf on at level one, and move me to level three?

Yes please. But ideally not just me as level one. Level one should be "we trust this person to respond to questions when they know the answer, or flag them when they do not". That should be a pretty easy level of trust to hand out.

I should note that I spend five months a year travelling, so my availability is wildly variable. ;)

~ P

[seanlinsley]

A possible replacement for SupportBee: http://tenderapp.com/tour/collect/

[bruceadams]

@whit537 I've added a ⭐ to three support tickets assigned to you in SupportBee. Each of them are BitCoin related, appear to be straightforward and appear to need action from you. None are emergencies, but getting to them soon would be a good thing.

[seanlinsley]

IRC

[patcon]

Sorry, haven't read fully yet, but wanted to drop context-less links :)

http://venturebeat.com/2014/01/22/help-desk-software-heres-some-of-the-best-and-most-interesting/
https://github.com/awesomatic
https://github.com/Deskero
https://github.com/desk
https://github.com/freshdesk
kana = nothing
https://github.com/Kayako
parature = nothin
https://github.com/SupportBee
https://github.com/Zendesk
https://github.com/zoho

[patcon]

Also, awesome comment @pjf

One bullet made me think of this thing I shared in IRC a few weeks ago:
"Everyone on Support" at 37signals

A few discoveries we’ve made so far:

1. It’s an incredibly useful training tool.
2. Long-standing problems get fixed.
3. The workflow process has applications outside support.
4. It reminds us why we’re all here in the first place.

[patcon]

Do we have a support wiki? -- @pjz

I would love to enable the github wiki for this. FAQ items should be easier to edit and improve for less technical people, imho, and so a github wiki is a step in the right direction.

(For the record, I absolutely disagree with developer-centric stuff going in a wiki (ie. another repo), as I think that belongs in a docs/ directory where changes to supporting docs can be enforced as part of PR's.)

[seanlinsley]

I would love to enable the github wiki for this. FAQ items should be easier to edit and improve for less technical people, imho, and so a github wiki is a step in the right direction.

A Github wiki isn't any better for non-technical people than creating a PR (that's saying something -- Github has made a lot of progress on that front). Worse: it's not Gittip-branded. If we want a knowledge base for everyday users we should either make it part of docs/ that gets rendered inside www.gittip.com, or we should use something like http://tenderapp.com/tour/collect/

[patcon]

@seanlinsley I respectfully disagree that submitting pull requests is friendlier for non-devs than editing a wiki, but the point is moot if we're using freshdesk (which seems AWESOME so far :)

[patcon]

@whit537 If I understand correctly, we're currently sending [email protected] to both supportbee and freshdesk, right? If this is the case, perhaps we could switch wholesale?

(I went through some tickets but then realized that I might be double-replying, which would seem pretty unprofessional.)

[chadwhitacre]

@patcon Yes, we are now sending support tickets to both SupportBee and Freshdesk. I turned off the email replies from Freshdesk, so Freshdesk should be invisible to users.

My goal is to evaluate these services and pick one. We should continue to reply to users from SupportBee until we decide together on a way forward.

[chadwhitacre]

Freshdesk is a much cleaner and mature product than SupportBee. Between those two, we should definitely go with Freshdesk. I've spent 15 minutes each with TenderApp, Zoho, and Zendesk, enough to satisfy me that we're not shooting ourselves in the foot by not going with them.

@patcon is excited about Freshdesk, and @bruceadams is indifferent. IRC

Therefore, let's move forward with Freshdesk.

[chadwhitacre]

I also considered using account delegation with plain old Gmail. That's not featureful enough, though. We regularly use private notes in SupportBee, for example.

My long-term ideal would be to build support features into Gittip.com itself (a la Heroku and GitHub), but that's beyond our engineering bandwidth right now.

[chadwhitacre]

[email protected] is now forwarding to Freshdesk only. We should start replying from there.

• close other accounts
• finish configuring Freshdesk

[pjf]

FreshDesk doesn't always seem to be auto-chaining/auto-threading tickets. This ticket is continued here, meaning that we lose context. This is really bad; we don't see previous notes, we'll miss closing tickets in a "wait for customer" state, etc etc. Other tickets seem to be threading fine, so I don't know if one is required to leave the Freshdesk URL in a ticket, if there was a problem checking In-Reply-To fields, or if there's something else going on.

[patcon]

As mentioned in IRC, might be inline replies.

cc: @thanashyam @JohnSundarraj @freshdesk (In case you guys are interested :)

[chadwhitacre]

Closing w/ retickets (#2127, #2128).

[chadwhitacre]

Freshdesk doesn't always seem to be auto-chaining/auto-threading tickets.

@pjf I believe the ticket id needs to be in the subject line of any reply emails. Let's reticket if this is still an issue.

[thanashyam]

Ticket ID in the Mail Subject and the In-Reply-to Header are two of the things that Freshdesk looks for in an email to attach it to an existing ticket.

[chadwhitacre]

Thanks @thanashyam. :-)