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

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