Customer engineering: not (just) customer support!
The difference is more than just salary levels
For over a year now I’ve been talking about building and leading technical support teams. But one thing that always comes up when I’m speaking with folks who aren’t as familiar with customer engineering is: how is this different from ‘customer support’? To those of us steeped in the tech world, the difference is clear. But I think it’s worth talking through, if only so you have a better response to your well-meaning relatives at Thanksgiving who seem to think you work in a call center. Besides, if we’re not clear on the difference, how can we expect anyone else to be? The same information you give to Great-Aunt Edna at Thanksgiving can be employed as ammunition to your slightly confused CFO wondering why your team costs so much ’if it’s just customer support’.
Side note
Before anyone complains, I know I’m conflating customer service with customer support here—I know they may not be exactly the same thing, but a) even if they are different the definitions are pretty fluid; b) from the perspective of customer engineering they’re close enough to the same anyway; c) this is a newsletter about customer engineering, not customer service.
Similarities
To be fair to Great-Aunt Edna, customer support and customer engineering are not entirely dissimilar. In fact, if you squint, they have a lot of things in common.
Customer-facing: both roles have customer interactions as their primary focus.
Charged with solving problems: both roles are charged with solving a wide variety of problems coming from customers.
Standing by: when you call a customer support line, you expect someone to pick up if you’re within business hours, or sometimes even 24/7. When you email tech support, you expect a response quickly as well. Both roles have an emphasis on availability so customers aren’t left hanging for long.
In charge of customer happiness during stressful situations: customer support and customer engineers are dealing most of the time with customers who are experiencing problems. This is by definition a stressful situation. They need to solve problems, manage customer emotions, and try to emerge on the other side with a satisfied or even pleased customer. This puts them front and center in any customer retention discussions across the company.
Differences
But this takes the similarities about as far as they’ll go. Perhaps we’ve taken them too far, but I want to stay on Great-Aunt Edna’s good side. There are two major differences, in my opinion, between a good customer service person and a customer engineer: technical expertise and open-ended troubleshooting autonomy.
The first one, technical expertise, I don’t think I need to talk much about. To be a customer engineer, you need to know the specific product you’re supporting, as well as any adjacent products and technologies that are often paired with your company’s product. While a customer engineer may spend a lot of time handling issues they’ve seen before, they’re perfectly capable of investigating novel situations. By contrast, a typical customer service person has, and needs, minimal deep technical knowledge, because they’re not expected to solve complicated customer problems. The range of subjects they’re expected to be able to address is much more limited, and there’s probably a detailed playbook or even script for them to use for each of them. If they’re in a more support-focused role those playbooks may be more expanded, but they’re still there, at least at the first customer-facing level. When a customer arrives with a problem they can’t solve, then they get escalated to higher-level tech support or, in some cases, the return/refund or warranty replacement department. The person answering the phones is probably not going to be the one to solve your problem if it’s anything at all complex, because that’s not their job.
The second thing I mentioned, open-ended troubleshooting autonomy, needs some unpacking. It goes back to customer support not being expected to solve every problem themselves. Any troubleshooting they do is going to be entirely constrained to what’s written in their scripts and playbooks, and anything that isn’t resolved by going through the established process is going to be escalated elsewhere. A role like this doesn’t have autonomy to do open-ended troubleshooting, but has to stick to the script and stick to the topics they’re authorized to cover.
Another implication of open-ended can be found in the expected resolution time of issues. For your typical customer support, agents are expected to resolve and close issues as quickly as possible, to get on to the next customer issue. Metrics are collected and agents who are too slow are retrained, or removed from the role. But in customer engineering, it is generally understood that the issues they’re working on won’t often fit in a clean volume-based model. Some of the questions that come in, to be sure, can be addressed and resolved with a single response, but many can’t. And when you’re starting to troubleshoot a novel issue, you often have no idea whatsoever how long it’s going to take to resolve. How could you? It could be a misconfiguration, a customer’s dramatic misunderstanding of the product’s capabilities, or a serious bug. It could be something that’s actually a critical security flaw that you need to open a production incident about. In the first stages of troubleshooting, you just don’t know. How can that fit into a model of high-velocity ticket closure? Customer engineers need the autonomy (that word again) to take the time they need to fully investigate and resolve their customer-reported issues.
This isn’t to say there’s no time pressure on customer engineers! Even though a good customer engineering team doesn’t put too much importance on resolution speed, that doesn’t mean customer engineers can waste time. Indeed, the support issues that they are often dealing with are of critical importance to the customer—if a mission-critical workflow is completely broken due to your product, there’s going to be a lot of pressure to address it as rapidly as possible.
The take-away
So what have we learned from this extended compare-contrast session? Well, with all respect to Great-Aunt Edna and with even more respect to folks who work in customer support, the two superficially-similar titles conceal very different underlying purposes. Customer support is aimed at making enough customers satisfied, enough of the time, in a high-volume environment where speed is the most important consideration and autonomy is limited. Customer engineering focuses on deeply understanding and resolving customer issues without a specific ticket closure metric, owning the customer issue for the lifetime of the ticket, and roping in additional assistance as necessary.
The next time anyone asks you what your team is doing that’s so different from, say, your cell provider’s call center, now you have a ready answer: it all comes down to expertise, autonomy, and (most importantly) open-ended troubleshooting. You’re welcome!
Thanks for reading Andy's Support Notes 💻💥📝!