Building customer success from scratch at a fast-growing startup

The problem

Cloud Conformity was a fast-growing security startup with a complex B2B product, and I joined as its second product manager. The team was lean, and customer questions were arriving faster than anyone could answer them. There was no customer support team. Sales handled most queries and passed the difficult ones to engineering.

That was costly on every side. Engineers were pulled off the product to answer questions that often had known answers. Customers waited, because nobody owned their question. And sales spent its time on support instead of selling.

My role

I took this on as a set of customer success projects and owned each one from start to finish: the product documentation, the support desk, its link to engineering’s tools, and the way the new customer success team worked with product.

The decisions

Documentation first, support staff later. Much of what reached engineering could have been answered by good documentation, and there was none. Rather than start by hiring a support team, I wrote the product documentation from scratch, so that answerable questions stopped reaching people at all; support staff were hired later, as we scaled. To keep it consistent, I studied the help pages of services such as Slack and AWS and wrote a guide to language, structure and terms. I built it first in Confluence, then moved it myself into a CMS and published it on the company website, where customers could find answers without asking. The documentation also became the onboarding material for new employees.

Freshdesk, for one login. Customers needed to raise tickets without logging in to a separate system, so single sign-on was a requirement. Jira Service Desk would have kept everything in Jira, but it did not offer single sign-on at the time, and Zendesk cost more. I chose Freshdesk and set up the support workflow around it: the software, internal training modules for the team, and automation of 15+ repetitive tasks.

Let each team work in its own tool. Engineers worked in Jira; customer success worked in Freshdesk. Rather than make either team learn the other’s tool, I integrated Freshdesk with Jira. A tricky ticket became a Jira issue carrying all the customer’s information, and engineers could reply to the customer from Jira or create linked development tickets. Customer success did not have to manage Jira at all. Tickets carried customers’ personal information, so rather than route it through a third-party automation service such as Zapier, we built our own connector and kept the information flow between the two systems secure.

Turn tickets into a ranked backlog. Feature requests reached us through tickets from many customers. I designed our Jira set-up so that each request carried a score built from its priority, the effort it needed and the number of customers asking for it: simpler than a full RICE score, but consistent. A dashboard pulled in every ticket, scored it and ranked the list, so the product team could see what mattered most. We then went through the ranking with the customer success team, who knew the customers first-hand, to check that we were prioritising correctly.

Run customer success on data. I set up performance dashboards for the new customer success team and reviewed the support metrics with them every week in regular catch-ups, to improve how the team performed. I also built an automated, SQL-based KPI system that tracked retention, NPS and account health, which the team kept using after the acquisition.

What happened

The documentation cut support volume by 30%, grew self-help usage by 25% and saved 100+ person-hours a month. Engineers no longer spent time on questions the documentation could answer.

The Freshdesk–Jira integration cut ticket resolution time by 40% and made collaboration between support, product and QA simpler. Customer success spent its hours talking to customers and building relationships instead of doing admin. Insights from the KPI system guided customer success strategies that improved retention by 15%.

What I would do differently

I would choose the documentation’s long-term home before writing it. The documentation moved twice: from Confluence to a CMS, which I did myself, and after the acquisition to Trend Micro’s documentation site, which needed a lot of manual clean-up. Writing it once, in a format that travels, would have saved both migrations.

I would also make each change’s effect easier to see. We tracked the support metrics every week, but the documentation, the new support desk and the Jira link landed close together, so it was hard to say how much each one contributed. Staggering them, or tagging tickets by what resolved them, would have made that clearer.