Engineering teams don't just build software– they keep the product running.

But that wasn't always the case. DevOps only started to take shape around the late 2000s. The expression "You build it, you run it" was coined in 2016! What is a pretty straightforward no-brainer today, was revolutionary at the time.

Software developers used to build their product and hand it over to an operations team. Those were other engineers who had little knowledge of the product's inner workings but were tasked with keeping it up-and-running. They were in charge of monitoring, maintenance and support.

The big idea was that splitting up engineering capacity between project work and operations guaranteed enough bandwidth for both. As long as the product specifications were complete, these "Ops teams" could, in theory, field most support questions.

But that's not what reality taught us. Customers would always find questions with undocumented answers. They would ask about an edge case no engineer even thought about! How on earth could the Ops team answer that? They had no choice but to loop in the original developers…

As software development became more agile, specification and documentation levels went down, and the number of questions that reached the engineers skyrocketed. Customers would report bugs but also request data exports. Customer support questions to disable a certain user account would end up on the developers’ board. The days of just building features were over. That leads to planning issues as soon as a product finds a bit of success.

Answering customer questions takes time away from feature development. While not every customer request is an emergency, we can't just throw them on the backlog and hope to tackle them a few weeks from now. And by definition, it's impossible to know how many customer support requests you'll get in a day. Customer support questions become a source of unpredictable distraction for the team.

So, after an early honeymoon phase, startups quickly began considering professionalising their support organisation to prevent chaos in the engineering team.

But where to start?

Large companies have call centres and a legion of customer support agents at their disposal. That's not something a startup can afford.

We need a way of handling customer requests that scales with the company. Here's how to evolve such a system.

A three-tiered system

The traditional approach is a system with three levels of support.

  • 1st line support. This is the contact surface with customers. It's where they will look for answers, report issues and ask questions. In large organisations, this is typically a call-center.
  • 2nd line support. When 1st line can't help, the question reaches the second line. This consists of non-technical product specialists. They can answer most functional questions. In the scenario of the large call-center, these are the specialised agents you get forwarded to after the initial agent can’t help.
  • 3rd line support. Questions that can't be answered by 2nd line end up with the last line– the engineers who build the product. In the typical enterprise example, this is where you will receive an invitation to sit together with some of their developers to debug your issue.

This classic setup becomes an inverted pyramid. We want as many of the questions answered in line 1. We want to minimise the number of questions that reach tier 3.

This three-tiered approach works for startups and large enterprises alike, but the implementation will be different. Startups don’t have a call-center, but they still need to have tier 1.

Automating tier 1

The first step is to fully automate tier 1. Our first line of support should not be a call centre but a knowledge base with relevant articles to solve the customer's problem. When experiencing an issue, they should be able to find the answer for 90% of the cases. This can be as fancy as an AI support chatbot or as simple as good-quality FAQ documentation.

When you're just starting out, this documentation will be minimal. We'll grow it over time.

Automating tier 2

For 2nd line support, we want a different kind of automation. We need a tool where users can send their requests when they can't find the answers in the docs. This is where staples like Freshdesk or Jira Service Desk come into play. These service desk ticketing systems act as a buffer between the customers' requests and the engineering team. We really need that buffer so the engineers can focus on strategic work. When customers can add Jira tickets to the current sprint, the team can no longer operate. That’s also why direct Slack access to engineers is such a bad idea. We don't want customers to have direct access to the engineers or their Kanban board. That leads to chaos.

We want to replace telephone calls, emails and direct Slack messages. Every question becomes a ticket in a centralised database. This makes it easy to stay on top of open support issues.

As an added benefit, these tools often offer knowledge databases which can be used for tier 1.

Starting the machine

With these simple layers in place, we can create a professional, rightsized support machine.

Customers with questions are directed to the support page, where they can consult the knowledge base.

If they don't find the right answer, the question goes to the second line and becomes a ticket in the service desk software. This is where your customer success people can pick it up. If they can answer it, it goes back to the customers. If they can't, they push the question to the engineers.

Building a support feedback loop

Now, in the beginning, most questions will still end up on 2nd or 3rd line support as your documentation is lacking. But as the second line starts answering or delegating those questions, they add them to the knowledge base. Instead of sending the customer an answer to their question, they send them a link to a helpful article– even if they have to write it on the spot. This leads to ever more automated responses to relevant user questions.

Over time, the inverted pyramid starts to appear.

Scaling the machine

This approach allows us to scale the support organisation organically. We start with the team's product manager answering a few customer requests per week. However, this same system can grow to support an entire Customer Success department that handles thousands of requests for multiple teams.

The goal of professionalising customer support is not to avoid having questions reaching your engineers. It's to prevent the same question from landing on their desk twice.

The questions that do end up on third-line support will still take away time from feature development. It’s not a magic bullet. Managing that requires a fair bit of capacity planning. A lot of the early knowledge base work will add to the product manager’s workload. But by reducing the influx of questions, we can tame the chaos and free up engineering capacity for strategic work.

In those early days, you don't need an army of call centre agents or an operations team. You can start with a simple knowledge base and a ticketing system.