Ticket triage

Route the ticket using the same feature names as the docs

A customer reports missing columns in Forecast export. Support calls the feature one thing and the documentation calls it another, so a known issue looks like a new problem. Shared product terms connect intake, ownership, and the relevant workaround.

See the comparison

The task in this example

Route this ticket: “Forecast export is missing columns since yesterday.”

Business goal: Build brand loyalty
Business metric: Service-level attainment

The same known issue can take different routes

The ticket concerns the same release-specific export issue. The difference is whether support categories, known-issue notes, and documentation use connected feature identifiers.

Different names split the evidence

Support uses Forecast export; docs use Planning reports with no mapped synonym.

The ticket lands in an unrelated queue and the known workaround is missed.

Category: Unrelated reporting queue
Known issue: Not matched
First reply: Generic request for details

The customer waits for a useful response

Shared terms connect issue and owner

Both labels map to one feature and release-scoped issue record.

The ticket reaches the owning team with the applicable workaround attached.

Category: Forecast export
Known issue: Release match checked
First reply: Relevant workaround, after scope check

The first response can address the issue

Measure useful response, then service-level performance

Correct routing removes avoidable queue time. Classification accuracy alone does not show whether the customer received help within the promised service window.

Classify and scope

Identify feature, release, and warranted severity.
- Right category
- Severity accuracy
Match and route

Find the applicable issue and owning queue.
- Known-issue match
- Misrouted tickets
Respond usefully

Send or review the maintained workaround.
- First response time

Business metric

Service-level attainment

Track attainment against the service-level definition for comparable ticket classes and severity.

What to measure and how to interpret it

Use resolved tickets with reviewed categories and severity. Include near-match issues from other releases so a similar phrase cannot pass as a correct issue match.

Right category: Share assigned to the reviewed product area and feature.
Severity accuracy: Share assigned the warranted severity under the support policy; docs terminology alone does not determine business impact.
Known-issue match: Share linked to the correct issue for the ticket’s release and symptoms.
Misrouted tickets: Share transferred because the initial queue did not own the problem.
First response time: Time to the first useful response under the agreed service definition; distinguish automatic acknowledgment.

Check the business result

Compare service-level attainment, queue delays, and time to resolution for similar incoming tickets. Monitor the first reply’s usefulness and subsequent transfers so faster automation does not hide misrouting.

Schedule a call

Give the known issue a reusable workaround

A shared taxonomy makes the match possible. A short, maintained workaround makes the match useful to the customer.

Forecast export / Release scope

Known-issue record

Missing export columns

Match this issue only when the reported feature, release, and symptoms agree.

Feature: Forecast export; Planning reports mapped as a legacy term
Scope: Affected release recorded
Owner: Export feature support queue
Workaround: Reviewed task linked to the issue
Severity: Apply support policy using the customer’s impact

Intelligent content

Maintain workaround topics that can be sent with their prerequisites, limitations, and current issue status.

Taxonomy

Share product-area and feature identifiers across support and docs; tag known issues with affected releases.

A practical starting point

Compare a week of rerouted tickets with docs and issue labels. Test a shared feature map on one queue before expanding routing rules.

Support owns severity policy and queue responsibilities. Engineering owns issue status; the system executes routing and must honor those rules.

See how this scenario works

Explore the work with Intuitive Stack

Where do naming differences send tickets to the wrong queue?

Intuitive Stack can help align support and documentation terms and structure known-issue content that supports useful first responses.

Shared feature identifiers
Release-specific known issues
Workarounds connected to queue ownership

Schedule a call Explore the implementation