In today’s competitive world, providing exceptional customer support is critical to ensure customer satisfaction and loyalty, both core items helping minimize customer churn. This is becoming a significant item of focus as customer churn is a very important, and costly, item.
For example, the cost of acquiring new customers is commonly 5-25 times more compared to keeping existing customers. That paired with the economic climate, potentially declining sales and constant push to drive down costs, puts the business in an awkward situation.
However…
One of the problems with historical customer support is there is little to no coordination between support and other customer-facing teams (e.g., sales, product managers, customer success, etc.) leading to a very poor customer experience which can eventually lead to churn.
Support is not a team but something that must be looked at holistically. Yes, there may be a dedicated support team, but all need to work in synchrony to ensure the customer’s experience is amazing.
In this article we will look at what the current state of support looks like and how this affects the business. We will then look at what one ideal option of support may look like and how it may provide benefit.
Status Quo
If we look at the history of support, it wasn’t originally seen as a strategic role, it was done out of necessity. Customers will inevitably have problems, and it is too costly for product/engineers to support them (this still happens early stage). Hence support was introduced to help triage customer problems/requests, assist and then only when necessary ‘escalate’ to product/engineering.
The current model of support is almost wholly focused on a dedicated support team, or teams (e.g., L1, L2, L3), with minimal structured coordination with other customer-facing teams (e.g., engineering, sales, etc.). In certain cases, there may be a customer success team that acts as a coordinator and mole helping with up-sell/cross-sell. In some cases, support may report into customer success; in others, they may report to completely different entities. Note: this divergence is something that should be avoided at all costs.
When looking at a “dedicated” support team you either have a Support Team or a Customer Success Team, or potentially both depending on your scale.
In the scenario where there are dedicated Support and Customer Success teams, there are a few things to highlight:
Support
- Reporting
- Commonly reports to the COO or equivalent depending on the scale of the business
- In certain cases reports into Customer Success (good), but this is not always the case
- Focus
- Focuses on helping customers with technical problems (e.g. tickets)
Customer Success
- Reporting
- Commonly reports to the Chief Customer Officer, CRO, Head of Sales or equivalent
- Focus
- Act as a liaison and helps coordinate across teams
- Help customers with strategy
- Acts as an AE for smaller customers
- Help generate opportunities for cross-sell/up-sell
Now I’m not going to argue about whether customer success is just a rebranding (or expansion) of support (or should be) or the need for both. There are plenty of opinions there, and my goal isn’t to slander but enable you to decide what is best in your situation. I see value in the role that Customer Success provides which is a single entity to coordinate teams, and a “mole” to help with cross-sell/up-sell. The key question is is this a dedicated role or a role everyone interacting with the customer should express. Hint: I believe this should be both a team and role everyone expresses.
An Example
Have you ever had an experience where you’re told contradicting statements from a vendor? Have you ever had a support experience where you’re “escalated” and have to explain yourself all over again? How was that experience? Likely pretty poor. This is no different than what the lack of internal coordination between support and other customer-facing teams causes.
For example, say a customer was told by their sales rep that a certain feature will be coming within the next few weeks. After some time the customer files a support ticket to get an update on the status of this feature as well as asks their rep what is going on. In most cases the rep and support engineer don’t communicate or have the context of what the other is doing (let alone access to the other’s system). The support engineer may respond saying that feature is a long ways away, while the rep may say it’s “coming soon”.
This lack of coordination leads to contradiction and a clear indicator to the customer that the vendor obviously has some problems internally. Do you think the customer will be happy? Do you think the customer will trust what the sales rep says in the future? Simply put, no.
Now, let’s handle this a little differently and look at the result…
In this scenario, let’s say the customer files the same ticket and asks their sales rep for an update. The support engineer working on the ticket and the sales rep communicate with each other and determine the best way to respond to the customer and send a consistent message to the customer. Yes, this sounds simple, but you’d be surprised how frequently this doesn’t occur. How will the customer’s response differ? They still may not be happy that it isn’t done, however, it won’t erode trust and spawn additional concerns about the vendor.
Here’s the key: each one of these individuals will interact with the customer at some point in the lifecycle, which is why things need to be looked at as a cross-functional team vs. just a “support” team.
So what are some of the problems with this model?
The problems with status quo
In this model your faced with a few core challenges:
Misalignment Customer Support and Customer Success may care about different things (they shouldn’t) and may have a different reporting structure (e.g., support to eng or CS to sales). This means there is a potential for misalignment of goals/priorities which may lead to teams focusing on different things. This holds true for the extended teams that interact as well. For example, you could be reporting on metrics the teams care about and have good metrics, but the overall experience can be lacking. This lack of unifying metrics and goals causes focus that may not align with what it should.
Silos Departmental silos and lack of cross-functional goals/teams leads to both knowledge and focus gaps which can lead to inefficiency. In some cases people may use these gaps to control knowledge. However, this does not benefit the business or the customer experience.
Inefficiency
Given the lack of coordination and gaps in systems/access a lot of things are “thrown over the fence”. This means handoffs are commonly done at a system level which intoduces a ton of inefficiency which can be even worsened if there is no access across system boundaries. For example, take a look at the Scenario outlined HERE
Poor/inconsistent customer experience Given that teams are likely not coordinated and they don’t have access across systems (e.g. support doesn’t have access to CRM data or vice-versa), the experience may be very inconsistent. For example, say a customer has a problem and creates a support ticket, in most cases there is nothing that notifies the sales rep on the account for the customer (some may have this).
Now say there’s a large opportunity (in the CRM system) that the sales rep is working on, as a support engineer how would that impact how you handle the interaction? Sure, ideally you should handle everything with the upmost professionalism and brevity, but, let’s be honest, that doesn’t happen and people get busy. Having this information, you can ensure it has the adequate prioritization and care to ensure that this support experience can be seen as a “selling point.”
How to Enable
Getting a single team to work effectively is complex, and cross-functionally is even more difficult. However, the benefits of establishing this approach can be astounding (both internally and externally).
Here are some essential items to enable this:
Ensure You have the correct cross-functional structure in place
Systems and integrations can solve the data/context piece, but having the proper processes, reporting structure and metrics is equally essential.
Minimize finger pointing by establishing a cross-functional team with a reporting structure that makes sense. Who should “own” the team? Sales, Support, CCO, CPO, COO? This will vary from company to company, but ensuring that there is one place that the cross-functional team reports to is key to ensuring priorities are aligned and things are looked at holistically. This doesn’t mean management reporting structure, but function reporting structure. Without a structure, cross-functional team charter (aka mission statement) and established process, this will fail.
If you have both a Customer Success and Support team, ensure that the Support team reports into the CS team. This will ensure Support’s metrics are aligned with Customer Successes.
Commonly each team has its own metrics and KPIs that they track; however, as a cross-functional unit setting the right metrics and KPIs is key. For example, metrics like time to first response, time to resolution, CSAT, etc. should be core metrics for all members of the cross-functional unit (not just the support team). Additionally, things like up-sell/cross-sell rates, win rates to CSAT scores are all crucial for the unit as a whole. For example, why can’t a PM or AE be the first to respond to a customer inquiry? It’s simple, they can and should.
Ensure access across system boundaries
Depending on the function you will commonly see a bunch of different systems:
- Support
- Ticketing system (e.g. ZenDesk, SFDC ServiceCloud, DevRev)
- Chat system (e.g. Intercom, DevRev)
- technical
- Issue management system (e.g. Atlassian Jira, Linear, DevRev)
- Sales & Marketing
- CRM system (e.g., SFDC CRM, DevRev)
All involved parties inherently have access if you have a single system across these functions. While this is not the common case, there are some tools like provide this experience:
- DevRev (support + chat + issues + CRM)
- SFDC (support + CRM + chat (sort of via Slack))
If you have disjointed or disconnected systems, it’s imperative to either provide access across these functions (common case but costly), or create automations to sync data between different systems (costly from a time and maintenance perspective). One of the problems, is that most systems involved here are licensed on a per-seat basis, which means provisioning accounts for a user in each system can be very expensive.
If systems are disjointed, integrate
As mentioned above, very few platforms provide everything you need in one place (nor would likely displace all systems in a single moment anyways). So some form of integration is usually required.
In this disjoint system approach, ensuring the integrations between systems are key. If you’re using DevRev for support/chat/issue management and SFDC for CRM, you’ll want to have the ability to sync data across these system boundaries. Here opportunity data from SFDC could be used to augment the customer account in DevRev and augment tickets/issues with opportunity data (e.g., amount). This allows support to have visibility on customer size and opportunities and product management to use revenue data to drive prioritization.
Similarly, you may have an integration that pushed some customer ticket data into the CRM system for sales visibility (or at least notifications).
The key is that some level of integration is necessary between systems to provide visibility without requiring people to look in different places unless you have a platform that handles these in a converged manner.
Why change
This will help facilitate the following:
- Interactions are coordinated and consistent
- Hand-offs are handled correctly
- Customers won’t get tossed around or told different things by different people
- Customer experience is much better
- Extended “support team” experience is much better given all have context and are “in the loop”
So what, how does this help my business? Well, can you afford to lose customers (churn)? What if sales start to decline?
It’s not a new concept that churn is costly and repeat business is a massive revenue generator. Now, there are a few ways to retain customers:
- Have an invaluable product –> something so good that they can look past poor support
- Ensure customers are taken care of –> provide an amazing support experience
- Lock them in (this should not be considered a strategy)
TL;DR
- Support is not a team, it needs to be looked at holistically
- Embrace cross-functional teams and coordinate
- Ensure context/system access across teams
- Turn support into a revenue generator by approaching it differently