Every customer operations team eventually develops a “figure it out” queue.
It fills up with problems that don’t cleanly map to the organization:
- confusing edge cases,
- multi-team failures,
- strange customer behavior,
- broken workflows,
- and issues nobody fully owns yet.
The queue grows because the routing logic assumes something important:
If we already know what the problem is, route it to the right team. If we don’t, send it to a group of humans who can figure it out manually.
Triage works, but in hindsight many of these issues could have been solved immediately, routed differently, or prevented upstream in the product entirely. The “figure it out” queue is where organizations discover the gap between their workflow diagrams and reality.
Most operational workflows are frozen assumptions about the best path through a problem. That works until the problem changes.
Workflow systems are built around known paths
Most workflow software assumes the operator already knows the correct sequence of actions ahead of time.
That assumption appears everywhere:
IF issue_type = "tax"
route to Tax queue
IF customer_tier = "VIP"
escalate to Tier 2
IF sentiment = "negative"
notify manager
There’s nothing wrong with this approach. Some requirements should stay fixed: approvals, audit trails, compliance checks, escalation logging, customer notifications.
But operational reality changes faster than workflows do.
When the “pile of tickets to be triaged” starts growing faster than the tickets can be moved to the place where they need to go, you hit an obvious problem. In your customer ops queue there are some things that are immediate emergencies. There are other items that are simply confusion. There are feature requests the team won’t get to for a while. And there are bugs where you need engineering help.
The triage is the problem, and people can’t do it fast enough.
There are some obvious root causes like customers describing problems inconsistently. Sometimes, teams don’t know who to send an item to because the ownership has moved. Perhaps there is a new product offering that created a weird edge case. And there are tickets that cover multiple concerns. A ticket that looked like onboarding turns out to be billing, product confusion, and a retention risk at the same time.
Every mature support system eventually develops strange routing rules nobody fully trusts anymore:
- enterprise accounts bypass Tier 1 except during renewals,
- accounting tickets route differently during tax season,
- onboarding escalations go to a special Slack channel,
- and someone still manually reassigns half the queue every morning because the logic never quite works.
The workflow is procedurally correct, but operationally fragile. It depends upon hidden, heroic effort by a few team members rather than resolving the accumulated uncertainty about ownership.
The shift agents force
Humans are usually good at defining the desired outcome, unacceptable outcomes, required approvals, escalation paths, and operational constraints. We’re much worse at predicting the single best execution path ahead of time.
Traditional automation assumes the intelligence lives inside the predefined workflow. Agent systems assume the intelligence comes from dynamically navigating toward an outcome within constraints.
This doesn’t mean “let the AI do whatever it wants.” In practice, the best systems become more explicit about permissions, guardrails, required checkpoints, escalation criteria, and evaluation. The difference is that the system no longer assumes every valid path must be designed ahead of time.
A traditional routing system asks:
“Which queue should this go to?”
An adaptive system asks:
“What combination of actions is most likely to resolve this correctly and quickly?”
Those are not the same question.
Consider a customer who submits this:
“My accountant changed, my return still isn’t filed, and I think my quarterly estimates are wrong.”
A rules-based workflow immediately struggles.
Is this onboarding? Accounting? Tax? Retention? Escalation? Billing confusion? Most systems solve this procedurally — categorize, assign, escalate, reroute, notify. But customers don’t experience organizations as queues. They experience outcomes.
An adaptive system starts somewhere different:
Goal:
Resolve customer-impacting issues as quickly and accurately as possible.
Constraints:
- Financial changes require human approval
- Escalations must be logged
- Compliance-sensitive issues require review
- VIP accounts require visibility to account teams
Capabilities:
- Analyze customer sentiment
- Compare historical resolution patterns
- Detect escalation risk
- Identify likely ownership areas
- Summarize context across systems
- Recommend next-best actions
Now the system can dynamically determine whether urgency matters more than specialization, whether multiple teams should collaborate, whether the issue resembles a known escalation pattern, or whether the customer primarily needs proactive communication and reassurance.
The workflow stops being a rigid sequence of tasks and becomes a system for evaluating paths toward an outcome.
Requirements vs. Execution
Adaptive systems don’t eliminate process. They separate invariant requirements from adaptive execution.
Some things should stay fixed: approvals, compliance review, identity verification, customer consent, audit logging. Many other operational decisions are contextual: prioritization, routing, sequencing, escalation timing, coordination between teams.
As agents become more capable, the human role shifts away from scripting every action and toward designing environments, constraints, capabilities, permissions, and evaluation systems. That starts to look less like workflow design and more like platform design.
Observability > Procedure
Procedural systems are easy to validate — every request follows the same path. Adaptive systems aren’t. Multiple valid paths exist for the same problem, and a procedurally correct workflow can still produce a terrible customer outcome.
That changes what you measure. SLA adherence and queue accuracy tell you the workflow executed. They don’t tell you the customer got to the right answer quickly and confidently.
Your first step is to learn what percentage of your tickets get to the right place with the SLA. Your second step is to determine if that was the right place after all given the rest of the context you know about the question (and the person who asked, and their current situation).
Adaptive systems force evaluation to move up a level. You are no longer just asking “did the agent follow the script,” but also “did the system consistently produce good outcomes across many kinds of problems.”
That evaluation, done well, finds the next bottleneck in your systems and starts removing the the root cause of your customer-initiated questions and makes you better able to scale.
What’s the takeaway? Workflow software assumed the best path could be designed ahead of time. The teams that win with agents won’t be the ones with the most elaborate workflows. They’ll be the ones who admitted they didn’t know the optimal path, and built systems that could find it.
