Why Customer Success Matters

Introduction

Customers are the lifeblood of any organization. Although many of us tend to believe that customer-service advocacy is a role reserved for talented salespeople, marketers, growth specialists, community managers, and of course the humble helpdesk worker, in fact everyone employed by an organization, from the CEO to the cleaning crew, is a potential customer-service advocate. Even software developers.

Developers must be effective in producing high-quality code and creating systems that make organizations more efficient and leaner, which will improve business processes. As a result, developers are often placed inside a protected bubble and are not exposed to end-users or customers directly.

However, there are organizations out there (often startups) that require every new hire to begin working in the support helpdesk, regardless of the role they were hired to fill. As radical as this might seem compared to a more traditional corporate and hierarchical organization, the fact is that getting people to feel the customers’ needs is a great way to get everyone aligned and in tune with the company’s vision, mission, and direction.

Customer success matters because it pays the salaries and keeps the business moving. Your boss is ultimately the customer.

For a software developer, customer success should mean fewer bugs going out the door, improved sprints and releases, and a better overall customer experience while using the application and software products.

By the end of this chapter, you—as a developer and part of a larger dev team—should understand why having a customer-oriented mindset will benefit the quality of the code you produce and decrease any future troubleshooting efforts. As a dev team member, you should be able to blur the line between what is considered support and what is considered development (coding). This will allow your team to become more agile and to respond better to customer problems.

Isn’t customer service for helpdesks only?

For customers, a helpdesk is the gateway into an organization. It’s the customer’s entry point for raising concerns and having them dealt with—it is not a shield that tries to deflect issues from other departments (especially the software-development team) as quickly as possible.

The helpdesk’s role should be to properly quantify and translate into technical language the information required for the development team to make adjustments or to deliver the correct fixes and solutions to specific problems.

In a perfect world, both the helpdesk and the development team should be able to “talk” using the same technical terms, and both should have a clear understanding of the product and its roadmap. However, this is not always the case.

Table 1 represents a typical flow between the helpdesk and the dev team when an issue is reported.

Table 1: A Typical Helpdesk to Dev Team Flow

Items in green usually happen quickly. The item in orange normally takes a bit longer, given that assigning a priority to a reported issue might involve part of the dev team deviating from a current sprint or from the overall roadmap for a period of time. Most dev teams tend to prioritize on the product roadmap over fixing issues.

Typically, item 4 (the dev team working on the fix) will consume the most time within that flow. The dev team might also require additional information and need to request that the helpdesk ask the customer for extra details, delaying the entire process.

This approach is not only lengthy, but it leaves the helpdesk to manage customer expectations before it knows how much time or effort will be required by the dev team to produce a fix and provide a definite solution. 

During this “fixing” time, the helpdesk can only inform the customer that they are “following up with the dev team.” In the meantime, the customer sometimes becomes tense and agitated.

Going forward, this juncture can negatively impact how the customer will view the company. If the “fixing” process takes longer than initially anticipated, the customer can feel neglected.

So the question is, why do so many software companies keep using this flow?

The answer is that the product roadmap drives the dev team forward. The entire company has bought into the same vision: releasing new software and/or existing software with more features is what drives the business forward.

We should acknowledge here that in today’s competitive landscape, customers are well informed and able to make quick decisions, which leads to increased corporate competition and pressure to stay in a perpetual hamster-wheel race to release the next big thing or the latest feature in their products.

Of course companies must stay innovative, but this process can often lead to customer success being ignored, and if helpdesk issues are not addressed quickly, companies risk losing even longtime customers. One solution is to blur the line between support and development.

Blurring the line between dev and support

In order to respond more efficiently to customer issues and provide faster fixes, the currently rigid views about how to support the helpdesk and dev team need to be reconsidered.

One simple way to blur the lines is to employ software developers at the helpdesk who are not solely interested in working on R&D projects or under a product management structure. Instead, employ people who prefer to work with internal projects or their own projects. Internal projects can be anything software related that helps the organization operate more efficiently or improves internal business processes.

Many prospective employees who know how to program and write code will enjoy this approach and will want to keep doing it.

