Your credit report has changed.
That’s the subject line of an email you receive from a popular credit monitoring service.
Expecting praise for aggressively reducing your debt, you’re surprised when you open it. The email reads:
It looks like there is a change to your TransUnion credit report.
You fell behind on payments on one of your accounts.
Do you recognize this new information?”
So you check your credit report with TransUnion where your suspicion is confirmed. There are no missed payments.
You reply to the email asking for an explanation. When support writes back, they ask for information to verify your identity: full name, social security number, date of birth.
Two days later you receive an auto-generated email. Apparently, your request was solved.
Annoyed, you reply again—this time to demand an answer. Instead of providing one, the rep follows up by doubling down.
He sends a lengthy canned response detailing how credit scores are calculated and says nothing of the company’s faulty notification emails. You decide to double down too—by deleting your account.
These scenarios happen often. And it’s not because support reps enjoy unproductive conversations.
It’s because customer service and product only engage when they must.
The customer service and product predicament
Support and product have a great deal in common. Both teams work to create positive user experiences and both know the product better than most of your organization.
They’re also not strangers. According to Tony Ulwick, pioneer of the jobs-to-be-done theory, customers “hire” products and services to perform specific jobs.
When those jobs aren’t delivered as expected, customer service serves as a safety net—a way for companies to bridge the gap between what customers need and what they’re actually getting. In practice, this often includes:
- Completing a task internally that customers can’t (or asking the product team to)
- Reporting an issue to the product/engineering team for a fix
- Compiling and communicating customer feedback as feature requests
But in spite of their inevitable contact—and proximity to the product—most customer service and product teams don’t share their knowledge to proactively improve the customer experience.
Instead, their relationship is one of imminent need, with both teams poised to react. Support reacts to product issues by funneling them to the product team. Product reacts to support requests by triaging problems, and, in many cases, tasking a developer with finding a fix.
This dynamic can sustain companies with a modest customer base, but as a business grows, a purely reactive relationship can become trouble. In extreme cases—like when a company’s product consistently fails to “do its job”—both teams grow to resent each other for impairing their respective productivity:
- Customer service teams can view product as indifferent to their perspective. Whether they’re following up on bugs or much-awaited product features, their ability to provide customers with solutions often depends on timely responses from the product team.
- Product/engineering teams can also see support as indifferent to their plight. Whether they’re trying to make sense of badly written bug reports or wading through unfeasible feature requests, their ability to balance ongoing development needs with unexpected product issues depends on clear and concise briefs from support.
Amidst these tensions, customers suffer, products stagnate, and members from each team like their jobs (and each other) a lot less.
Worst of all, the gap between what customers want and what an organization can deliver widens, paving the way for competitors with similar solutions—and better alignment between teams—to gain market share.
Here’s the good news: When they join forces to navigate customer problems before they happen, product can build better, support can serve better, and your organization can earn a reputation for being customer-centric, the ultimate in competitive edge.
1. Streamline and standardize bug reporting
Bugs are more than an unavoidable part of doing business. They’re a considerable source of tension between customer service and product.
As the folks on the frontlines, support wants bugs fixed as quickly as customers do, but on-the-job pressures frequently get in the way. From managing first-response times to obtaining the information needed to file a report, support reps remain stretched across multiple tabs and systems.
Product teams don’t care about this when they receive mind-bending bug reports. They care about getting the information needed to replicate the problem. When support fails to deliver it, they push the issue back—usually to an overwhelmed agent who hoped they were clear enough the first time.
Whether the steps to reproduce are too vague, or there’s two separate issues crammed into one ticket, too many support reps waste time writing bug reports the product team hates reading.
Here are two ways to solve it:
Re-configure your bug reporting tool
To produce bug reports the product team can act on quickly, support teams need a seamless process. Every input should be programmatic—like autocomplete drop-down menus—so that reps don’t waste time thinking about what to enter where.
Manual data entry should only happen in one field: steps to reproduce. For added clarity, instruct reps to conclude each report with both an Expected result and an Actual result.
Consider investing in something more robust if your current tool can’t connect with other systems or allow the flexibility to build reports around products or features.
Re-think product development resources
Product teams must balance bug and code management with new product development, which is no easy feat.
Some engineers view debugging as valuable experience that helps them grow into better developers. Others see the process as a time-consuming chore better left to junior employees. Then there’s the folks who only enjoy the thrill of cracking something mysterious.
Your organization likely has all three on its product team. Depending on their backlog, they have a few options:
- Build sprints or releases that only target code stability and bug resolution
- Use a rotating schedule so everyone has a turn handling bugs for a predefined period
- Consider hiring a full-time QA engineer so someone’s always on the hunt for defects
Products inevitably break in ways big and small. To reduce downtime for customers, every business should strive to resolve these issues as quickly as possible. To do so, they must reduce friction for employees first.
2. Encourage data-driven feature requests
Feature requests can also foster tension between support and product.
Without visibility into big-picture goals, customer service reps can easily champion ideas about features they believe will make a huge impact—even when product knows better.
They may even frame their ideas as fully realized quick-fixes that product can “easily” address without realizing other dependencies.
For product teams, this lack of awareness breeds skepticism around support-driven feature requests. Left unchecked, they begin to see support’s feedback as anecdotal or too driven by emotion—and they can become dismissive as a result.
To shed these perceptions, customer service and product must align around what makes an irresistible feature request.
Here are two starting points:
To get their requests taken seriously, customer service should validate their product recommendations with data as much as they can. There’s a few ways to approach this:
- Track how many customers have asked about feature X within a time period
- Create a “product feedback” category for negative CSATs
- Use custom CRM fields or helpdesk tags to flag tickets with related products or features
Any of these options can help your support team identify which products or features create the most friction for customers. Attaching these data points to feature requests will help the product team understand the business case behind them.
Context that describes, not prescribes
Product development isn’t just about adding new things. It’s about identifying a customer’s problem and devising elegant and holistic solutions.
That’s why product teams are more receptive to feature requests that describe the problem associated with an ask. They don’t need support reps to prescribe a solution.
Here’s the difference:
As a user, I should be able to return to the app from the dashboard so that... Put a ‘Back to app’ button on the dashboard
When support defines the problem rather than commanding a specific solution from product, it signals they understand there’s more to consider than the immediate need at hand.
While support teams should never dictate product actions, they can and should use descriptive context to build recommendations that ideally reduce the volume of certain ticket types.
3. Choose a system for capturing feedback
How customer service curates feedback is just as important as the feedback itself.
For small teams, this usually starts in spreadsheets—maybe a Trello board if they’re fancy—but if your team supports several high-profile enterprise clients or a global customer base, these makeshift methods can get messy fast.
No matter how hard your team strives to make them all-encompassing, it will be impossible for product—or support, for that matter—to grasp the full picture without toggling between several systems.
This may not seem like the end of the world, but it’s not scalable or efficient. In their analysis of how innovative, high-performance organizations get ahead, Slack found they share three traits in common. Employees at these companies:
- Prefer user-friendly tools that foster open communication and provide the context for decisions
- Embrace innovation and the open platforms that make regular innovation possible
- Put customers first by equipping their teams with the best tools to do so
For an organization’s customer service and product teams, this means investing in purpose-built software that not only captures product feedback, but can also quantify it and connect meaningfully with the systems these teams already use.
4. Build transparency with regular meetings
The best support reps know the product as well as the product team. In some cases, they may even know it better. It’s what they don’t know that hurts them—the bigger picture and all of its requisite complexities.
Regular meetings can solve for this. In addition to building rapport, they enable a company’s customer service and product squads to build trust through transparency.
Here are a few ways to leverage support and product team meetings:
Train new agents on features and functionality
While your team can certainly train reps on how to perform certain actions, product can provide broader context into a product’s origin, evolution to-date, vulnerabilities, and shortcomings—highly valuable context that new and existing reps can use to personalize their interactions and speak with authority.
When support reps understand a wide variety of use cases, they’re better able to set customers up for success.
Provide clarity on product complexities
Some product features may be inherently complex, but customers expect support reps to be experts regardless. When they’re not, your customers will react in one of two ways:
- Assume your support reps are unprofessional or unprepared. They’ll also assume this is a reflection of how your entire company operates.
- Assume your product is too difficult to use. If employees struggle to understand it, they may believe they will, too.
They’re also likely to leave the interaction confused and upset about devoting time to an unproductive conversation—especially if support provides inaccurate information.
By making it a priority to turn support reps into bonafide product experts, organizations can ensure meaningful, quality service.
Get ahead of support documentation
As a product evolves, support must do more than learn new features and functionality. They’re also on the hook for creating and updating FAQs, email macros, and any other messaging they use to educate and inform customers.
Meeting regularly with product to discuss the product roadmap and coming updates enables customer service to get the information (and screenshots) needed to get a leg up on support content.
School product on adoption and trends
Product teams may have their own means of identifying user engagement, but the qualitative feedback support can provide them with can pack a greater punch than numbers alone.
Customer service reps can share data about which products generate the most questions or confusion, what sorts of questions customers ask, and what feedback they’ve volunteered.
Given the opportunity, product can ask questions about feedback and gauge how to prioritize feature requests with respect to their roadmap.
5. Involve support in new product development
Consumers have ample options. If you need a ride, you could hail a cab on the street, but you could also use Uber or Lyft to pre-arrange a pickup. Need a help desk? There’s Zendesk, Freshdesk, HelpScout, and HappyFox, to name a few.
With so many businesses banking on similar solutions, true product differentiation is the stuff of unicorns. For most companies, increasing their focus on customer service is enough of a competitive edge.
But when organizations promote customer experience initiatives, they often overlook the relationship between product design and customer service. Worse, they rarely involve support in the design process.
According to several studies, these businesses miss out big time.
The most innovative companies acknowledge the relationship between a customer’s “cost of ownership” and a product’s “serviceability.”
Low cost of ownership for customers High serviceability for business
Product is intuitive and easy to use Fewer support tickets and less hand-holding
Product satisfies obvious needs and delivers on needs they may not have anticipated Customers more likely to share praise and “nice to have” feedback that inspires and informs product team decision-making
Organizations that don’t regard customer service as crucial to the product design process usually face very different circumstances:
High cost of ownership for customers Low serviceability for business
Product “too hard” or confusing to use Support struggles to help customers achieve their goals
Product too often fails to “do its job” Product struggles to create or maintain the solutions customers need
When product makes use of support team insights before building or scoping a new product, they’re able to design for real needs instead of perceived ones.
Products consciously designed for ease of use often stand out as an obvious choice in a sea of options. Like the original iPhone, they may even help to redefine what customers expect from a product.
The goal of customer service and product alignment isn’t just to build a better product, but to build a better relationship between teams. To get there, both teams must do the work.
To help at the organizational level:
- Provide integrated, user-friendly tools for both teams to communicate
- Close product knowledge gaps with ongoing training
- Open the door to the product roadmap so support is always prepared
- Share customer data to help the product team make customer-centric decisions
Enjoy this post? You may also like these: