3 ms·

A couple strategies I've seen work: * have more-experienced CS reps act as "expert reps"; they handle more of the triage & answering routine questions. They're

A couple strategies I've seen work: * have more-experienced CS reps act as "expert reps"; they handle more of the triage & answering routine questions. They're also a valuable information source since they see more questions than any individual engineer. * similar but different: have a point person from engineering responsible for answering & collating questions. This is a tricky role to hire for, since it's not a standard "pull ticket, ship code" setup. This person also typically carries the "user perspective" into engineering planning meetings. * interpret the repeated issues as design feedback. If CS reps are "always getting stuck", figure out what about the UX is causing them to get stuck. If the problems are fixable by the user, can you add messaging to the interface that points them towards a resolution when they get an error? Even better, can you design the system so those errors can't be made? (see also Elm's "make invalid UI states unrepresentable" philosophy)

brudgers 8y ago
Just like some people like answering StackOverflow questions (or posting comments on HN) there are probably already engineers in a staff of 200 who enjoy helping CS, but are primarily assigned other work (and if there aren't any then the hiring process is filtering against hiring engineers who like helping people and that's probably a broken aspect).
sjellis 8y ago
> interpret the repeated issues as design feedback. If CS reps are "always getting stuck", figure out what about the UX is causing them to get stuck. If the problems are fixable by the user, can you add messaging to the interface that points them towards a resolution when they get an error? Even better, can you design the system so those errors can't be made? (see also Elm's "make invalid UI states unrepresentable" philosophy) This is very good advice. Treat the support requests as also being bug reports. The fact that CS reps are not reading the answers that already exist on the FAQ also show that there a system or process failure there. Either the reps don't know about it, the FAQ does not do what the reps need, or they have decided that asking questions is the easiest way to get what they need. Working on tech support, I found that non-technical people are very rarely actually "stupid" (as some technical people are wont to say) but humans optimise for lowest short-term effort: "ask a technical person on Slack rather than read a big bunch of stuff or try to figure it yourself" might be the most efficient solution for them, so that's why they do it. In the worst case, you might have to make your engineers less available and deliberately be a bit less helpful to the reps if you can't offer a better solution and need to protect engineer time.
falsedan 8y ago
Great ideas. We’ve even done something similar to the first point for internal engineer support teams: some permissions/responsibilities are handled/owned by specific teams, who then get a lot of requests/questions about it (ops for restating hosts, release engineering for CI/source tweaks, i18n for translation submissions, mobile for iOS/Android), so we delegate to nominated team members and deputise them with enough permissions to do routine fixes themselves, and let them know we’ll treat their questions as a priority matter (if they are clearly stuck and have read whatever docs they were shown when they were deputised). This comes with the collary that we now expect their team to ask them questions (as a designated deputy), and the delegating team will promptly redirect questions from the deputy’s team back to them: hey how do I <do the thing mentioned in the FAQ>? Oh hi, I think one of your team’s <whatever> deputies is <so and so>, check with them because they definitely know.
jmiserez 8y ago
>This is a tricky role to hire for, since it's not a standard "pull ticket, ship code" setup. Instead of hiring someone extra, you could also rotate the assignment on a daily/weekly basis to one of the engineers.
- Retric 8y ago
  This defeats the purpose of having someone know the answers to repeated questions. Rotating the role ends up with a lot of overhead and some increased turnover as a few people really hate this.

brudgers 8y ago

Just like some people like answering StackOverflow questions (or posting comments on HN) there are probably already engineers in a staff of 200 who enjoy helping CS, but are primarily assigned other work (and if there aren't any then the hiring process is filtering against hiring engineers who like helping people and that's probably a broken aspect).

sjellis 8y ago

> interpret the repeated issues as design feedback. If CS reps are "always getting stuck", figure out what about the UX is causing them to get stuck. If the problems are fixable by the user, can you add messaging to the interface that points them towards a resolution when they get an error? Even better, can you design the system so those errors can't be made? (see also Elm's "make invalid UI states unrepresentable" philosophy) This is very good advice. Treat the support requests as also being bug reports. The fact that CS reps are not reading the answers that already exist on the FAQ also show that there a system or process failure there. Either the reps don't know about it, the FAQ does not do what the reps need, or they have decided that asking questions is the easiest way to get what they need. Working on tech support, I found that non-technical people are very rarely actually "stupid" (as some technical people are wont to say) but humans optimise for lowest short-term effort: "ask a technical person on Slack rather than read a big bunch of stuff or try to figure it yourself" might be the most efficient solution for them, so that's why they do it. In the worst case, you might have to make your engineers less available and deliberately be a bit less helpful to the reps if you can't offer a better solution and need to protect engineer time.

falsedan 8y ago

Great ideas. We’ve even done something similar to the first point for internal engineer support teams: some permissions/responsibilities are handled/owned by specific teams, who then get a lot of requests/questions about it (ops for restating hosts, release engineering for CI/source tweaks, i18n for translation submissions, mobile for iOS/Android), so we delegate to nominated team members and deputise them with enough permissions to do routine fixes themselves, and let them know we’ll treat their questions as a priority matter (if they are clearly stuck and have read whatever docs they were shown when they were deputised). This comes with the collary that we now expect their team to ask them questions (as a designated deputy), and the delegating team will promptly redirect questions from the deputy’s team back to them: hey how do I <do the thing mentioned in the FAQ>? Oh hi, I think one of your team’s <whatever> deputies is <so and so>, check with them because they definitely know.

jmiserez 8y ago

>This is a tricky role to hire for, since it's not a standard "pull ticket, ship code" setup. Instead of hiring someone extra, you could also rotate the assignment on a daily/weekly basis to one of the engineers.

Retric 8y ago
This defeats the purpose of having someone know the answers to repeated questions. Rotating the role ends up with a lot of overhead and some increased turnover as a few people really hate this.