Questions or tasks: sort your support inbox in 20 minutes

Take your last 30 support conversations, give each one a row in the table below, and mark it Q if the customer wanted to know something or T if they wanted something changed or set up in their account. Then count the T rows by task. The three most frequent tasks are what costs you calls, and the Q rows tell you which documentation to fix. It takes about twenty minutes.

This post gives you the table, the one rule for sorting, and how to read the result.

Why sort by question or task instead of by topic?

Because a topic tells you which part of the product is noisy, not what to do about it. Most teams that tag their inbox tag it by feature: billing, integrations, permissions, reports.

The question/task split does, because each pile has a different fix:

• A question (“do you support SSO?”, “how is usage counted?”) is fixed by an answer. Better documentation, or an answer delivered where the customer is.
• A task (“add my colleague”, “switch us to the annual plan”, “connect our Slack”) is fixed by the task getting done. An answer only helps if the customer can then do it alone, and the fact that they wrote in suggests they couldn’t.

The numbers say customers do try. Gartner found that only 9% of customers report solving their issue completely through self-service, and in a later survey that the most common reason self-service fails is that in 43% of cases customers couldn’t find content relevant to their issue. Those are two different problems: one is findability, the other is follow-through. The split shows you which one you have.

This exercise is step 2 of How to cut support calls when you’re a 3-person SaaS. You can do it on its own, but it is most useful as part of that plan.

Before you start (minutes 0–5)

You need three things:

1. The last 30 conversations, from every place support reaches you: shared inbox, chat widget, the calendar bookings, DMs. Don’t filter them. The boring ones count.
2. A timer. Twenty minutes forces you to sort on instinct, which is what you want. If a conversation takes more than thirty seconds to classify, mark it and move on.
3. The table below, pasted into a doc or a spreadsheet.

If your team shares support, do this with whoever answers the most. Two people disagreeing on a row is useful; it often means the conversation contained both a question and a task.

The template (copy this)

One row per conversation. Keep “what they wrote” short and in the customer’s words, not yours.

| # | Channel | What they wrote (short, their words) | Q or T | Task (verb_object) | Ended in a call? | Article exists? | Minutes |
|---|---------|--------------------------------------|--------|--------------------|------------------|-----------------|---------|
| 1 |         |                                      |        |                    |                  |                 |         |
| 2 |         |                                      |        |                    |                  |                 |         |
| 3 |         |                                      |        |                    |                  |                 |         |

What each column is for:

• Q or T: the main classification. Bugs get a third mark, B. A bug is neither a question nor a task; it goes to your issue tracker.
• Task (verb_object): only for T rows. A short name like invite_teammate. More on this below.
• Ended in a call?: yes if it turned into a call, a screen-share or a recorded walkthrough.
• Article exists?: does your help center already cover it? Yes, no, or “yes but outdated”.
• Minutes: your best guess of the total time spent, including the back-and-forth. What founder-led support really costs shows how to turn those minutes into money.

Here is how a few rows might look. These are illustrative, not from a real inbox: say you run a monitoring tool and these are some of your thirty.

#	Channel	What they wrote	Q or T	Task	Call?	Article?	Min
1	email	”Can I add my colleague as admin?”	T	invite_teammate	no	yes	6
2	chat	”Do you have an API?”	Q		no	yes	2
3	call	”Help me set up alerts for the checkout page”	T	add_monitor	yes	yes	30
4	email	”Move us to the yearly plan”	T	change_plan	no	no	8
5	chat	”Why is the dashboard empty since this morning?”	B		no	no	15
6	call	”How do I get the weekly report to my team?”	T	create_report	yes	yes	25

How do you tell a question from a task? (minutes 5–15)

Ask of each conversation: would the right answer be a sentence, or a change in their account?

• A sentence: Q. “Yes, we have an API, here are the docs.”
• A change: T. “Done, your colleague is now an admin.”

Three cases trip people up:

• “How do I…?” looks like a question and is usually a task. Row 6 above asks how, but what the customer wants is the report arriving in their team’s inbox. If you’d end up doing it for them, or walking them through it on a call, it’s a T.
• Mixed conversations. “Do you support Slack, and can you connect it for us?” is a T. The question is the lead-in; the task is the reason they wrote.
• Things only you should do. Refunds, contract changes, account deletions on request. Mark them T, and add a note: these stay with a person. They still belong in the count, but they are not candidates for automating.

Don’t debate edge cases for long. The point is the pattern across thirty rows, not the perfect label on one.

Name each task as a verb and an object (still minutes 5–15)

For every T row, write the task as a short verb_object name: invite_teammate, change_plan, connect_slack, create_report, add_monitor.

Two reasons. First, it makes duplicates obvious. “Add Marta to the account”, “can my CTO get access?” and “invite a new user” are three ways of writing invite_teammate, and you only see that once they share a name.

Second, if you later turn a task into something your app can do on the customer’s behalf, this is already its name. In aside, an action is registered with a snake_case name like invite_teammate, a description, and the arguments it needs. Your sorted inbox is the first draft of that list.

Read the result (minutes 15–20)

Count, then make a second, shorter table:

Task or question	Times	Ended in a call	Article exists	Total minutes

Sort it by total minutes. Then read it three ways:

1. Q rows where the article exists. The answer was there and the customer didn’t find it, or it didn’t match what they asked. Fix the title and the wording, and put the answer where customers already are: inside the app.
2. Q rows with no article. Write it. Use the customer’s sentence as the title.
3. T rows that repeat. These are the expensive ones. Look at the top three by total minutes. If they already have an article and still ended in calls, more documentation won’t help: the customer read the steps and still needed someone to do it with them.

That third group is the one to watch. A task that is documented, simple, and still comes back every week is not a documentation problem.

What do you do with each pile?

Questions go to your documentation. If you want them answered without you, an assistant inside your app that answers from your docs is the usual next step. With aside, that part is one script tag plus your documents loaded into the workspace: it answers from what you wrote, says when it doesn’t know, and hands the conversation to your team (the aside inbox, Slack or a webhook) when it can’t help.

Tasks are where the hours are. The top three become actions: functions your app already has, wrapped with a name and a description, that open the right screen and fill the form where the customer can see it. The customer presses the button that saves or sends. Writing one needs someone who can write a function. From help article to action walks through turning three repeated tasks into code, step by step.

Bugs go to your tracker, with the count. Five rows of the same bug is a priority argument.

Things that stay human stay with you. The goal is that the calls you take are the ones that need you.

Do it again in a month

The second sort is faster, and more useful, because you can compare. If a task you turned into an action is still in the top three, read those rows: the action’s description probably doesn’t match how customers phrase it, or it stops before the point where they got stuck. If a question you documented keeps coming back, the article is hard to find.

Twenty minutes a month, one table. It’s the cheapest product research you’ll do.