Customer Support Taxonomy

Five Messages, Five Different Obligations

The founder of a small-agency reporting product opens support on Monday to find five messages:

• Friday’s report never arrived.
• A new user cannot tell which file columns are required.
• An owner wants reports branded with each client’s colors.
• A paid workspace still says that its trial has expired.
• A prospect asks whether the founder can see uploaded client data.

An inbox can make these look like five pieces of the same work. They are not. One may be an incident, one may expose weak onboarding, one is an untested capability request, one joins billing to access, and one tests the product’s trust promise. “Bug,” “question,” and “feature” are too coarse to decide what must interrupt the week, what the customer should hear, or where the evidence belongs after the reply.

Use this taxonomy to give each meaningful contact one durable record. It separates four judgments that are often collapsed: impact, request class, likely cause, and destination. Those judgments may change during diagnosis. The customer’s original words and observed outcome do not.

Capture the Case Before Naming It

Start with the event as the customer encountered it. Preserve their words or a faithful short excerpt, then add the account, target segment, workflow step, and product stage. “Export broken” loses too much. “The scheduled Friday PDF did not arrive for the three client accounts due this morning” gives the founder a promise, a workflow, a deadline, and a possible scope.

Record behavior separately from interpretation. A customer may report a privacy problem when the immediate evidence shows an unclear disclosure. A founder may hear a feature request when the customer is actually trying to preserve responsibility between two people. Classification should make the case easier to investigate, never overwrite what happened.

SUPPORT CASE
Case ID and opened time:
Customer, account, and target segment:
Channel and contact person:
Customer's words:
Observed behavior or missing outcome:
Workflow step and value at stake:
Product stage—evaluation / activation / active use / renewal / exit:
Evidence attached—event, job, invoice, screenshot, recording, or logs:

A cancellation, failed renewal, or abandonment after an error can become a case even when the customer never wrote. The taxonomy describes product contact with reality, not just inbound messages.

Set Severity from Impact

Classify urgency before estimating a fix. Use the same four internal levels as the support operating chapter:

• S1 — stop and stabilize. Core paid value is unavailable, a consequential result may be wrong, or money, data, security, access, or customer trust may be at immediate risk.
• S2 — restore a path. Activation or continued use is blocked or damaged, but a bounded workaround or founder-assisted path exists.
• S3 — resolve recurring friction. The product works, yet its behavior, language, or process repeatedly causes confusion or avoidable support.
• S4 — learn without interruption. A preference, edge case, or idea does not obstruct the target workflow.

Severity is a response policy, not a verdict on the customer. A calm note can describe S1 impact. An angry request can remain S4. When scope changes, change the severity and record why. The missing Friday report begins as S1 until the founder knows whether the report failed to generate, failed to send, or reached customers with incorrect data.

IMPACT AND RESPONSE
Severity—S1 / S2 / S3 / S4:
Users, records, money, access, deadline, or trust exposed:
Known scope and unknown scope:
Immediate action—stabilize / work around / investigate / schedule / decline:
First response sent and next update promised:

An immediate response does not promise an immediate product change. It says what is known, what the customer should do now, and when they will hear again.

Choose One Primary Class

Choose the class that best describes the present obligation. Add one secondary signal only when it changes where the case will be reviewed. This compact reference is intentionally a lookup table: the rows distinguish cases that sound similar in an inbox but require different first destinations.

The class can change. If logs show that the missing report was generated correctly but an address was entered incorrectly, the case may move from reliability incident to account operation. Preserve that history. It explains why the founder interrupted planned work and what the eventual fix can prevent.

Do not use “customer error.” Name the failed action and the condition around it. If well-fit users repeatedly provide a file the product rejects, the boundary may be valid, the instruction may be weak, or the product may not understand the real input convention. Blame is not a useful class.

Keep Cause and Destination Separate

The primary class organizes the response; it does not establish cause. Mark a cause as observed, likely, or unknown. A timeout is an observed event. “The worker is underprovisioned” remains a hypothesis until evidence supports it. The same symptom can arise from product code, source data, configuration, third-party behavior, documentation, an unsupported workflow, or an inaccurate promise.

Then choose a destination for what the case has taught: product, onboarding, documentation, operations, segment or sales policy, refusal, or continued observation. A case may close for the customer before the destination work is complete.

CLASSIFICATION AND ROUTE
Primary class:
Secondary signal, if it changes review:
Cause—observed / likely / unknown:
Evidence for that cause:
Customer resolution or workaround:
Destination—product / onboarding / documentation / operations /
  segment-policy / refusal / observe:
Decision owner:
Review trigger or date:

The branded-report request, for example, is a capability request. The founder still needs to ask what changes when branding is present, who requires it, and whether comparable agencies share the job. If it is a sales deliverable for one large prospect, the secondary signal is a fit boundary. The destination may be discovery or refusal; “feature backlog” would decide too much too soon.

The data-access question is different. The founder can answer it from actual policy and operating practice. If the upload screen fails to disclose a real support-access path, the customer receives an exact answer and the case routes to onboarding or documentation. If practice contradicts the promise, it routes to a trust repair. Reassuring copy cannot settle that mismatch.

Record the Cost of Making the Customer Whole

The visible ticket count understates support burden. Record founder time, manual touches, systems entered, and work displaced. Ten short documentation questions may be cheaper than one monthly import repair, while the repair may be more valuable evidence because it occurs at the product’s value moment.

OPERATING COST
Founder minutes and elapsed customer wait:
Manual actions and systems touched:
Planned work or promise displaced:
Could the same case be resolved safely from the current operating record?
Recurrence key—same workflow + same cause or unresolved job:

A recurrence key should describe the mechanism closely enough to join like cases. “Import problem” creates a misleading pile. “Required client ID absent from the agency export” and “date parsed in the wrong locale” demand different decisions even though both arrive as failed imports.

Close Three Loops

A support case is ready to close when three outcomes are explicit:

1. Customer loop: the customer knows the result, any required action, and whether another update is due.
2. Product loop: the evidence has a destination, including an honest choice to observe or refuse.
3. Operating loop: the resolution, founder cost, and recurrence key remain available for the next occurrence.

CLOSURE
Customer-visible outcome verified:
Final message sent:
Promise kept, changed with notice, or missed:
Product or policy decision created:
Follow-up evidence required:
Closed time:

Review open S1 and S2 cases by promised update time. Review recurring S3 cases as a group before planning product work. Review S4 cases only when a trigger arrives: another well-fit customer, a renewal consequence, repeated founder labor, or evidence that the request belongs in the core workflow.

The taxonomy is working when two similar messages can be separated for good reasons and several differently worded messages can be joined by the same cause. It should shorten the path from contact to an honest response, then leave evidence strong enough to decide what the product, its explanations, its operating surface, or its market boundary must do next.