Basecamp dropped live chat from their support operations. Support volume didn't spike. CSAT didn't drop. In fact, satisfaction improved. Their support responses got longer, more thoughtful, and more thorough because agents weren't racing to type fast enough for a chat window.

Co-founder Jason Fried has described the logic: when support is async, the agent can think, research, and write a careful response. When it's live chat, they're performing.

This is the case for slow support. Not slow as in "we take a week to respond." Slow as in "we take enough time to get it right the first time."

The Speed Trap

The industry obsession with speed (first response time, handle time, time to resolution) creates a perverse incentive. Agents optimize for fast responses, which often means shorter, less complete, and less accurate responses.

A 2-minute response that says "try clearing your cache" is fast. It's also useless for 80% of the customers who receive it, because their problem isn't cache-related. Those 80% send a follow-up message. The agent responds again (another 2 minutes). The customer clarifies. The agent asks a question they should have asked in the first response. Four exchanges later, the problem is solved.

Total time: 15 minutes spread across 4 exchanges over 6 hours. Customer effort: 4 messages. Resolution quality: mediocre.

A 20-minute response that thoroughly investigates the issue, checks the customer's account, identifies the root cause, and provides a step-by-step fix takes longer to send. But it resolves the issue in one exchange. The customer sends zero follow-ups.

Total time: 20 minutes in 1 exchange. Customer effort: 1 message. Resolution quality: excellent.

The "slow" response is actually faster in total resolution time and dramatically better in customer effort. But it looks worse on the dashboard because the first response time is 20 minutes instead of 2.

When Slow Is Better

Email support. Nobody expects a 2-minute email response. A 2 to 4 hour response time with a thorough, complete answer is objectively better than a 30-minute response that starts a 4-email chain.

Complex technical issues. A developer who reports a bug doesn't want a fast acknowledgment. They want a real investigation. "I reproduced the issue and found the cause. Here's what's happening and here's the fix" is worth waiting 4 hours for. "Thanks for reporting this, we'll look into it" in 5 minutes adds no value.

High-value accounts. Enterprise customers with $50K contracts don't care about response speed as much as response quality. They want to feel like their issue got genuine attention, not a template.

Emotionally charged situations. A customer who's upset needs a response that demonstrates empathy and thought. A fast template feels dismissive. A slower, personalized response feels respectful.

When Fast Is Non-Negotiable

Live chat. If you offer synchronous chat, you're promising real-time interaction. The expectations are instant. Don't offer chat unless you can staff it for speed.

Account access issues. "I can't log in" needs a fast response because the customer can't use your product at all until it's resolved. Speed matters here because the customer is completely blocked.

Active outages. During downtime, fast acknowledgment prevents panic. "We know, we're working on it" in 2 minutes is essential. The detailed explanation can come later.

The Hybrid Model

The smartest approach: fast for simple, slow for complex.

AI handles the simple, speed-sensitive queries instantly. Password resets, order status, FAQ answers. These don't benefit from deliberation. They benefit from speed.

Humans handle the complex queries with deliberate thoroughness. Billing disputes, technical bugs, emotional complaints, high-value accounts. These benefit from thought, research, and careful writing.

Supp's classification makes this division automatic. Simple intents (315 categories) get instant AI responses. Complex intents get routed to human agents with context pre-loaded. The human doesn't rush. They investigate, compose a thorough response, and resolve it in one exchange.

Set different SLAs for each tier. AI: seconds. Human (simple): 2 hours. Human (complex): 4 to 8 hours. The customer sees fast responses for simple questions and thorough responses for hard ones. Both are satisfying.

Measuring the Right Thing

If you adopt a "quality over speed" approach, stop measuring first response time as a primary KPI. Measure instead:

Messages per resolution. Fewer is better. A resolution in 1 message at 4 hours beats a resolution in 5 messages at 2 minutes.

Reopen rate. Tickets that get reopened within a week weren't really resolved. Slow, thorough responses have lower reopen rates than fast, surface-level ones.

Customer effort score. Ask "how easy was it to get your issue resolved?" Customers who had to send 5 messages to get help rate effort as high, regardless of how fast each individual response was.

The goal is resolution quality, not response speed. Speed is a means to an end (faster resolution means lower customer effort). But when speed comes at the cost of quality, it increases effort instead of reducing it.

The best support feels effortless to the customer. Sometimes that means instant. Sometimes that means waiting a few hours for an answer that actually solves the problem. The customer remembers the outcome, not the clock.