SaaS Customer Support: Tiers, Handoffs and Response Times

A SaaS customer doesn't buy a product once and walk away. They log in on Monday, get stuck on Tuesday and decide on renewal day whether the thing was worth it. SaaS customer support is the work that sits between those moments, and it differs from shop-style support in a few ways: the questions are about how software behaves, the same person asks many times, and some of what they report is a real bug that only engineering can fix.

This guide covers how to structure the help you offer, how to sort bug reports from how-to questions, how to hand problems to engineers and what to promise on each plan.

Three tiers of help

Most SaaS teams end up with three layers, whether they planned it or not. Planning it means each layer has a job.

The rule of thumb: a question that has one right answer belongs in the docs, a question that needs a quick human glance belongs in chat, and a question that needs someone to look at the account or the logs belongs in a ticket. Hodhod doesn't include a knowledge base, so docs live wherever you host them; link them from your canned replies. For writing them, see knowledge base and help center.

Chat and tickets can sit in one inbox. A chat that turns out to need an hour of digging becomes a ticket with its history; see ticketing and live chat, and ticketing vs live chat if you're unsure which to lead with.

Onboarding questions are their own category

In the first two weeks, people ask different things than long-term users do. They're rarely reporting bugs. They want to know what to do first.

Collect the questions from your first twenty or thirty new accounts and group them. You'll usually find the same five or six: connecting data, inviting teammates, importing a file, billing basics, one confusing setting. Then:

1. Write one canned reply for each, with a link to the doc or a two-line answer.
2. Put a short chatbot menu or a pre-chat question in front of the chat so people with these questions get the answer at once.
3. Tag them with an "onboarding" label so you can count them monthly.

If the same onboarding question keeps arriving, the product or the first-run screen is probably unclear. That is a finding for the product team, not a reason to hire another agent. See canned responses and templates.

Bug report or how-to question?

The first job on any message is deciding which of these it is. They need different answers and different owners.

When it's unclear, try to reproduce it yourself with the same plan and role as the customer. If you can't reproduce it, ask for the details in one message instead of five. A template to copy:

Thanks for the report. To check this on our side, could you send: 1. The page or screen where it happens, and what you expected to see 2. What you saw instead (a screenshot helps) 3. The time it happened, with your time zone 4. Your browser or app version 5. Whether it happens every time or only sometimes

Priority is a separate decision from type. A bug that blocks every user on an account is urgent, and so may be a how-to question from a trial user the day before the trial ends. See ticket triage and priority.

Handing a bug to engineering

Support often fails here, not because engineers are unreachable but because the report arrives without the information they need, or arrives eleven times.

A handoff note should hold the following, whether you send it in your tracker or by hand:

• One-sentence summary of the problem
• Steps to reproduce, and what you saw instead
• Account, plan and time of the first report
• How many customers have reported it so far
• Workaround, if there is one, and what you told the customer

In Hodhod you can attach conversations and tickets to an issue: one record for one problem, so engineering sees a single item with a count instead of a pile of messages. Issues also track occurrences when a problem comes back, and an issue can be sent to Jira as an engineering ticket; see issue tracking and connecting support to Jira. Tell the customer what happens next ("we've passed this to the engineers and I'll write when it's fixed") and set a due date on the ticket so you do write back.

When a problem is hitting many accounts at once, that's an incident, not a ticket. The rules for who gets paged and when are in an escalation policy template.

Support inside the app

Customers ask questions at the moment they're confused, which is inside your product. A help button that opens chat, with the user already identified, saves the "what's your email?" round trip and gives agents the context to answer faster. For mobile, the Android SDK brings chat and tickets into a native app; see the Android SDK tutorial. On the web, the same job is done by the website widget.

Response expectations by plan

Not every plan has to get the same speed, but every plan has to get a promise you can keep. A simple structure, with example numbers counted in business hours:

These are placeholders. Start from what your team delivers today and check that the numbers add up: if three agents each handle about 30 tickets a day and the Business plan has 40 accounts that each send one a week, the Business queue is nowhere near the limit. If the free plan has 4,000 users, it may be. Do your own sum before printing numbers on a pricing page.

To make this work in Hodhod, label the conversation by plan (for example "plan-business"), then create an automation rule that adds the matching SLA policy to conversations with that label. Details in SLAs in customer support.

A weekly checklist

• Count new tickets by label: how-to, bug, billing, onboarding
• Read the oldest five open tickets
• List bugs with more than one report and check their status with engineering
• Check which how-to questions came up three or more times, and write or fix a doc
• Check missed deadlines against the plan promises

If you'd like to see this in a shared inbox with your own plans and labels, request a free demo.

Frequently asked questions