Companies often make the mistake of assuming that anyone capable of writing code wants to sit behind an R&D structure and under product management. But there are a lot of software engineers out there who excel when working on their own projects, whether they’re internal projects or opportunities to help and mentor others.

Why not tap into this existing talent pool and create a support helpdesk that allows software engineers who are not R&D or product-management oriented to excel in what they love—coding—while also working on internal and individual projects that let them become customer advocates?

If you are a one-person show running a small, independent software vendor (ISV) shop, you will surely be acquainted with the notion of solving critical customer issues and will see it as essential to keeping your reputation and business afloat. You have already blurred the thin line that separates your support and development operations. 

However, if you work for an organization that has one or more dev teams within an R&D and product-management structure, it is likely that the helpdesk will be more traditional in that it includes support specialists (who typically do not create code fixes) rather than software developers.

In practical terms, blurring the line between support and development means having the capability within your helpdesk team to provide product fixes or at least workarounds (code solutions) that can keep customers happy while at the same time keeping the dev teams under the R&D and product-management structure focused on the product roadmap.

Table 2 represents what the typical flow between the helpdesk and the dev team looks like when the helpdesk also employs software engineers who might not be interested in working within an R&D and product-management structure.

Table 2: A Bug-Fixing and Solution-Oriented Helpdesk-to-Dev Team Flow

The flow from Table 2 has the same number of steps as Table 1, however there are two subtle differences.

First note that the premise here is that the helpdesk will do whatever it can within its capabilities (it must employ developers) to provide the customer with at least a workaround (even if that means the workaround or temporary fix is a code fix, e.g., a DLL).

This is done in order to minimize the impact on the customer (less anxiety and waiting time) and to allow the dev team under an R&D and product-management structure to focus on the product roadmap.

Also note that the helpdesk will only resort to the dev team if the customer requires a permanent fix or if they explicitly require the fix to come from the dev team (certified by R&D). However, if the customer is happy with the code solution provided by the helpdesk, there will be no need to get the dev team involved (other than to validate and certify the solution provided by the developers employed by the helpdesk).

The helpdesk also wins, as support specialists who are not coders gain know-how, and developers employed by the helpdesk get to work on an internal project (the customer’s issue), allowing them to put their creativity and imagination to work.

Remember that the goal is to solve the customer’s issue and avoid using the dev team unless strictly necessary.

Why you need to wear two hats

At the end of the day, what customers want are a fast, proactive response and a solution to their problems. They will value that solution no matter where it comes from.

Winning your customers’ hearts requires agility. When you engineer your support helpdesk to act as a Customer-Oriented R&D (CORD) by employing software developers as part of the helpdesk, you will not only close issues more quickly, but you keep your core dev teams on schedule.

Table 3 represents the advantages of employing this mentality within your organization’s helpdesk.

Table 3: Comparison of Traditional and Customer-Oriented R&D Helpdesks

It’s important to understand the huge impact that both approaches can have on your business. When you have a helpdesk that enjoys the challenges of reverse engineering an issue and providing a custom fix (that is not dependent on the dev team under an R&D or product-management structure), your organization suddenly becomes incredibly agile and able to respond more quickly to customer issues while still accelerating development under the product roadmap.

The key differentiator of both approaches is that when operating in the traditional model, apart from configuration problems, your helpdesk will require input from the dev team (for anything code related, which means any time an urgent customer issue involves a code fix, you risk breaking the momentum of the dev team working on a sprint).

With the CORD approach, your helpdesk is empowered by developers who do not necessarily like the hustle of sticking to a rigorous roadmap—instead they love hacking code and coming up with innovative solutions. This allows the dev team to focus exclusively on their roadmap.

Summary

We’ve seen how making a small change in how we view a traditional software helpdesk could revolutionize your organization, allowing you to be more agile and to respond faster to customer issues while sticking to your roadmap without major deviations.

We’ve introduced this mindset so that we can next focus on how this approach can be semiautomated with some customer relationship management (CRM) code classes and some reverse engineering.

Later we’ll explore tactics and opportunities for customer service that can help grow your business and company value.