Quick answer
Start with three independent facets rather than one flat category: what the customer needs, what impact or specialist risk is evidenced, and what workflow or evidence state controls the next action. Permit multiple labels, require provenance and confidence, keep priority and resolution in separate fields, and record every human correction.
A three-facet support tagging taxonomy
Customer need
The outcome or help being requested. Prefer one primary need and add a second only when the case truly contains separate work.
Impact and risk
Observed scope, harm, or specialist trigger. Zero, one, or several may apply; these labels feed—but do not replace—priority and incident decisions.
Workflow and evidence
Temporary state controlling the next action. Remove, replace, or retain it as evidence changes; do not turn temporary labels into permanent customer attributes.
Quality contract for every label
| Field | Purpose | Failure prevented |
|---|---|---|
| label_id + facet | Stable machine key and independent dimension | Rename breakage and single-bucket confusion |
| Definition + include/exclude | Shared boundary and counterexample | Synonym drift and overlapping labels |
| Evidence + provenance | Explain why the label applies | AI confidence mistaken for truth |
| Owner + action | Turn context into accountable work | Decorative tags and unowned queues |
| Version + review trigger | Safe change and reassessment | Silent historical drift |
25 support ticket tagging taxonomy labels
These labels are individually defined starting points. Adopt only the labels that create a clear action, query, control, or learning use case; unused tags add noise.
How-to guidance need.how_to
NEED
Meaning
The customer wants instructions for a supported task and has not yet shown that expected behavior failed.
Include / exclude
Include when the requested outcome is learning a procedure. Exclude a reproducible failure, missing entitlement, access denial, feature gap, or complaint; attach those labels instead.
Evidence and route
Retain task, product/version, attempted steps, documentation seen, desired outcome, and channel. Route to knowledge or frontline support; reclassify if execution evidence shows a defect.
Account access need.account_access
NEED
Meaning
The customer cannot sign in, verify, recover, join, or obtain an expected role or permission.
Include / exclude
Include authentication, invitation, recovery, role, permission, lockout, or session access. Exclude service-wide authentication incidents and suspected account takeover; add impact or security labels.
Evidence and route
Retain safe account identifier, identity state, affected role, exact error, time, device/session context where permitted, and recovery attempts. Route to identity/access owner without requesting secrets.
Setup or configuration need.setup_configuration
NEED
Meaning
The customer needs to configure a supported product, workspace, policy, workflow, integration setting, or deployment option.
Include / exclude
Include a known capability with unresolved configuration. Exclude pure how-to questions once configuration is known, unsupported feature requests, integration failures, and product defects.
Evidence and route
Retain target state, current configuration/version, environment, dependencies, change history, attempted validation, and rollback needs. Route to implementation or product specialist.
Feature request need.feature_request
NEED
Meaning
The customer asks for a capability, behavior, control, channel, format, or integration that is not currently verified as supported.
Include / exclude
Include desired future capability or confirmed gap. Exclude misunderstood existing features, configuration, access, defects, and contractual commitments until evidence establishes them.
Evidence and route
Retain job-to-be-done, current workaround, affected users, frequency, evidence of need, constraints, and requested outcome—not a fabricated delivery date. Route to product discovery with no promise.
Product defect report need.defect_report
NEED
Meaning
Observed behavior differs from a documented, configured, or previously verified expectation under reproducible conditions.
Include / exclude
Include a reproducible mismatch with an evidence basis. Exclude preference, feature request, configuration error, data-source error, or isolated misunderstanding; co-label when uncertainty remains.
Evidence and route
Retain expected versus observed behavior, steps, timestamps, version, environment, logs/screenshots with provenance, frequency, workaround, and regression point. Route to support engineering.
Performance issue need.performance_issue
NEED
Meaning
The customer reports latency, timeout, throughput, resource, or responsiveness outside an evidenced expectation.
Include / exclude
Include measured or repeatable slowness and timeout. Exclude complete unavailability, local-device-only assumptions, vague “slow” statements without evidence, or a billing/perception complaint.
Evidence and route
Retain operation, timestamps/time zone, region, tenant, volume, percentile or sample, baseline, trace/request ID, network context, and workaround. Route to performance owner; add service degradation when scope expands.
Integration issue need.integration_issue
NEED
Meaning
Data or actions fail at a defined boundary between OpenMax and another API, connector, webhook, identity provider, or business system.
Include / exclude
Include authentication, schema, mapping, rate, delivery, or state-sync failures at an integration boundary. Exclude native product defects with no boundary and unsupported connector requests.
Evidence and route
Retain systems and versions, direction, endpoint/connector, safe request and response IDs, status/error, timestamps, retry/webhook state, mapping, recent changes, and ownership boundary.
Data or reporting issue need.data_report_issue
NEED
Meaning
The customer questions missing, delayed, duplicated, inconsistent, transformed, exported, or calculated data.
Include / exclude
Include lineage, synchronization, aggregation, dashboard, export, or metric disputes. Exclude confirmed access-only problems, product UI defects unrelated to data, and requests for new analytics.
Evidence and route
Retain source, destination, record/metric definition, query/filter, time range and zone, expected/observed values, freshness, sample IDs, lineage, transformation version, and reconciliation result.
Billing or payment question need.billing_payment
NEED
Meaning
The customer asks about an invoice, price, plan charge, tax, payment status, credit, payment method, or account balance.
Include / exclude
Include explanation or reconciliation requests without a final refund or cancellation decision. Exclude a formal refund/cancellation request, suspected fraud, and confirmed product usage defects; co-label when needed.
Evidence and route
Retain merchant entity, invoice/payment IDs, amount/currency, line items, tax and discount basis, payment state, plan/version, prior credits, customer question, and finance owner.
Refund or cancellation request need.refund_cancel
NEED
Meaning
The customer explicitly requests money back, a credit, reversal, subscription cancellation, renewal stop, or another commercial remedy.
Include / exclude
Include the requested commercial outcome even before eligibility is known. Exclude treating the label as approval, legal entitlement, fraud evidence, or completed refund; attach complaint or billing labels separately.
Evidence and route
Retain exact request, transaction and contract references, requested effective date, reason in customer words, fulfillment/usage, prior recovery, dispute state, policy candidate, authority, and decision state.
Task blocked risk.task_blocked
RISK
Meaning
No reasonable workaround lets the affected customer complete a time-relevant core task.
Include / exclude
Include evidence of a blocked outcome, not frustration alone. Exclude inconvenience with an effective workaround and service-wide impact already represented by a broader incident; priority is calculated separately.
Evidence and route
Retain blocked task, affected identity/role, business deadline and source, workaround attempted, dependency, start time, impact owner, and next reassessment. Route for urgency review.
Multi-user impact risk.multi_user
RISK
Meaning
Verified evidence shows the same issue affects more than one distinct user, account, tenant, region, or workflow.
Include / exclude
Include an evidenced shared pattern; do not infer scope from one loud report, duplicated messages, or correlated-looking symptoms. Exclude service-wide classification until monitoring confirms it.
Evidence and route
Retain distinct affected units, denominator where known, first/last observed, common signature, correlation method, sample IDs, confidence, and incident link. Route for scope reassessment.
Service degradation risk.service_degradation
RISK
Meaning
Monitoring or corroborated reports show reduced availability, correctness, capacity, or performance of a shared service.
Include / exclude
Include a validated shared-service condition or incident link. Exclude isolated tickets, local configuration, planned maintenance already communicated, and past incidents no longer affecting service.
Evidence and route
Retain service/component, telemetry source, threshold/baseline, region, affected scope, start/recovery time, incident ID/status, workaround, owner, and next update.
Security signal risk.security_signal
RISK
Meaning
The ticket contains an indicator of unauthorized access, credential compromise, malicious activity, vulnerable behavior, or confidentiality/integrity/availability risk.
Include / exclude
Include a signal that warrants security review; never use the label as proof of breach, attacker identity, or customer fault. Exclude ordinary access problems with no security indicator.
Evidence and route
Retain minimal indicator, source/time, affected asset/account, safe artifact location, exposure window, containment state, security owner, disclosure restriction, and incident link. Do not paste secrets into tags.
Privacy signal risk.privacy_signal
RISK
Meaning
The ticket may involve personal data collection, access, disclosure, correction, deletion, consent, retention, identity rights, or unintended exposure.
Include / exclude
Include a potential privacy issue for specialist triage; do not assert a violation or identity from incomplete text. Exclude generic confidentiality language with no personal-data context.
Evidence and route
Retain data category and subject relationship at the minimum necessary level, system, event time, lawful request/authority state, exposure hypothesis, access restriction, privacy owner, deadline source, and correction trail.
Accessibility barrier risk.accessibility_barrier
RISK
Meaning
A person cannot perceive, understand, navigate, operate, communicate with, or complete a task because of an accessibility barrier or incompatible accommodation.
Include / exclude
Include reported or observed access barriers and inaccessible support interactions. Exclude using disability assumptions to infer capability; preserve the customer’s requested format or accommodation.
Evidence and route
Retain affected task/content/control, assistive technology only if voluntarily relevant, environment, expected/observed behavior, requested accommodation, alternative quality, deadline, accessibility owner, and review.
Complaint or escalation risk.complaint_escalation
RISK
Meaning
The customer expresses dissatisfaction requiring a response, disputes handling or findings, requests review, alleges unfair treatment, or invokes an external complaint route.
Include / exclude
Include the expression and requested review without treating it as proven misconduct or higher priority by tone alone. Exclude ordinary dissatisfaction resolved in the same contact only if local definition permits.
Evidence and route
Retain customer words, issues, requested outcome, prior case/decision, review right and deadline source, conflict check, accessibility/representative needs, independent owner, next update, and non-retaliation controls.
Identity or authority unverified evidence.identity_unverified
EVIDENCE
Meaning
The workflow lacks enough permitted evidence to rely on the requester’s identity, account relationship, representative authority, or authorization for the requested action.
Include / exclude
Include as a temporary evidence state, not a judgment about honesty. Exclude once verification succeeds or a safe no-identity service path is intentionally used.
Evidence and route
Retain verification requirement, permitted method, attempts, result, confidence, representative document location, access restrictions, expiry, owner, and safe next step. Never store credentials in the label.
Evidence missing evidence.missing
EVIDENCE
Meaning
A defined decision cannot be made because one or more required records, observations, permissions, versions, or confirmations are absent or unusable.
Include / exclude
Include only when the missing item and decision dependency are named. Exclude vague “need more info,” facts already available elsewhere, and requests that would collect excessive data.
Evidence and route
Retain missing field/artifact, why it is necessary, lawful access source, request owner, customer/internal dependency, due time, alternative evidence, status, and expiry. Route reminders without blaming the customer.
Possible duplicate evidence.duplicate_candidate
EVIDENCE
Meaning
Two or more tickets may describe the same customer issue, event, transaction, or root cause, but equivalence is not yet verified.
Include / exclude
Include a candidate link; do not merge solely on similar wording, email, timing, or model similarity. Exclude related but distinct affected people, transactions, remedies, or privacy boundaries.
Evidence and route
Retain candidate IDs, match signals, differences, identity/authorization boundaries, primary-record proposal, customer-visible history plan, human merge decision, linkage—not deletion—and undo path.
Customer action required workflow.customer_action
WORKFLOW
Meaning
Progress depends on a specific, reasonable, accessible customer action that the organization cannot perform and has clearly explained.
Include / exclude
Include only a named action with reason and safe method. Exclude internal work, information already held, unreasonable burden, inaccessible steps, secret requests, or using the label to pause an SLA silently.
Evidence and route
Retain action, reason, minimum required input, secure/accessibile method, instructions, due/expiry basis, delivery status, alternative, reminder plan, owner, and what continues internally.
Internal action required workflow.internal_action
WORKFLOW
Meaning
Progress depends on a named internal team completing investigation, configuration, correction, approval, deployment, reconciliation, or communication work.
Include / exclude
Include a concrete owned action. Exclude using “engineering” or “back office” as an unowned queue, and do not hide internal dependency from the customer’s next-update commitment.
Evidence and route
Retain action, owner and backup, acceptance evidence, dependency, priority, start/due/review time, status, blocker, customer update owner, completion proof, and recovery if missed.
Specialist review required workflow.specialist_review
WORKFLOW
Meaning
A decision requires qualified security, privacy, safety, accessibility, legal, fraud, finance, tax, compliance, incident, or other domain authority.
Include / exclude
Include the required specialty and decision; do not use the label as evidence that a violation, breach, fraud, liability, or entitlement exists. Exclude routine escalation that needs no specialist judgment.
Evidence and route
Retain trigger, specialty, question, bounded evidence package, access classification, reviewer/backup, deadline source, decision authority, outcome, rationale, restrictions, and reassessment.
Monitoring or verification workflow.monitoring
WORKFLOW
Meaning
The immediate action is complete or containment exists, but the expected result, recurrence, recovery, delivery, synchronization, or stability still needs observation.
Include / exclude
Include a measurable observation plan. Exclude passive waiting with no signal, owner, threshold, or end condition; do not equate silence with recovery.
Evidence and route
Retain signal/query, baseline, expected result, scope, cadence, threshold, start/end, owner, alert route, customer update, success/failure decision, and evidence snapshot.
Reopened workflow.reopened
WORKFLOW
Meaning
A previously resolved or closed ticket is active again because the issue recurred, the remedy failed, material evidence changed, the customer disputed the outcome, or dependent work remained incomplete.
Include / exclude
Include a new activation event linked to the prior closure. Exclude new unrelated issues and routine post-resolution questions; create or link a separate ticket when scope differs.
Evidence and route
Retain prior closure decision/evidence, reopen trigger and time, changed facts, recurrence signature, failed remedy/dependency, customer words, new owner/priority, correction notice, and next review.
Worked case: “CSV export is broken” changes labels twice
A customer reports, “CSV export is broken for our finance team.” The classifier proposes need.data_report_issue and risk.task_blocked because “export” and “finance” appear in the text. Both are hypotheses, not conclusions.
- Preserve the report. The ticket keeps customer wording, tenant, role, export type, time, UI error, and a redacted request ID. No priority is inferred from “finance.”
- First correction. A human reproduces a 403 only for one newly created role. The data is intact and admins can export. Labels become need.account_access + evidence.missing while the team checks the expected role policy; risk.task_blocked is removed because a verified workaround exists.
- New scope evidence. Monitoring finds the same policy mismatch in 18 tenants created after a deployment. Add need.defect_report + risk.multi_user + workflow.specialist_review; link cases without merging customer identities.
- Recovery evidence. After a controlled fix, workflow.monitoring remains until telemetry and sampled exports confirm recovery. The label history records model proposal, human removals/additions, evidence, time, and owner.
How to govern and measure the taxonomy
Version and migration
Give every definition an owner, version, effective date, examples, counterexamples, downstream uses, and retirement path. Map old to new labels explicitly; never rewrite historical meaning silently.
Quality sampling
Sample by language, channel, product, label, confidence, model/rule version, reviewer, route, and outcome. Measure precision and recall only against a documented review set with disagreement resolution.
Operational usefulness
Track unlabelled rate, unknown/other use, co-occurrence, correction, stale temporary labels, routing changes, time to owner, reopen, privacy defects, and labels with no consumer. A popular label is not necessarily a useful one.
Minimum auditable assignment record
ticket_id · label_id · facet · taxonomy_version · proposed_by · model_rule_version · evidence_refs · confidence · assigned_by · assigned_at · reason · corrected_from · correction_reason · expires_at · route_action · owner · downstream_consumers · access_class · review_sample · retention_event
How OpenMax can govern ticket tagging
OpenMax can collect permitted ticket context, retrieve versioned definitions, propose multiple labels with evidence references and confidence, enforce facet and incompatibility rules, request human review, route owners, expire temporary labels, monitor changes, and preserve corrections. Keep raw sensitive content outside tag values and restrict specialist evidence by role.
Misclassification, privacy, and governance boundaries
- Do not encode protected characteristics, health, vulnerability, sentiment, customer value, blame, fraud, or legal conclusions as ordinary routing labels without a lawful, necessary, specialist-governed purpose.
- A label is not proof, priority, SLA, incident declaration, root cause, ownership, resolution, or customer consent. Store those as separate governed fields.
- Never place credentials, full payment data, personal narratives, medical facts, security artifacts, or confidential investigation text inside tag names or values.
- Require qualified human review for security, privacy, safety, accessibility, fraud, discrimination, complaint, legal, regulatory, or high-impact routes.
- Provide accessible correction, appeal, and reopen paths; monitor label quality by language and group where lawful without turning sensitive data into permanent profiles.
Frequently asked questions
Should each ticket have only one label?
No. Use one primary customer-need label when possible, plus zero or more independent impact/risk and workflow/evidence labels. Avoid duplicate synonyms.
Are tags the same as priority?
No. Tags provide context. Priority needs separate evidence-based impact, urgency, override, owner, and reassessment rules.
Can AI assign tags automatically?
It may auto-assign low-consequence labels inside validated thresholds, but must expose evidence, version, confidence, correction, and sampling. Specialist or adverse routes require humans.
When should a label be removed?
When its evidence no longer applies, its temporary state expires, a human corrects it, or a migration replaces it. Preserve assignment history and reason.
How many labels are too many?
Any label without a distinct definition, action, query, control, owner, or learning consumer is probably excess. Measure use and merge or retire safely.
What does OpenMax add?
It can retrieve versioned definitions, propose evidence-backed labels, request review, route work, expire states, monitor corrections, and preserve an auditable taxonomy history.
Sources, editorial method, and limitations
OpenMax editors reviewed Atlassian documentation on request types, work types, and ITSM categories; NIST SP 800-61 Rev. 3 for incident prioritization and escalation; the NIST AI RMF for documentation, monitoring, and human-AI accountability; ISO 10002 for complaint-handling context; and WCAG 2.2 for accessible labels and error support. We synthesized an original three-facet, 25-label starting taxonomy and correction case. Sources were rechecked September 3, 2026.
- Atlassian — Request types and work types
- NIST — SP 800-61 Rev. 3
- NIST — AI Risk Management Framework
- ISO — ISO 10002:2018
- W3C — WCAG 2.2