When there's no playbook, build the missing piece: repeated support friction is a product requirement

When different clients get stuck at the same point and support repeats the same explanation, the problem isn't support: it's a product requirement nobody has written. In this case, instead of waiting for engineering to prioritize it, the team built a .NET project with the integration classes ready to use, which cut client integration time by 10–15% and nearly eliminated the repeated support sessions.

In the early years, every week was the first time

In the early years of a SaaS startup where I was part of the founding team, we were the implementation and support team. There was no playbook. We built the process and documented it at the same time we accompanied clients integrating with the platform. Every week was, literally, the first time we did something.

The problem that looked like "normal support"

The platform only exposed API endpoints, bare. Every client had to build their own integration classes from scratch around those endpoints. On paper, that was reasonable: the API was documented, and integration was the client's responsibility.

In practice, it generated confusion and repeated support sessions. Different clients got stuck at the same point: not on the business logic, not on configuration, but on understanding how to assemble those classes. And every session was resolved with the same explanation we had already given another client the week before.

Pro Tip #1 — When the same question arrives from different clients, stop treating it as a ticket. Friction that repeats isn't a support problem: it's a product requirement nobody has written yet.

The decision with incomplete information

We didn't know for certain how many more clients would go through the same thing, or whether engineering would prioritize a fix soon. We could wait for someone to put it on the roadmap, or we could solve it ourselves.

I decided not to wait. We built a ready-to-use .NET project, with the integration classes already assembled around those endpoints, and delivered it directly to clients. It wasn't another guide or another documentation page: it was the missing piece, working.

Pro Tip #2 — A working example project is worth more than ten pages of documentation. Documentation explains how to build something; a base project removes the need to build it.

Pro Tip #3 — If you have what it takes to solve it, don't wait for another team to prioritize it. Waiting is also a decision, and your clients pay for it in every repeated session.

The result

Client integration time dropped between 10 and 15%, and the support sessions where a client was stuck just trying to understand how to build those classes dropped significantly. The team could dedicate that time to what genuinely needed hands-on support.

What remains from this story

When you don't have a playbook, it's tempting to wait until you have all the information before deciding. But often the fastest path isn't waiting for someone else to take it on — it's building the missing piece yourself. Paradoxically, that's how you start writing the playbook.

Frequently asked questions

How do you know a repeated ticket is a product problem? If the same question arrives from different clients and is always resolved with the same explanation, it stops being an isolated case: it's product friction that should be solved in the product.

Is it better to document or to build an example project? Documentation explains how to build something; a working base project removes the need to build it. When the friction is technical and repeated, the base project usually cuts support more.

Should support wait for engineering to prioritize the fix? Not always. If Operations has what it needs to resolve a recurring friction, waiting is also a decision — and clients pay for it in every repeated session.