The cheapest support ticket is the one nobody files

Whitelabel clients ran a business on top of our product. Their questions weren't random — they clustered around predictable moments: after launch, before a store policy deadline, when a build went stale.

I was answering those questions one at a time, in whatever order they happened to arrive.

My week was shaped entirely by an inbound queue. The customers who wrote in got attention; the ones who didn't got none, regardless of which group actually needed it.

That's a bad allocation and it doesn't scale — inbound volume grows with the account count, so the model gets worse exactly as the business gets better.

Reading back through my own ticket history, most of what I answered wasn't a problem with the product. It was a customer not knowing where they stood — whether they were current, whether something was expected of them, whether the silence meant everything was fine.

Questions like that are generated by the absence of information, which means they're preventable rather than just answerable. And because they cluster by lifecycle stage, they're predictable in advance.

I took the third because I could test the hypothesis immediately without asking anyone for anything. If proactive contact deflected tickets, the data would say so within a couple of cycles and I could argue for the automated version with evidence.

• More knowledge base articles — scales infinitely but requires the customer to know they have a question and go looking. Passive.
• Trigger-based automated emails per event — precise, but needs engineering work and event plumbing I didn't control.
• A scheduled bi-weekly check-in carrying each account's actual status — no dependencies, and I could start this week.

A bi-weekly check-in to whitelabel clients built around what was true for their account: where their build stood, what was coming, what needed them. Status first, not a newsletter.

I ran it on my own accounts until the pattern held, then documented it as a repeatable process so the rest of the team could run it on theirs.

Inbound tickets dropped sharply. The team adopted the program beyond my accounts, and the Group Product Manager recognised the work.

The change I valued most was in the relationship. Customers stopped experiencing us as a place you go when something breaks. When I did need something from them, I was already someone they'd heard from.

The program worked and it stayed manual. Every check-in cost someone real time, which caps how far it can spread and guarantees it degrades when the team gets busy — the most valuable version of this is the one that survives a bad quarter.

The scheduled email proved the hypothesis. It should have been the argument for the triggered, in-product version, and I didn't push that far enough.