During the sales process, they've explained what they're trying to achieve, agreed on the use case, identified key stakeholders and provided the business context. Much of this information is documented in the vendor's CRM.
Then Professional Services sends an onboarding workbook asking for the business objectives, intended use case and stakeholder details.
A few weeks later, Customer Success introduces a success planning exercise that asks the customer to describe its desired outcomes again.
Each team has a legitimate reason to understand what the customer is trying to accomplish. But the customer has now been asked to reconstruct essentially the same information three times.
Compare that with another onboarding requirement: the customer must nominate someone internally to own the new business process enabled by the software.
That's a decision the vendor can't make for them. It requires customer effort, but the effort serves a clear purpose.
Customers have responsibilities in achieving their outcomes. They shouldn't also have to compensate for gaps in how their vendor operates.
Yet this is exactly what can happen when customer-facing processes are designed and managed independently by Sales, Professional Services and Customer Success.
What behavioural economics can teach us about customer effort
Behavioural economists use the term sludge to describe burdens that make it unnecessarily difficult for people to achieve their goals.
Richard Thaler has written about exploitative sludge, while Cass Sunstein's work on sludge audits examines how to identify excessive or unjustified burdens and assess whether they serve a legitimate purpose.
Much of the research and practical application has focused on government services and consumer experiences. The OECD's work on sludge audits, for example, considers psychological costs alongside the time and effort required to complete administrative tasks.
Sludge isn't an entirely new concept in B2B customer experience discussions. But there's an opportunity to apply it more deliberately to how B2B companies design their customer lifecycles.
Consider what a customer actually has to do when asked to provide information for a second or third time.
They may need to locate the original response, check whether anything has changed, consult colleagues, interpret slightly different questions and resolve inconsistencies. If the request is unclear, there's another round of emails or meetings.
A ten-minute form can create considerably more than ten minutes of work.
The customer may also be left wondering why the vendor doesn't already know something that was discussed and agreed weeks earlier.
Viewed individually, each request may appear reasonable. Looking across the complete customer journey reveals the accumulated burden.
The problem with designing journeys one function at a time
Many B2B companies have invested significantly in defining how their individual customer-facing teams operate.
Sales has qualification criteria, opportunity stages and exit requirements. Professional Services has implementation methodologies, intake processes and readiness assessments. Customer Success has engagement models, success plans and business reviews.
These processes are often developed by different leaders, supported by different systems and measured against different objectives.
The problems tend to appear at the boundaries.
Let’s return to our implementation example.
Sales has captured the customer's desired outcome in the CRM. The implementation team needs that outcome, along with more detailed technical and operational requirements, to develop its delivery plan.
There may be good reasons why the information captured by Sales isn't sufficient. Perhaps the implementation team needs a level of detail that wouldn't have been appropriate during qualification. Perhaps the original information needs updating or validation.
But unless the business has designed how those requirements connect, the easiest solution is often to ask the customer to start again.
The implementation team receives the information it needs. Its process works as designed.
The additional work imposed on the customer may never appear in any internal performance measure.
A similar problem emerges when Customer Success establishes a separate success plan without a reliable connection to the outcomes agreed during Sales or the work undertaken during implementation.
The customer becomes responsible for maintaining continuity between the vendor's processes.
This is why improving the efficiency of individual functions doesn't necessarily improve the customer journey.
A faster onboarding questionnaire is still an unnecessary questionnaire if the information already exists and can be reused.
The underlying issue is how the business has divided responsibility for information, decisions and work across the customer lifecycle.
AI agents could make this problem much worse
This becomes especially important as companies introduce AI and agents into customer-facing operations.
Consider what happens if our hypothetical vendor independently deploys AI agents across its commercial functions.
Sales introduces an agent that captures and summarizes customer requirements. Professional Services introduces another that automatically initiates onboarding and collects implementation information. Customer Success deploys an agent to establish success plans and gather progress updates.
Each agent might perform its assigned responsibilities extremely well.
Yet the customer could still receive three separate requests for essentially the same information, now generated and followed up on automatically.
In fact, the burden could increase.
When creating requests, sending reminders and chasing responses becomes inexpensive to automate, there's less operational friction preventing teams from asking customers for more.
A vendor could end up using AI to become remarkably efficient at creating sludge.
The alternative is to design how agents should operate across the customer lifecycle before deciding what each one should automate.
In our implementation example, an agent could use the information already approved during Sales to prepare the implementation intake. It could identify what's missing, flag inconsistencies for an internal owner and ask the customer to confirm only the details that genuinely require their input.
That sounds straightforward, but it depends on more than connecting systems or giving agents access to customer records.
The business needs to establish which information can be relied upon, who can access it, which decisions belong to the customer and who is accountable when requirements conflict. Agents also need clear boundaries around what they can change or approve without human involvement.
Without those decisions, automation can simply reproduce the fragmentation that already exists between teams.
This has implications for how we measure the success of AI in customer operations.
An agent that completes hundreds of tasks, sends follow-ups instantly and reduces administrative hours may look highly productive. But if customers are still repeating information, reconciling conflicting instructions or responding to unnecessary requests, the journey hasn't necessarily improved.
Before automating a customer-facing activity, it's worth establishing whether the activity should exist at all.
Examine the work, not just the journey map
Customer journey maps can show where handoffs occur and which teams participate. They don't always expose the work those handoffs create.
To find that work, examine the actual requests being made of customers.
Take the onboarding example. Put the CRM record, implementation workbook and success planning template alongside one another.
Look at what each document asks for, who uses the information and what decision it supports.
You may discover that the same business outcome is recorded in three places, using slightly different terminology. Or that an implementation team is asking for information Sales already collected, but can't access through its usual systems.
You may also find genuine differences in what each team needs. A high-level business objective captured during Sales may need to be translated into measurable implementation requirements.
That's useful work. The question is how much of it genuinely requires the customer's involvement.
In our example, the revised process might be straightforward.
The implementation team starts with the approved information captured during Sales. It asks the customer to confirm what's still accurate and provide the additional detail genuinely needed for implementation. Where requirements differ between vendor teams, a designated internal owner resolves those differences.
The customer remains responsible for decisions such as assigning an internal process owner, agreeing priorities and committing resources.
The vendor takes greater responsibility for managing the information it has already collected.
Once that process is defined, automation becomes a more useful option. An agent can help prepare information, identify gaps and coordinate the handoff without automatically creating another set of customer tasks.
Test whether the change actually helps
Removing a duplicated request sounds sensible. It's still worth checking what happens when you change it.
For the onboarding example, start with a small number of implementations and compare the revised approach with the existing process.
Look at how much time customers spend preparing information, how often clarification is needed and whether the implementation team receives what it needs to proceed.
If agents are involved, examine what they've changed from the customer's perspective. Have they reduced unnecessary interactions? Are they asking for information that's already available? Do their requests reach the right people, and is there a clear route for resolving mistakes?
Pay attention to where the work goes. If reducing customer effort creates a large administrative burden for another team, there may be a better way to design the handoff.
And if the implementation team starts missing important information, the redesign hasn't fully solved the problem.
The aim is to reduce unnecessary effort while preserving the information, decisions and safeguards needed for successful delivery.
There may eventually be evidence that these improvements contribute to faster time to value or better customer outcomes. That shouldn't be assumed simply because a form has become shorter or an agent has taken over the task.
Where else should we look for sludge?
Onboarding is an obvious place to start because the boundaries between Sales, Services and Customer Success are relatively visible.
Similar issues can develop throughout the customer lifecycle.
During adoption, customers may be asked to prepare separate issue updates for different vendor teams, even when the underlying evidence is largely the same.
Expansion processes can introduce repeated qualification exercises despite the vendor already having an established understanding of the customer's business.
At renewal, customers may be expected to reconstruct evidence of value that should have been developed and reviewed throughout the relationship.
Even offboarding deserves examination. Some exit requirements protect legitimate contractual, financial or security obligations. Others can make leaving unnecessarily difficult.
As more of these activities become automated, the importance of understanding their purpose increases. Otherwise, unnecessary work risks becoming embedded in the rules and instructions that govern how agents operate.
A different way to evaluate customer operating models
The concept of sludge gives B2B leaders another way to examine the effectiveness of their customer operating models.
Most companies can explain what they expect their Sales, Services and Customer Success teams to do at each stage of the lifecycle.
Fewer have the same level of visibility into all the work those processes collectively require from the customer.
That's an important gap, and one that becomes more consequential as AI takes on a greater role in executing customer-facing processes.
A customer journey should make clear which activities require customer participation, why that participation matters and who is responsible for the work surrounding it.
Those decisions need to be made regardless of whether the work is performed by people, agents or some combination of the two.
Where customers are being asked to compensate for disconnected systems, unclear ownership or poorly coordinated handoffs, there's an opportunity to improve the design.
Start with one customer-facing requirement that regularly causes duplication, confusion or delay. Examine why it exists, what work it creates and whether the business can take greater responsibility for resolving it.
Then decide what should be removed, redesigned or automated.
Customers have enough work to do changing their own businesses. They shouldn't have to compensate for the way we've organized ours, whether they're dealing with our people or our AI agents.
← Back to resources