How to cut support calls when you're a 3-person SaaS

You cut support calls in a small SaaS by finding out which conversations are tasks rather than questions, fixing the documentation for the questions, and letting the product do the repeated tasks with the customer inside the app instead of on a call with you. The order matters: count first, write second, automate last, and always keep a door open to a human.

This is the plan, step by step, for a team where the founder is still the support department.

Why do customers call even when your docs are good?

Because self-service usually fails: most customers who end up on a call with you did try to help themselves first. Across industries, 81% of customers attempt to take care of matters themselves before they reach a person. Few of them get there: in a 2019 Gartner survey, only 9% of customers reported solving their issue completely through self-service. Gartner’s later survey of 5,728 customers puts it at 14% of issues fully resolved in self-service, and only 36% even for issues customers called “very simple”.

So the call is rarely the customer’s first move. It is what happens after the help center told them where to go and they didn’t get there. We wrote about that gap in The same question, every week. This post is about closing it.

Step 1: Count a month of conversations

Before you change anything, find out what you are actually dealing with. Your memory of last month is biased toward the annoying conversations, not the frequent ones.

Pull the last 30 days from wherever support reaches you: the shared inbox, the chat widget, the calendar links people booked, the DMs. For each conversation write one line with three things:

• what the customer wanted, in their words, shortened;
• the channel it arrived on;
• whether it ended in a call or a screen-share.

If you get more than a hundred conversations a month, take the most recent thirty. Thirty is enough to see the pattern in a small product, and you can do it in one sitting.

Step 2: Split questions from tasks

Now sort every line into one of two piles.

• Questions: the customer wanted to know something. “Do you support SSO?”, “What happens to my data if I downgrade?”, “How is the usage limit counted?”
• Tasks: the customer wanted something changed or set up in their account. “Add my colleague”, “Move us to the annual plan”, “Connect our Slack”, “Create a weekly report for the sales team”.

The test is simple: would the right answer be a sentence, or a change in their account? A sentence is a question. A change is a task, even when it was phrased as “how do I…?”.

We wrote the full method, with a table you can copy, in Questions or tasks: sort your support inbox in 20 minutes. It takes about twenty minutes for thirty conversations.

Then put the piles next to the third column, the one that says whether a conversation ended in a call. That tells you where your calls come from. A question ends when you answer it. A task ends when it is done, and if the customer couldn’t do it alone the first time, a written answer usually sends them back to the same place they got stuck.

Step 3: Put a price on the task pile

A support conversation looks cheap because each one is short. Gartner’s 2019 figures are $8.01 per contact on live channels such as phone, chat and email, against about $0.10 for self-service. For a team of three, the cost is not a line in a budget. It is the founder’s hours, and the context switch out of whatever they were building.

Take the task pile and add up the minutes, including the call that was booked for five minutes and took twenty-five. Then multiply by what an hour of your time is worth to the company. We worked through that calculation, with a clearly made-up example you can replace with your own numbers, in What founder-led support really costs.

You don’t need a precise number. You need to know which three tasks eat the most hours, because those are the ones worth fixing first.

Step 4: Fix the questions where the customer is standing

Questions are a documentation job, but “write more docs” is not the whole fix. In Gartner’s 2024 survey, the most common reason self-service failed was that in 43% of cases customers couldn’t find content relevant to their issue. Often the article exists and the customer never found it.

Three changes help:

1. Write the missing answers. Every question in your pile without an article gets one. Use the customer’s words in the title, not your internal feature name.
2. Fix the stale ones. If an article mentions a menu that has since moved, it creates calls instead of preventing them.
3. Answer inside the app. Many customers would rather ask than search. An assistant inside the product that answers from your docs, says when it doesn’t know, and links the article meets them where they already are.

With aside, that last part is one script tag on your app and your documents loaded into the workspace. It answers in English or Spanish from what you wrote, and when the docs don’t cover something it is built to say so instead of making it up.

Step 5: Turn your top three tasks into actions

This is the step that takes calls off your calendar, because it covers the part docs can’t: doing the thing.

Take the three tasks that cost you the most time in step 3. Each one is almost certainly a form or a settings screen your app already has. An action is a small wrapper around it: a name, a description the model reads, the arguments it needs, and a handler that opens the screen and fills in the form where the customer can see it. The customer then presses the button that saves or sends.

Here is what that looks like for “invite a teammate”, written with the aside SDK. The page registers the action, aside picks it when a customer asks for it and fills in the arguments, and your own code runs:

const actions = [{
  name: 'invite_teammate',
  description: 'Open the team settings and fill in the invite form with an email and a role. '
    + 'It does not send the invite: the user reviews it and presses Send invite.',
  inputSchema: {
    type: 'object',
    properties: {
      email: { type: 'string', description: 'Email of the person to invite' },
      role: { type: 'string', enum: ['admin', 'member', 'viewer'], description: 'Their role in the workspace' },
    },
    required: ['email', 'role'],
  },
  label: 'invite a teammate',
  run: async ({ email, role }, aside) => {
    aside.navigate('/settings/team');
    await aside.fill(await aside.waitFor('[data-aside="invite-email"]'), email);
    await aside.fill('[data-aside="invite-role"]', role);
    aside.highlight('[data-aside="invite-send"]', 8000);
    return { filled: { email, role }, next: 'the user reviews it and presses Send invite' };
  },
}];

if (window.aside) window.aside.register(actions);
else window.addEventListener('aside:ready', () => window.aside.register(actions), { once: true });

Notice what the handler does not do: it never presses “Send invite”. An action prepares; the person confirms anything that saves, sends or deletes. The enum on the role means the model can’t invent a role your form doesn’t accept.

Answering from docs needs only the script tag. Actions need someone who can write a function like this one, because it is your code that runs. For a form that already exists, each one is often an afternoon, not a project. If you want the longer version, From help article to action walks through turning three help articles into three actions, and How to let an assistant act inside your web app covers which functions to expose and which never to.

Step 6: Keep a door to a human

Some conversations should reach you: a customer who is about to cancel, a bug, a contract question, anything where the right answer is a judgment call. Cutting support calls doesn’t mean making yourself unreachable. It means the calls you take are the ones that deserve a call.

So whatever answers first must know when to stop. A conversation aside can’t solve goes to your team: it lands in the aside inbox where someone can pick it up and reply, and it can notify a Slack channel or a webhook. The customer doesn’t have to start over somewhere else, and you see the conversation with what was already tried.

A useful rule: if the same handoff reaches you three times, it belongs in step 4 (a missing answer) or step 5 (a missing action).

Step 7: Count again in a month

Repeat step 1 thirty days later, with the same three columns. You are looking for three things:

• Fewer calls on the three tasks you turned into actions. If they still show up, read those conversations. Usually the action’s description doesn’t match how customers phrase the request, or the action stops short of where they got stuck.
• Fewer repeat questions. If a question you documented keeps coming, the article is hard to find or doesn’t answer what people actually ask.
• A new top three. Once the first three are handled, the next three become visible. Work through them the same way.

This loop is the whole system. It is small enough to run in an hour a month, and it is what keeps the inbox from growing back.

Does cutting support calls mean being unreachable?

No. This plan isn’t a reason to hide your email address or remove the calendar link. Small teams win on being reachable, and some customers will always want a person.

It isn’t a project to automate your whole product either. Three good actions on the three most repeated tasks change your week more than forty actions nobody asks for.

And it doesn’t replace talking to customers. The sorted inbox is the best product research you have: every repeated task is a place where your interface didn’t make the next step obvious. Sometimes the right fix is an action. Sometimes it is moving a button.

Start with step 1 today. Thirty conversations, three columns, one sitting.