Something breaks. A customer opens a ticket. Support starts working the case.

And then the Customer Advocate gets a Slack message. From the customer. Before support has even responded.

That’s not a coincidence. That’s a pattern.

The Customer Advocate didn’t cause the issue. They don’t own the code. They don’t have access to the logs, the traces, or the deployment history. They can’t see what engineering sees.

But they’re the one the customer called. Because they always pick up.

That’s the job.

What the Customer Advocate actually does during an incident

Here’s what it looks like in practice.

The customer is upset. The ticket is open. Support is working through their queue. Engineering is looking at signals the customer will never see. Nobody is talking to each other yet.

So the Customer Advocate starts making calls. They message the support lead. They find the right engineering contact. Not the on-call rotation. The one who actually knows this part of the product. They create a Slack channel, add the right people, paste in the customer’s description, and try to translate “it’s broken and we’re losing money” into something a team of engineers can act on.

They are not in the code. They are not in the logs.

They are in five conversations simultaneously, none of which have the same information.

That’s the gap. And the Customer Advocate lives in it full-time.

This is the structural problem nobody talks about

This is the structural problem that nobody talks about.

Support has the customer context but not the technical depth. Engineering has the technical depth but not the customer context. The systems they each work in don’t talk to each other. And the customer doesn’t care whose problem it is. They just want it fixed.

So who bridges that? The Customer Advocate. Every time. With whatever information they can gather from both sides, stitched together through sheer persistence and an embarrassing number of follow-up messages.

“Hey, just circling back on this 👋”

“Quick update. Any movement on your end?”

“The customer is asking again, I totally get you’re slammed, but…”

That’s not a communication style. That’s a structural workaround dressed up as friendliness.

The runaround is the job description nobody wrote down

Ask a Customer Advocate what a bad day looks like. They won’t describe a hard conversation with a customer. They’ll describe a day where they couldn’t get answers fast enough to have that conversation at all.

They went to support. Support needed more information from the customer. They went back to the customer. The customer gave them more information. They went back to support. Support escalated to engineering. Engineering needed a different team. That team was in a different time zone. By the time anyone had an answer, the customer had already escalated to their VP, who called your VP, who now wants a post-mortem.

The Customer Advocate did not cause any of that delay.

They spent the whole day trying to prevent it.

This isn’t a people problem. It’s a visibility problem.

The Customer Advocate is not filling this gap because they’re good at chaos. They’re filling it because no system gives the right people a shared view of what’s actually happening.

Support sees the ticket. Engineering sees the signals. The customer sees the impact. Nobody sees all three at once.

And so the Customer Advocate runs back and forth carrying context that should be in a system. Because it isn’t.

Every time they do that, a customer gets a faster answer. And the Customer Advocate gets a little further behind on everything else they were supposed to do that week.

That’s the gap. It’s real. It’s exhausting. And it shows up on your retention metrics before anyone thinks to ask why.