Part of an ongoing series on ordinary workspace friction, and what happens when you point an agent at it.
The customer writes a careful ticket. Login failed after the billing change. They attach a screenshot. They name the plan they think they're on. A support person reads it, tags it Billing, and sends it over.
Billing looks at it for forty seconds. This isn't a failed charge, it's a session issue after a plan change, so they route it to Engineering. Engineering sees "login" and a screenshot of a paywall and sends it to Product. Product puts it in the backlog for the next triage. Two days later the customer follows up in the same thread: "just checking on this." Nobody is dodging them. Everybody already "handled" the ticket. It just never landed.
That's how support tickets die at most companies. Not from neglect. From bouncing.
The bounce looks like progress. Nobody owns it
Reassigning a ticket is real work. You read enough to know it isn't yours, you pick a queue that sounds closer, you add an internal note, you hit transfer. The status changes. The SLA clock sometimes even resets. From the inside, something happened.
From the customer's side, nothing did. The original ask is still sitting there, now buried under three internal notes that each explain why this belongs somewhere else. The person who took the first pass has already moved on. The person who has it now is seeing it for the first time, with less context than the last person had, and a queue that was already full before this one arrived.
So when the day is loud, the bounce is the cheapest way to look done. Understandable: you cannot solve a billing-plus-auth problem from a Level 1 queue in six minutes. But that trade has a cost nobody tracks. Nobody logs how many tickets change owners twice before anyone replies to the customer. Nobody logs how often the follow-up from the customer is the first time the current owner even knows the ticket is theirs. Because nobody measures the bounce, nobody treats it as a problem worth fixing. It just quietly keeps happening.
And a lot of what would stop the bounce already exists. The customer's actual ask is in the first message. The plan change is in Stripe. The login error is in the logs. The last three similar tickets were solved by the same two people. The person staring at the transfer dialog isn't missing information. They're missing coverage: a way to see that this ticket has already been handed off, that the clock is aging, and that "not mine" is not the same as "now owned."
The kind of system we'd build
This is the kind of problem we like: not a new support culture, just a specific leak between "someone touched it" and "someone owns it." It also passes the test we use before recommending AI agent development at all: it repeats, it spans more than one tool, and a person can describe exactly what a good result looks like.
Here's what an agent for this looks like. It watches the tools the ticket already lives in: Zendesk, Intercom, Freshdesk, Linear, Jira, the Slack channel where escalations actually happen. It notices when a ticket changes queues more than once without a customer-facing reply. It notices when ownership ages past a threshold your team already believes in and nobody is watching. It doesn't wait for the customer to bump the thread.
It drafts a recap of the original ask, stripped of the internal ping-pong, with the source messages linked. It flags the bounce: who had it, who has it, how long since the customer heard anything, and which similar tickets got solved without this tour. It can post that in Slack, or drop it as an internal note on the ticket, so the next person starts with the history instead of reconstructing it.
Nobody starts from a transfer with three stale notes and a customer waiting. The coverage is already done.
The agent drafts. A person still decides what it means
The agent doesn't reassign the ticket on its own. That line matters, and we'd draw it hard in the design.
It can tell you a ticket bounced twice and the customer hasn't had a reply in 36 hours. It can't tell you whether this is actually Billing's, or a known auth bug Product already has a ticket for, or a customer who needs a human conversation more than a queue. It can guess an owner from who solved the last three like it. It can't tell you whether that person is on-call, out, or the wrong person for an account that's already waiting. It can draft a customer update. It can't tell you whether the honest version is "we're looking" or "this is a bug and here's the workaround."
So someone still reads the flag, decides who actually owns it, and decides what the customer hears. The difference is where they start. Instead of discovering the bounce when the customer follows up, or when the SLA turns red, they start with a dated recap and time still on the clock. The ticket stops moving because a person picked it, not because the queue ran out of places to send it.
A question worth sitting with
Pull last month's tickets that changed owners more than once. How many of those missed the first-reply SLA? How many of those customers had to write "just checking on this" before anyone answered?
If the honest answer is "more than you'd want a prospect to see," that's not a knock on the support team. It's a sign the miss wasn't effort. It was ownership. The work was already in the ticket. It just never stopped bouncing long enough for someone to keep it.
That's the same shape as the action items that die in the doc, the onboarding checklist nobody owns, and the sales follow-up that goes cold: work that already happened, scattered across tools you already own, with a next action that only becomes obvious when someone asks, a week later, whether it shipped.
If you have a workflow like this one and want to talk through whether it is worth automating, that is what our AI agent development work is for.