Why Most Support Retros Fail

The typical support retrospective goes like this: someone pulls up a dashboard, everyone stares at numbers for 30 minutes, people say "we should probably do something about response time," and nothing changes. Next month, same meeting, same numbers, same conversation.

The problem isn't the meeting. It's the structure. Or rather, the lack of it.

Cadence: Weekly vs. Monthly

Weekly works better for teams under 15 people. Keep it to 25 minutes. Focus on what happened this week and what to change next week.

Monthly works for larger teams or when your ticket volume is low enough that weekly patterns aren't meaningful. Block 45 minutes. Go deeper.

Don't do both. Pick one.

Who Should Be There

Your support team lead (obviously), two or three agents who handled interesting cases that period, and one person from product or engineering.

That last one matters more than anything else. Without someone who can actually fix product problems, your retro becomes a venting session. With them there, "customers keep asking about X" turns into a bug ticket or a feature discussion. The retro becomes a feedback loop between support and product, which is its real purpose.

Don't invite managers who aren't going to contribute. Don't invite the whole company. Keep it small enough that everyone speaks.

The Agenda

Part 1: Numbers (5 minutes)

Pull up your key metrics. Don't spend time explaining what each number means; everyone should already know that. Just note what changed and what's surprising.

Look at:

• Ticket volume (up or down, and why)
• First response time
• Resolution time
• Customer satisfaction scores
• Tickets by category or intent

Spend five minutes max on this. Numbers set the context, but they're not the point.

Part 2: Interesting Tickets (10 minutes)

This is the heart of the retro. Pick 4 or 5 tickets from the past period. Not random ones. Choose tickets that were:

• Unusually hard to resolve
• Handled especially well (celebrate wins)
• Mishandled (no blame, just learning)
• Revealing of a product gap or a documentation hole

Walk through each one briefly. What happened, what worked, what didn't. This is where institutional knowledge gets built. A junior agent hearing how a senior agent handled a tricky escalation learns more in five minutes than in a week of reading documentation.

Part 3: Patterns (5 minutes)

Zoom out. Are you seeing the same type of ticket over and over? Did a product release cause a spike in a specific category? Is there a self-service gap you could close?

If you're using intent classification, this is easy. Sort your intents by volume change. What's trending up? That's your signal.

Part 4: Action Items (5 minutes)

This is where retros either succeed or fail. Every retro must produce at least one concrete action item with an owner and a deadline.

"We should update the FAQ" is not an action item. "Jordan will add a section on billing cycles to the FAQ by Friday" is an action item.

Write them down where everyone can see them. Start the next retro by reviewing last period's action items: done or not done?

Common Pitfalls

Turning It into a Blame Session

When reviewing mishandled tickets, focus on the system, not the person. "What could we have done differently?" is better than "Why did you say that?" If agents feel like they'll be publicly criticized, they'll stop sharing interesting tickets, and your retro dies.

Only Looking at Bad Stuff

Celebrate what went well. If an agent defused an angry customer brilliantly, share that story. If your response time improved, acknowledge it. People need to hear what good looks like, not just what bad looks like.

No Follow-Through

If action items from the last retro aren't getting done, you have two options. Either the items weren't important enough (stop assigning trivial actions) or the people assigned don't have time (escalate that to management). A retro with no follow-through teaches your team that the meeting is performative.

Making It Stick

Keep a shared doc or Notion page with every retro's notes and action items. Over time, this becomes a valuable record of how your support operation evolved, what problems you solved, and what patterns keep recurring.

How Supp Helps

Supp automatically classifies every ticket into one of 315 intents. That gives you precise category data for your retro without anyone manually tagging tickets. You can see exactly which intents spiked, which resolutions took longest, and where automation could help, all at $0.20 per classification.