If you run a startup that requires following up users beyond basic reachouts such as “How can I reset my password?” or, “If I want to use feature X, what price plan must I have?”, you are likely to benefit from having a system that is more than just a standard customer support tool. Your specific need would probably however still vary widely. From whether you are hosting a niche repository or have a larger SaaS-project that delivers a complete suite of functionalities. Whether you have a robust and stable product release version, or a shaking pre beta skeleton. Whether your code base is built in JavaScript or the more obscure, Haskell. In other words, there are numerous things to think of when setting a plan for your support efforts. 

Many tech startups host repositories consisting of volumes of code, SDKs and maybe open APIs. Their users might be other tech companies using their code, SDKs and APIs to create their own products or projects. Without perfect documentation, varied technical competence among your users, and a wide range of different application areas, this will inevitably, from time to time, lead to the need of help with solving issues, debugging, integration guidance, help with breaking changes, and some best practice pointers. 

In a world of an almost infinite number of options, businesses, and especially enterprises, want support to be easy and hassle-free. They may use tens, and sometimes hundreds of different projects and systems, so support has to be smooth. In the following we’ll share some thoughts on how you can plan for support from the very inception of your project.

The early days of your project

In the early days, you can probably easily hustle any incoming requests on a running basis. But soon you might get too many abruptions and lose development flow and oversight. All at the cost of future features and growth of your project. At this point (ideally earlier) it is time to put things into system. Most startups see a none to steady linear predictable growth, before a few eventually strike gold, and are left with an exponential luxury problem. Setting up a good support system and routine is definitely easiest before things are getting out of hand growth wise. Regardless of the actual need, offering a structured support front to your users leaves a better and more solid impression, and might be decisive for some businesses when choosing a solution. 

In the start, having one dedicated support person who can escalate technical requests and questions to the other team members, could be a good way to approach it (unless you are working solo, and this person also is you). This person needs to understand the product and know the documentation, but doesn’ t necessarily have to be very technical. From our perspective there are especially two reasons to consider this: 1. Non-tech persons usually cost less than having a developer handling support, and 2: Regardless of cost, developers need flow, probably more than people working on business development stuff (though I’m sure some will disagree here).

AI might help you, but..

In addition to answering questions about pricing and admin stuff, AI may be able to do the trick for basic technical requests, such as answering more general code questions related to the largest languages, or point your users to relevant parts of your documentation and FAQs. But using AI still comes with a dilemma. You may free up time, but can you afford bad experiences and unnecessary high curns from sub-par AI answers in the early days?

Today people tend to test solutions and migrate over to the next option if things don’t run smoothly from day one, or oftentimes more like hour one. And if they end up using your product, but your product doesn't have any natural lock-in through complex migration, cumbersome code replacement, or inconvenient data exports, the need to constantly make your users feel good about your product becomes even more important. With lock-in and barriers you may be able to afford poorer user experiences, hence poorer support, but it doesn’t necessarily result in any ideal word of mouth or great reviews of your project. As a startup you need to go the extra mile for your users to get word of mouth running, and currently AI rarely goes that extra mile. And even if it did, people still tend to appreciate a human taking its time over an AI, especially in the beta days. 

You still may want to consider a hybrid approach, where AI handles “tier one complexity”, and humans handle everything else. This can be achived with clear and thought-through escalation rules, an integrated part of many AI-systems. 

When to double down on documentation (and AI)

As a startup, spending time on extensive guides and documentation, going through all thinkable edge cases, are usually badly spent time pre beta. If you are available and helpful, it is usually better to start out with less documentation (not talking about code documentation here), and see what questions people are asking. You may be surprised. 

In addition the product will probably change a lot in the early days from alpha to beta, meaning guides will need a lot of revisions in this phase. Instead of writing documentation, you probably therefore want to focus on shipping features and talk to people, either personally or through someone you trust on your team. That said, try to document what you know will stick for longer periods, and build gradually from there. With more extensive and better documentation, AI will be able to do more of the heavy lifting in the future.

Early product = Strong support (and less AI)

Our advice would be, don’t overthink the support or get too fancy, but pay attention to it earlier than you may think. Consider using a simple support tool to set routines and a structure from an early phase so you don’t have to scramble when you really need it. Already when you get, let’s say 20 unique users that reach out to you once a week, things will feel more hectic. Store your support conversations and support statistics, and gradually build your documentation. With documentation, AI will likely gradually relieve you from a greater share of any incoming requests. Setting up the perfect documentation from day one is both poor time management and distance you from great user interactions and valuable insight. 

So to summarize:

Early product  = Strong support (and less AI)
Set product = Strong documentation (and more AI)

Good luck with building!