Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent.
It's important for at least the following to happen:
1. Bad issues that engineering will fix don't get stuck in support.
2. Product management review and respond to feature requests, or enable support to respond to customers.
3. Support have a reasonable level of technical and communication skill, and are empowered to answer for the company.
4. The organization works through rather than around support.
What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.
Your role as the back channel is helping to provide some coherence here. However, things can go bad if you left. Inevitably, this is the fault of the company, but when I've found myself in this position I've tried to "promote" people in support to take the lead on this role. Further, formalizing the special request process to be minimally tracked helps visibility with my manager and others. Eventually managers ask why you have become a gopher.
Improving the workflow often involves helping support build relationships with engineering. Management can buy in if support attrition is high (it often is if there is a limited career ladder for support) and it can also improve their perception when people are focused on trimming support cost.
To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."
It seems like this leads to incredibly predictable problems: brain drain, demoralized workers, the bare minimum being aimed for and not actually being achieved, etc.
I feel like a better organization has no "cost centers" - every single role at the company contributes to the mission and to the bottom line. If they didn't, that position wouldn't exist.
What am I missing?
Unless you’re into fraud, “accounting” and “accounts payable” are examples of cost centers. You don’t hire a bunch of innovative people to boost it because it’s not going to ever increase your revenue.
The distinction is made from a strategic perspective because scaling up “cost centers” should be avoided at all costs and scaling up “profit centers” is something you want to do as much as you can.
It has no overlap with “interesting work”. Very often the boring parts of an industry are the profit centers (e.g. in academia the profit comes from packing students into classrooms, not research).
Some examples (that I have seen in reality):
Finance departments are cost centres, until you give them enough resource and they find you a more efficient tax structure. Cut finance departments start to struggle with things like credit control which affects your revenue.
Distribution Centres are usually seen as a cost centre, until you drop spend and it impacts COGS or customer lead times, or inventory in shops raises because of less frequent deliveries and you get out of stocks.
IT is a cost centre, but when funding is reduced change across the whole business slows and other areas are impacted (eg the customer web experience).
In reality the distinction of “some areas generate profit” and “some areas just cost” isn’t true in the end. All areas contribute to profit - some just do so indirectly.
I think the idea of Michael Porters “value chain” is better, where everything contributes to customer value (including indirect functions). The argument this makes is if you see some areas as just cost centres (e.g. fulfilment centres) then you can miss your ability to maximise customer value (e.g. offering faster delivery options).
Even sales people don’t usually generate profit on their own because without the other business areas they would be selling hot air.
You're so, so spectacularly wrong on this, I am honestly gasping for air.
Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?
The biggest companies in the world typically end up with CEOs that come either from sales or from accounting. That is not an accident. Business is about money, and you want smart and innovative people to look after it. Conservative CFOs can be the death knell of a company, among other things.
Support can very much be a profit center. Support personnel is relatively cheap; if their services are priced correctly, they can easily become a stream of recurring income - and everybody knows that "recurring income is best income".
However, this requires efficiency and creativity at the managerial level. It's easier to see support as a burden and just work on shrinking its costs, instead of maximizing its revenues by formulating good price plans. The former is an internal effort that is fairly easy to implement in short timeframes and will easily win brownie points with direct superiors (who doesn't like to cut costs?); the latter requires actual pricing skills and market knowledge, and might take a while to get results. The mediocre manager will always prefer the former.
This sets up perverse incentives, that as far as I can tell, are theoretical, but have potential to become more prevalent. Because of the cost center as a profit center idea, my ISP can generate more revenue by providing less value to me. If failing infrastructure causes me to call support more often, and more support calls increase the likelihood of more revenue, why should the ISP invest in better infrastructure?
The key to having a successful business is to carefully align the incentives of specialities in an organization to make the most competitive offerings to the market. If there are competitors, and customers can switch to them, and the competition is more compelling, then I would go to other ISPs.
"Cost center" can be transformed into something else given both an understanding that support can and should contribute to future sales, and an organization capable of putting that understanding to work.
I have seen a similar scenario in manufacturing where various setup, prep, quality tasks are seen as cost centers and minimized.
Doing this kind of thing has ripple costs. Always.
In a perfect world, we make software, or hardware, and it just works and people grok it.
In the one we live in, these are fantasies and we can choose to understand, recognize the value, or not and get the benefits or not.
The users, customers, move from role to role, and support often determines their willingness to use the product again. That is straight up powerful marketing by referral.
Support often is the first to understand a user, customer needs an option too, or add on, replacement, preventative maintenance. Done right, these leads into lean, consistent sales.
"Cost center" to me has always been a bit silly in this way. There is opportunity to add value throughout the chain of people, process, machines, systems that are all necessary to properly conceive, realize and deliver something to others.
One thing often missed along with failing to understand value is failing to ask to be compensated for it.
Doing things in a robust, high value for the dollar way is not the cheapest way, in terms of raw product price, and depending, size of margin.
But, we do get what we pay for too, and the lowest price often comes with externalities paid by both the enterprise and its customers too.
Sometimes I see this all framed as a luxury. That is just as much of an error, and does come with unnecessary costs and or poor alignment with actual value.
If there are serious UX issues, your designer might not uncover them, but support will hear about it. If there are edge case performance issues, your dev team might not uncover them but support will hear about it. Very few people know more about how real users interact with your products than support.
not much, or everything -
it's basically an accounting term on how you are tracking an expense and so it is very insightful as to how the effort of your project,group,department etc. is perceived by upper mgmt
so "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."
is pretty spot on, if the effort has been (mostly arbitrarily) categorized as such..
when i learned the accounting theory behind it, it suddenly illuminated managment attitudes in current/previous jobs - literally in some orgs overly reliant on this perspective there is literally nothing certain efforts can do through official channels to be viewed as 'valuable' ..
* people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training)
* people unwilling to RTFM, google, youtube, etc.
* people whining when a general purpose tool doesn’t fit their exact workflow to a tee
Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads.
Fact is, people do what they do and they have their reasons.
Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does.
Net happiness goes up too. True for the enterprise and users, people at large.
In my opinion, we had this. They were your senior support staff or were operations; some companies combined this into a formal role called "Support" or "Service" "Operations."
But then we as an industry decided that operations is bad[0] and if you write the code then you can obviously test the code, deploy the code, maintain the code, and support the code. Then every Hip And Cool Start-Up adopted the model of "sysadmins and support staff are bad because we've had bad experiences in the past so we will also have our devs talk directly to customers until they get tired of doing that and we just replace it with a contact form encumbered by CAPTCHA and a no-reply e-mail address."
As someone who has greatly enjoyed, been very good, and very well paid (so my employers agreed that I was good at it), at support and operations roles only to see them disappear into the inky void of Everyone Codes All Of The Time, I am both biased and frustrated.
0 - Because money, I suspect.
I've been heavy in the data space, and get to do some fascinating work with folks, helping design data models, implement analysis, and other things in a wide variety of verticals. It's support, so sometimes there's some more tedious things too - there's no avoiding that. :)
But, and perhaps I'm biased, it's still a great career path, even if it's not as flash as "code all the time" work.
But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles.
When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).
For us, great customer support is one of our stronger sales arguments. In fact we've not had to push hard on sales due to our customers calling former colleagues who moved to a competitor to tell them "you have got to get this software". Having great support has been key to this experience.
Most of our support people have been recruited from our customers, so they know not just our software well but the processes and regulations around it, allowing them to quickly understand the issue at hand and offer relevant help.
So while it might look like a cost center on paper, I'm quite certain it's a massive net gain overall.
Of course as you say, we work hard to mitigate the cost of providing that support, like routinely looking at implementing changes that'll reduce repeat support issues. Maybe as simple as reworking a dialog text, to adding more automation.
We had 'official' faster escalation paths but those inevitably are determined by $$$ and there's always more ways to measure 'important customer' than can be defined / shown in $$$.
Management was totally aware of it all and supportive.
But eventually I got tired of the land of 'support' and moved on for a variety of reasons, mostly because time and again I saw support treated like the usual 'cost center' and I didn't want to be a part of that.
> What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.
The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane.
You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent.
... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it.
An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.
I think if there was a stricter division between support and technical sales, there would be more of a temptation to focus on burning through support requests as quickly as possible. The flip side of this is that it is easy for us to get bogged down in a complex half-support half-sales opportunity situation and that can sometimes cause other support requests to fall through the cracks.
