B2B and SaaS Customer Support: Best Practices for 2026

Several people per account

Gartner, a research firm that surveys businesses and advises executives in about 90 countries, found that B2B buying groups now range from five to 16 people across up to four functions. Many of them write to support after the sale. When three users from one company report problems in the same week, someone on your team should see the pattern.

Customers expect you to know them

In a separate Gartner survey of more than 5,800 customers, 86% of B2B customers expected a company to be well informed about them during a service interaction. For consumers, the figure was 71%.

This changes what your support tool has to do. Whoever answers, a person or an AI agent, needs the account's plan, setup and recent history next to the message. Much of that lives in your own product database, outside the support tool. The good setups read it live, so nobody has to ask the customer for their workspace ID.

Contracts and response times

Larger customers write response times into their contract. Those service level agreements turn speed into an obligation, and consumer brands keep raising the bar. McKinsey, the management consultancy, found that B2C companies typically score 65 to 85% on customer experience, while B2B companies average below 50%. In their words, consumer expectations of speed "are migrating to B2B."

I haven't found solid research that measures how much a slow reply raises B2B churn, so be careful with precise numbers you see online. The direction is clear, though. As Jeffrey Schott of Gartner put it, customers "will leave or stop purchasing from a company because of service failures." A reply that comes days late is one of those failures.

Bugs and feature requests leave support

Both need a ticket in the tool engineering works in, with the customer linked to it. In our sample, 82% of bugs and feature requests were linked to a Linear issue. That link is what lets someone tell the customer when the fix or the feature ships.

Paul Graham, co-founder of the startup accelerator Y Combinator, calls this contact with users a necessary part of the feedback loop that makes the product good.

1. Answer from the product

The correct answer to a SaaS question depends on how the product works. Help articles describe the common path. The code defines every path. Give your team, and any AI agent you use, product knowledge deep enough to explain an edge case.

For example, an admin asks why a custom role can view a report but can't export it. The answer names the separate export permission and links to the role settings. The admin turns on that one setting and keeps the role's other limits in place.

2. Make every answer low effort

Matt Dixon led a study of more than 125,000 customers at CEB, a research firm that is now part of Gartner. Customers with a high-effort service experience were far more likely to turn disloyal: 96%, against 9% after a low-effort one. His Harvard Business Review article with Karen Freeman and Nicholas Toman sums it up: customers want a simple, quick solution to their problem.

For example, a customer asks how to rotate an API key. A low-effort reply gives the three steps and the link to the settings page. It also says how long the old key keeps working, which answers the next question before they ask it.

3. Set SLAs per plan and severity

Agree on first response targets for each plan and each severity, then look at how large vendors publish theirs. Atlassian promises a first response to a critical cloud issue within 2 business hours on Standard and 30 minutes on Enterprise. GitHub Premium Support answers urgent tickets within 30 minutes. Write your targets into your support tool so the queue sorts by deadline.

For example, a payroll software company promises enterprise accounts a first reply within one hour when a payroll run is blocked. A failed export from such an account moves ahead of routine setup questions.

4. Keep account context on every message

Show the company, plan, contract value and open issues next to each message. An agent who sees the third bug report from the same account this week can mention the earlier reports and raise the priority. So can an agent who sees a renewal next month.

For example, a support engineer opens a ticket about a seat limit and sees that the account bought more seats yesterday. The engineer checks the billing sync instead of sending upgrade instructions.

5. Write the help center from real questions

The questions customers ask show you the gaps in your docs. The Knowledge-Centered Service method builds on this idea:

Self-service often fails at exactly this point. In a Gartner survey of 5,728 customers, the most common reason self-service failed was that customers couldn't find content relevant to their issue, in 43% of cases.

For example, a support lead finds several solved conversations about webhook signature checks. They turn the tested steps into a help article with a sample request. The next admin checks their webhook with that article before writing in.

6. Send bugs to engineering with the customer attached

When a conversation turns out to be a bug, file it in the tool your engineers already use. Link the issue to the conversation and the account. Engineering then sees how many customers hit the bug and how much revenue sits behind it.

Collect the details engineers need before you file. Researchers at Saarland University and the University of Calgary asked developers and users of Apache, Eclipse and Mozilla what makes a good bug report. In 466 responses, they found "an information mismatch between what developers need and what users supply." Developers most wanted steps to reproduce, stack traces and test cases. Users found exactly those hardest to provide. Support sits between the two, so ask the customer for the steps while the conversation is still open.

For example, a support engineer traces a calendar sync failure to a date parsing bug. They file an issue with the failed request, the linked conversations and the affected accounts. The engineer who picks it up can reproduce the error without asking each admin for the same details.

Then let engineers answer where they already work. Atlassian surveyed 3,500 developers and managers for its 2025 developer experience report. Developers spent only 16% of their time coding, and half lost more than 10 hours a week to friction. Collaboration with other teams had moved up the list of causes. In a lab study at the University of California, Irvine, Gloria Mark and her colleagues found that people make up for interruptions by working faster. The price is more stress and frustration.

So bring the customer to the engineer. When a question reaches engineering, the conversation should appear on the issue. The engineer's reply should go back to the customer on the channel they wrote in.

7. Tell the customer when it ships

Rob Markey, a partner at Bain & Company, calls this the "outer loop" of customer feedback. Once a fix is approved, his advice is to let the people who initially raised the issue know what the resolution was.

Gartner found that proactive messages raise how much value customers see in a product. It also found that 82% of B2B customers contact the company after such a message. So write it to answer the obvious follow-up: what changed, and what the customer should do now.

In our own inbox, 70 conversations in the sample were linked to an issue that shipped. 65 of them got a message after the fix went live. Our automatic follow-up sent 51 of those within a minute. When a teammate wrote the message instead, the median wait was about an hour.

For example, an admin reports that CSV exports leave out a custom field. When the fix ships, support replies with the release date and asks the admin to run the export again.

Linear: engineers on a weekly rotation

Practices 6 and 7

Linear, the issue tracking company, published how its customer experience team works. The CX team triages every request. Bugs go to a "goalie", a role that rotates each week:

When an issue is marked Done, an update goes back to the conversation it came from. The team then confirms the fix with the customer.

37signals: everyone on support

Team structure and practice 6

37signals, the company behind Basecamp, ran a program called Everyone on Support. For one day a month, every designer and programmer answered customer emails, so everyone in the company talked with customers on a regular basis.

Kayak: engineers who fix the cause

Practice 6

Paul English, co-founder of the travel search site Kayak, put engineers on support. As English told Inc., quoted by 37signals, after the second or third identical question, engineers would stop what they were doing and fix the code.