Ask HN: What's the best way to handle internal tech support?
30 comments
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)
* 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)
> 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.
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.
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.
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.
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).
>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.
Instead of hiring someone extra, you could also rotate the assignment on a daily/weekly basis to one of the engineers.
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.
It does sound a bit abnormal to have gotten that large without a more formal system. But instead of jumping into a big change, which is just as likely to cause organizational stress, it is worth thinking about that - you are somehow mostly succeeding with Slack, with just a few problems. You need refinement of your system, not replacement.
I like your own suggestion of a bot to try to guess the correct question/answer. The first thought that comes to mind to make that would is to build out a wiki and a bot that will try to match up questions to the information in that wiki. Engineers could start a process to put answers in the wiki, and send the link to the asker. The askers can start asking the bot, and the bot can provide a few possible questions and answers back, with an option to say, "None of these are right, ask the engineers".
A system like that would solve your problem, while building the knowledge base needed to self-service information gathering, without throwing your entire process into a big change cycle.
I like your own suggestion of a bot to try to guess the correct question/answer. The first thought that comes to mind to make that would is to build out a wiki and a bot that will try to match up questions to the information in that wiki. Engineers could start a process to put answers in the wiki, and send the link to the asker. The askers can start asking the bot, and the bot can provide a few possible questions and answers back, with an option to say, "None of these are right, ask the engineers".
A system like that would solve your problem, while building the knowledge base needed to self-service information gathering, without throwing your entire process into a big change cycle.
Slack is clearly the wrong tool for the job. You should be answering questions on a persistent Q&A system and force all questions to come through that channel. Larger topics that come up all the time need to be documented on Confluence or something. Remember, everyone thinks that they are special and will come to you directly on Slack or whatever if they have the opportunity. It will waste your time so just close that channel.
I agree. Using an immediate channel like slack is like using gasoline to extinguish flames: the requester has an immediate response no matter how complex is the question.
Also your support process lacks of accountability and this is a huge risk: sooner or later you will need to allocate resources to support and you need both an estimate and a trend.
If you want to keep using slack, use it to record ans triage problems first. Then, use any channel you have to follow up and close.
Also your support process lacks of accountability and this is a huge risk: sooner or later you will need to allocate resources to support and you need both an estimate and a trend.
If you want to keep using slack, use it to record ans triage problems first. Then, use any channel you have to follow up and close.
Treat CS rep (and end-user) questions as bug reports. Almost every time a CS rep asks a trivial question (more so even if it's asked repeatedly), it is a sign that something's wrong in the app's UI; or in the docs; or in the docs' discoverability; or in the marketing/sales messaging (e.g. customer bought a screwdriver thinking it was a hammer). Fixing whatever it is will save everybody's time - end-users, CS reps, engineers, and managers.
Keep in mind you're never going to have a perfect system - call me a defeatist, but you're never going to get the repeat question problem to drop to a point where it's "gone". So first maybe it's good to get a very cold look at the situation and see "how bad is it really?" If the issue is just that the response to the same question being asked is the same copy/paste, it may not be an issue worth chasing down too much.
Information dissemination can be very tough, because a system that works for one person doesn't work for another, so two otherwise equally skilled persons may not find the same information in the same manner. It's very tempting to think you can engineer away this problem, but it introduces many more.
If you have repeat offenders who really are eating up a lot of time for everyone (I'm not getting from your description if other CS also participate in providing answers or if only Engineers do), then it's worth having an educational talk with them. "What did you try checking first? What search terms did you use? What information did you get on the problem first before coming to the channel to ask?" Often times the problem isn't the process in the information store (i.e., your FAQ and Engineers + more experiences CS reps), but in the way that the information is being processed by the CS rep, and how they try to feed that information in their available sources.
To clarify on the sources bit, different systems treat search differently, adding weight to different parts of articles and entries, etc. We switch our internal wiki system over a few months back, and it took awhile to get used to the search on the new system; it offered more granular search arguments, but people had gotten used to the relatively simple Title+Document Content > Title > Document Content search on our previous system. We had to retrain people a lot on how to "search" for information, and also had to really take time to structure the content in our new system to be discoverable by how our team was searching.
So, in short, figure out how big the issue really is. It's never going to be perfect, or even close. For your repeat questions/offenders, investigate - see what the people tried before hand, and figure out if it's an issue with what the CS reps are gathering/presenting or of there is an issue with discoverability in your FAQ/other information systems.
Information dissemination can be very tough, because a system that works for one person doesn't work for another, so two otherwise equally skilled persons may not find the same information in the same manner. It's very tempting to think you can engineer away this problem, but it introduces many more.
If you have repeat offenders who really are eating up a lot of time for everyone (I'm not getting from your description if other CS also participate in providing answers or if only Engineers do), then it's worth having an educational talk with them. "What did you try checking first? What search terms did you use? What information did you get on the problem first before coming to the channel to ask?" Often times the problem isn't the process in the information store (i.e., your FAQ and Engineers + more experiences CS reps), but in the way that the information is being processed by the CS rep, and how they try to feed that information in their available sources.
To clarify on the sources bit, different systems treat search differently, adding weight to different parts of articles and entries, etc. We switch our internal wiki system over a few months back, and it took awhile to get used to the search on the new system; it offered more granular search arguments, but people had gotten used to the relatively simple Title+Document Content > Title > Document Content search on our previous system. We had to retrain people a lot on how to "search" for information, and also had to really take time to structure the content in our new system to be discoverable by how our team was searching.
So, in short, figure out how big the issue really is. It's never going to be perfect, or even close. For your repeat questions/offenders, investigate - see what the people tried before hand, and figure out if it's an issue with what the CS reps are gathering/presenting or of there is an issue with discoverability in your FAQ/other information systems.
We specifically hired a "support engineer" and got lucky finding an excellent person for the role. She understands how software works so can debug strange things without needing developers to get involved, but is also extremely patient and understanding with people that just don't know how to use our tools or have technical issues from clients. Prior to her being here we had a rotating developer system going. That had an upside of forcing developers to learn odd parts of the system they hadn't seen before, but mostly frustrated people since developers didn't like doing that sort of work. We had also tried the Slack bot system, but nobody wants some automated answer or queue when they have a sales call in an hour and need some reports fixed up now. People just learned to skip that and ask developers directly, which was frustrating, but also probably the right decision given the scenario and available options. Some things aren't high priority and our support engineer uses a ticket system to keep things sane, but is still always available as a real person first. Having a real person can cost more than some automated system but in our experience, has been well worth it.
TLDR: Pay for quality.
TLDR: Pay for quality.
Stack Overflow for Teams - might that work? (edit: I had a look at this for us, a team of ~20 devs, with regards to our internal processes and frameworks- unfortunately for us it's a little expensive, compared to the other options)
For larger teams, there‘s also Stackoverflow Enterprise and clones of it as Confluence extensions. The former is pretty pricy, but we are currently investigating whether we should get a license.
Did you find any less expensive & self-hosted alternative to StackOverflow teams?
I'd love to setup one of those for a small group of researchers who use the HPC cluster that I administer.
There are so many repetitive questions about common errors in in-house scientific tools. It would be better to provide a search interface to a local knowledge base before those questions get to me..
I'd love to setup one of those for a small group of researchers who use the HPC cluster that I administer.
There are so many repetitive questions about common errors in in-house scientific tools. It would be better to provide a search interface to a local knowledge base before those questions get to me..
I know there are Hipchat bots that can automatically respond to public rooms based on filters. I've mostly seen them in the context of "Hey, we saw you asking about <product we don't support>. Go ask at <the other team's room>.". If there's something like this for Slack (and I'm sure the API exists if not), that could be a way of integrating the FAQ into their workflow.
It sounds like an area where the organization has scaled past a solution that worked when the company was smaller. I mean, Creating a staff with 1000 knowledgeable and well trained CS reps is probably a ten year process...even if that number was stable and not growing and there was only 10% turnover, there's two new reps every work week.
My first thought is to look at the Slack stats and see which engineers seem to enjoy helping CS and make triaging Slack their job priority for a while with the goal of improving interdepartment communication processes. In my opinion, saying "read the FAQ" is about as helpful an answer as "read the manual" is on StackOverflow...over the long term it's a good solution, in the moment it's bullshit.
Good luck.
My first thought is to look at the Slack stats and see which engineers seem to enjoy helping CS and make triaging Slack their job priority for a while with the goal of improving interdepartment communication processes. In my opinion, saying "read the FAQ" is about as helpful an answer as "read the manual" is on StackOverflow...over the long term it's a good solution, in the moment it's bullshit.
Good luck.
I may be off base here, but you may want to consider figuring out how to optimize flow of work. Analyze common questions and where they came from in order identify specific areas of training to provide to the CS rep, to determine how to restructure your engineering team to include 1st 2nd etc line support. Also think about replacing slack with a ticket based solution to support a more controlled flow of work, prioritisation etc (e.g. You may want to prioritise requests from high value client base). In way this is all a pretty old school way of figuring out how to scale an operation, improve left to right flow, and monitor metrics.
I think Spoke is probably the best solution for your problem because it can plug directly into the Slack workflow everyone is already used to.
Their site is https://www.askspoke.com
Their site is https://www.askspoke.com
> The same questions keep being asked over and over again. There's an FAQ linked in the channel topic and it's automatically posted in the channel every 12 hours, but it's still not enough, we still get tons of questions that could be self-solved without engineers' intervention.
Perhaps make a slackbot that tries to parse and question and return the relevant FAQ link.
Perhaps make a slackbot that tries to parse and question and return the relevant FAQ link.
We have customers with the same requirements and they started using my system at https://helpmonks.com
They are conversing internally with it. You can also use Slack to get notified. If a conversation is worth it they then either use the Trello plugin to create a card there or link to a new conversation in Discourse.
Hope this helps.
They are conversing internally with it. You can also use Slack to get notified. If a conversation is worth it they then either use the Trello plugin to create a card there or link to a new conversation in Discourse.
Hope this helps.
Interesting issue. We had the same issues albeit on a much smaller scale so we actually are building a bot that tries to parse some common words and checks to see if it has been answered by an engineer already and presents the responses.
We could’ve created an FAQ but thought it was cool to do something like that.
We might actually end up with a hybrid solution after giving the bot a go.
We could’ve created an FAQ but thought it was cool to do something like that.
We might actually end up with a hybrid solution after giving the bot a go.
[deleted](1)
We use TinyTracker (https://tinytracker.co) with 6 technical support, 3 customer success and 20 engineers.
If the same questions keep coming up, isn't this a usability issue? Can the user interface or workflow be improved to address this confusion?
https://taskwarrior.org/ could help you.
Holy cow. Jira or Bugzilla.
Close, I'd suggest jira service desk with confluence knowledge base hooked up. As the rep is typing the question suggestions from confluence pages start appearing if none of those help they can submit a ticket. Respond with a confluence page so the next person gets that result over time you have a huge faq.
Currently, all this is handled via a simple Slack channel. This is actually great, since there's no bureaucratic cost to getting in touch, unlike with a proper ticketing system, and having actual public conversations is the fastest way to resolve issues.
But of course, we started seeing inefficiencies in other aspects. The same questions keep being asked over and over again. There's an FAQ linked in the channel topic and it's automatically posted in the channel every 12 hours, but it's still not enough, we still get tons of questions that could be self-solved without engineers' intervention.
So, that made me curious, how are other companies handling this? Could we somehow maybe auto-respond to Slack messages with the correct answer with some bot, or just come up with something that actually makes people check the FAQs before posting? Or is there some way better solution to replace all this?