In a perfect world, your support team would be able to handle anything thrown at it. Need a bug fixed within the app? Easy. How about an account restored from a backup? Done. You’d be like Iron Man saving your customer’s day while inside that snazzy armor.
In the real world, you’re going to need a programmer to work with. And no – it’s not going to be Jarvis. (Alright, I’ll stop with the superhero talk).
But how do you steal a programmer away to work on the things you need help with?
Enter the On Call Programmer
An On Call programmer works primarily with support during the week, two weeks, or whatever amount of time you want to set for the stretch. During that time, they can handle those pesky bugs and other things that crop up with customer emails. After the cases are cleared out, they can work on other things to help out the support team like new internal tools, better access to data, etc.
The big thing is that the On Call programmer is there to help support first and foremost. They’ll get a chance to see firsthand some of the common customer issues. And you’ll get a programmer to ask questions without interrupting their work on other projects.
Here’s how it works in practice.
- You get a case that needs to be run by a programmer. You add a note with your question and assign it an “on call” label.
- The programmer opens the case, does what’s needed, then leaves a note on it. Then they flip the case back to you.
And that’s it. Super easy on both sides. The programmer can handle each case as it comes through the queue. It’ll make the support team / programmer team interactions way easier for everyone involved.
Do you have a dedicated programmer for support help or do you just grab anyone that’s free?
How timely, we were just talking about this exact role in our team today! Now if we can get our dev team set up with awesome vests like the guy in the picture, we’ll be set.
Chase Clemons says
Everyone needs a least one vest like that!
haha I would love to see a developers face when you suggest that all they ever get to do is work on faults 🙂
We have worked a couple of different methods for issue resolution but the most successful was an assigned fault day/period where the entire development team spent 1 – 2 days every 2 weeks working on issues for the customer service team.
This meant we could keep customers informed of when faults would be resolved and left developers free for project work the rest of the time. They would only need to stop that work if something very urgent came up. The customer service agent could also research issues enough to ensure that they provided all of the necessary information and then prioritise the list based on requirements.
I do love the idea of a SupportOps Developer role though, perhaps it could be good training ground for a Junior Developer? It would mean they learn about the actual day to day business of the company and its customers, instead of just being shut away from them.
Chase Clemons says
Just working on bugs and faults all the time would definitely suck. What we do at 37signals is rotate the programmer in this role. Two people will work On Call for two weeks. Then they’ll rotate off and head to a project in need of them.
I love the idea of knocking everything out in 1-2 days every so often! Definitely a good idea to spread that list of bugs around so everyone could work on them.
If you combine it with some innovation stuff as well it can work really nicely. If they finish all of their bugs in one day, the next day they can do pretty much whatever they like as long as it is innovative and could be useful to the company.