Customer support issues range from a confusing setting to a suspected security incident. Treating them all as generic “product problems” makes it harder to choose the right questions, owner and next action.
The seven categories below provide a starting taxonomy for a software support team. They preserve the distinction between using the product and managing the commercial relationship. They are practical classification choices, not a claim about which issues occur most often across every business.
Use a category to organize the request. Determine priority separately, investigate before declaring a cause, and keep a named owner until the next team accepts the handoff.
Seven types of customer support issues at a glance
| Issue type | Typical customer need | Likely next owner |
|---|---|---|
| 1. Usability and product guidance | Complete a task or understand a feature | Support; product or design for repeated friction |
| 2. Suspected bugs and technical failures | Restore an expected function | Support; engineering when investigation requires it |
| 3. Feedback and feature requests | Explain an unmet need | Support captures context; product evaluates |
| 4. Help finding or applying an answer | Locate relevant guidance and use it successfully | Support; knowledge owner for gaps |
| 5. Plans, subscriptions and invoices | Understand or correct a commercial issue | Support or an authorized billing owner |
| 6. Administration and user access | Manage membership, roles or permissions | Verified account administrator or access owner |
| 7. Security, data and compliance questions | Get an approved answer or report a concern | Security, privacy or other designated specialist |
1. Usability and product guidance
A customer may struggle to navigate a page, interpret a label or understand the sequence required to finish a task. The product could be functioning as designed while still being difficult to use. Start with the intended outcome: “What are you trying to complete, and where do you get stuck?”
Confirm the relevant product version, screen and account context. Explain the next action in the customer’s terms, using a short example or an approved visual when useful. Ask whether the instruction allowed them to complete the task, rather than treating a link sent as the result.
Record repeated friction for product review. “Three different customers could not find the export control” is more actionable than “customers need training,” provided the three reports actually exist. Keep observations separate from your proposed design change.
2. Suspected bugs and technical failures
“It is broken” describes an experience, not a confirmed defect. Capture expected behavior, actual behavior, the affected workflow, when it started and any exact error message. Check whether a documented incident or known issue explains the symptoms before starting a new investigation.
Follow approved, proportionate troubleshooting. A safe workaround may restore work while engineering investigates the cause. For the detailed sequence, use our technical troubleshooting guide.
Escalate with reproducible steps where available, relevant environment details, tests and their results, and business impact. Redact evidence before sharing it. The OWASP Logging Cheat Sheet identifies passwords, access tokens and other sensitive information that should generally be removed, masked or otherwise protected in logs. More evidence does not mean collecting every piece of customer data.
3. Product feedback and feature requests
A request for a feature can reveal a workflow that the current product does not serve. Ask what the customer needs to accomplish, who needs it and what they do today. Preserve those details alongside their suggested solution.
For example, “Add a scheduled export” might represent a need to prepare a weekly finance report without manual work. Product teams can evaluate that need more usefully when support records the frequency, required fields and present workaround.
Check existing capabilities and approved alternatives. Then explain the actual status of the request: recorded for review, linked to an existing request, or covered by a published commitment. Do not turn a customer’s enthusiasm into an invented roadmap date. Acknowledging feedback and promising delivery are different actions.
4. Help finding or applying an answer
Some requests already have a documented answer. That does not establish that the customer failed to try. The article may be hard to find, use unfamiliar terms, cover another version or leave an important step unclear.
Ask what they searched for or tried, without making self-service a test they must pass before receiving help. The Consortium for Service Innovation’s KCS guidance on requester context recommends capturing the person’s own description and relevant environment. It also explains how search terms and prior self-service activity can inform knowledge improvements.
Send the relevant section with a short explanation of why it applies. If it does not solve the need, continue the conversation. Record whether the gap was findability, coverage, accuracy or applicability. Article views alone cannot tell you whether someone completed their task.
5. Plans, subscriptions and invoices
These issues include plan differences, renewal questions, payment failures, invoice details and disputed charges. Begin by identifying the account and the specific transaction or subscription through the approved verification process.
Use the applicable plan terms and transaction record. An advertised price does not necessarily explain a particular invoice: billing period, quantity, discounts or changes may matter. State only what the record supports, and distinguish an explanation from a refund or adjustment decision.
Route exceptions to someone with authority to approve them. Avoid asking customers to send complete payment credentials in a ticket. If a payment attempt appears uncertain, check its recorded status before advising another attempt. Document the agreed action and who will confirm completion.
6. Administration and user access
Invitations, account ownership, role changes and permission errors can look like technical bugs. Ask which action is blocked, what the user should be allowed to do and who can approve access for the account.
Verify identity and authorization through the organization’s approved process. Never solve a permission problem by giving everyone administrator access. The OWASP Authorization Cheat Sheet recommends least privilege and denying access by default when it has not been explicitly permitted.
Provide the correct administrator instructions or route the request to the access owner. Record the approved change and verify that the intended action works. A successful login does not by itself prove that the customer’s original permission problem is resolved.
7. Security, data protection and compliance questions
A routine question about a published security practice requires a different response from a report of suspected unauthorized access. Identify which situation you are handling early.
For routine inquiries, use approved security or privacy documentation and route unanswered questions to the responsible specialist. Do not invent certifications, retention periods, contractual assurances or legal interpretations. For a suspected incident, follow the designated reporting process, preserve relevant evidence and avoid ordinary troubleshooting that could obscure it.
Collect only the information needed for the next safe step. Keep sensitive evidence in the approved channel and confirm who owns communication. A customer should know that the concern has reached the right team without receiving speculative conclusions.
Classify the issue without confusing it with priority
A category describes the kind of request; priority describes how urgently the organization needs to act. A billing question can block an important operation, while a confirmed bug may have a limited impact and an available workaround.
Atlassian’s impact and urgency guidance distinguishes effects on business processes from the time before those effects become significant. Apply your own documented priority rules to those facts, rather than making every request in one category automatically urgent.
Use a provisional category when the cause is unknown. In an illustrative access case, an agent initially records “user access,” discovers an expired subscription and changes the primary category to “subscription.” The history should show why the classification changed; it should not imply that the first agent confirmed a permission defect.
Turn classifications into useful operational feedback
Define each category with examples, exclusions and a routing owner. Allow a secondary tag for overlapping issues, but keep one primary category for a given report so totals are interpretable. Separate customer requests from internally created tasks and state the reporting period.
Review ambiguous classifications together. Look for repeating usability friction, incomplete instructions, recurring defects and avoidable billing confusion. Check a sample of the underlying conversations before proposing a product or process change: counts can rise because demand grew, labeling changed or a temporary incident occurred.
For handoffs, use the support ticket escalation process to specify the accepting owner and communication responsibility. The taxonomy should help someone take the next useful action, while the resolution record shows whether that action met the customer’s need.
