Ask HN: What's the best way to handle internal tech support?

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)

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.

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.

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.

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)

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.

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

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.

https://taskwarrior.org/ could help you.

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.

Holy cow. Jira or Bugzilla.

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.

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?

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.

We use TinyTracker (https://tinytracker.co) with 6 technical support, 3 customer success and 20 engineers.

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.

> 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.