up one level
---
http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/
What Support is for a Software Support and Development Engineer
One time, my support colleague asked me ‘Can you help Customer X from “Company Y? They have a question about “How to do Z).”
What my support colleague meant was “will you triage Customer X’s concern?”, and the immediate answer was simultaneously “yes” and “I don’t know” — yes I can talk to the customer and investigate their concern — but I don’t know yet until the end of the conversation whether I’ll have to say I can’t help them or whether I’ll be able to directly help them.
90% of support is telling a customer I don’t know, in other words not helping the customer, (maybe/usually with a period of deep investigating into the concern), and the other 10% is doing something towards fixing their concern like reporting a bug, giving a refund or answering a direct question.
It’s beneficial for a support person to realize this, because if one goes in thinking of one’s support job as “helping people” or “answering people’s questions” or “making the solution work for the customer”, that is setting up for anxiety and failure.
It might be more accurately described as support is communicating with the customer about both what my company’s solution can do and what my company’s solution can’t do.
Moving on.
For a Software Development and Support Engineer, support is always unique and is never the same person with the same issue.
Support is never the same issue — it’s a unique person with their own question every time. So then why are they treated as all being “Support”?
The answer is that support is largely a triage channel. The job is to triage and send the bulk of the questions to other departments (sales, engineering, etc.) or back to the customer — or to answer a quick 2-minute question.
Now once one realizes that support is triaging large numbers of unique questions, and sending them to the appropriate place, that is great; one can proceed to focus on doing that, and doing it well.
Something else about support. Any communication from every customer could be considered support and triaged by support — support is equipped to begin the conversation supporting anyone with any issue. Furthermore, salespeople, executives, success people, professional services support people, and engineers all, at times, support customers. But for these communications, they are not support conversations, and for these roles their support is not customer support. Why?
Because support is separating post sales customer requests from other customer requests, based solely on that fact. (The fact that the customer is post-sales — they already bought the software) The people in non-support roles don’t log their conversations into the support case ticket system.
So in other words, support is only limited to: 1.) Cases that are post-sales, and 2.) Cases that came in through the “support” channel.
To recap, “Support” is the fraction of a company’s overall customer support effort that is a one-way triage inbox for post-sales customer requests. After the “support” request hits the inbox it goes through initial triage where about 90% of the requests are forwarded or denied as “the reason it’s no is because ___”, and about 10% of the requests are directly fixed or addressed. Support is communicating with the customer about both what my company’s solution can do and what my company’s solution can’t do.
Edit: This post was previously published at: w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/2016-06-24-what-customer-support-is.php
[2019 edit: Moved to: https://i̶n̶v̶e̶s̶t̶o̶r̶w̶o̶r̶k̶e̶r̶.̶c̶o̶m̶/2016/... .html.]