How to Write Resolver-Group Definitions for AI Ticket Routing

An AI routing system cannot infer an organization's service ownership from resolver-group names alone. "Infrastructure," "Platform," and "Applications" may be meaningful to employees, but they do not state which requests each team accepts or where one team's responsibility ends.

A resolver-group definition is an operational classification rule written in business language. It should give the routing system enough evidence to prefer one team, enough exclusions to reject a neighboring team, and a safe path when the ticket does not contain the deciding context.

This guide shows how to write those definitions. It complements the broader AI ticket triage guide and fits into the release controls in the AI ticket routing change-management framework.

Start with ownership, not ticket vocabulary

Weak definitions are lists of words seen in historical tickets:

> Handles VPN, Wi-Fi, laptop, access, login, network, and connectivity issues.

This looks useful but mixes devices, identity, network access, and application authentication. A ticket containing "cannot log in to VPN from laptop" could match several groups.

Start with the assets, services, request types, and operational outcomes the team owns. Then add the language users apply to those objects.

A stronger definition states:

• What the team owns
• Which actions it performs
• Which conditions indicate that ownership
• Which adjacent conditions belong elsewhere
• What context is required to decide

Historical vocabulary remains useful, but it supports the ownership model instead of replacing it.

Use a consistent definition schema

Give every resolver group the same structure. Consistency helps reviewers compare boundaries and makes gaps visible.

Group identity

Record the canonical group name, accountable owner, and definition version. If the workflow uses a technical queue identifier, map it separately so a naming change does not alter the meaning of the definition.

Owned scope

Describe the services, systems, assets, and request outcomes the group owns.

For example:

• Identity lifecycle for managed workforce accounts
• Authentication policy and multifactor enrollment
• Enterprise directory group membership
• Investigation of directory synchronization failures

Use concrete nouns and actions. "Handles identity issues" is too broad.

Included request types

List common request classes that demonstrate the scope:

• Create, disable, or restore a workforce account
• Reset a managed account password
• Enroll or recover a multifactor method
• Change membership in an enterprise directory group
• Investigate directory account lockout

These are positive examples, not an exhaustive keyword list.

Excluded scope

State the nearest boundaries explicitly:

• Application-specific roles are owned by the application team.
• Customer account authentication is owned by Customer Support.
• Device-local passwords are owned by Endpoint Support.
• Network authorization after successful authentication is owned by Network Operations.

Exclusions are especially important when two teams share language such as access, account, connection, client, or permissions.

Required context

Identify the fields or ticket details needed to make the route safely:

• Account type
• Affected application or service
• User population
• Device ownership
• Environment
• Error stage
• Requested action

Also define the action when the context is missing: request clarification, enrich from an asset record, or send to assisted review. Do not force a confident route from insufficient evidence.

Positive and negative examples

Use short, realistic examples that expose the boundary.

Positive:

• "New employee cannot enroll a security key for the corporate account."
• "Restore a disabled directory account after leave."

Negative:

• "Add the finance approver role in the expense application." Route to Business Applications.
• "Customer cannot reset the password in the public portal." Route to Customer Support.

Examples should represent concepts and ownership, not phrases the classifier is expected to memorize.

Escalation and fallback

State when the group should receive an exception and when it should not. Include incident bridges, executive support paths, security review, or geographic restrictions only when they change initial ownership.

Keep fulfillment handoffs separate from intake ownership. A team can be the correct first owner even when it later coordinates with another group.

Write boundaries in pairs

Resolver groups do not exist independently. Review adjacent definitions together.

If Network Operations owns connectivity and Endpoint Support owns managed devices, write both sides of common boundaries:

• Failure across multiple devices or sites points toward network ownership.
• Failure isolated to one managed device points toward endpoint ownership.
• VPN authentication failure may require identity context.
• A connected VPN with unreachable internal services may require network context.
• A broken VPN client installation remains an endpoint issue.

Pairwise review catches contradictions that individual team owners may miss. It also reveals gaps where neither team claims a common ticket type.

The process in How to Audit AI Ticket Misroutes and Build a Triage Feedback Loop helps identify which boundaries need attention from real correction data.

Separate classification from priority and escalation

A resolver-group definition should answer who owns the initial work. It should not become a container for every service desk rule.

Keep these decisions distinct:

• Classification: Which team owns the ticket?
• Priority: How quickly should the organization respond?
• Automation eligibility: May the system assign without review?
• Escalation: Does the ticket require special coordination?
• Fulfillment: Which teams participate after intake?

A sentence such as "Identity Operations handles urgent access problems from executives" mixes ownership, impact, and escalation. Define identity ownership in the group scope, then apply executive handling through policy.

Separating the decisions allows the same classification to remain correct when priority or escalation policy changes. The broader taxonomy considerations in How to Classify Support Tickets with AI are useful when category and priority labels currently overlap.

Prefer discriminating evidence over broad keywords

Some terms are common across many queues:

• Access
• Error
• Account
• Application
• Server
• Slow
• Connection
• Permission

A definition built around those terms creates overlap. Look for evidence that changes ownership:

• The affected object
• The requested action
• The stage where failure occurs
• Whether the problem affects one user, one device, one application, or many
• Whether authentication succeeded
• Whether the issue is configuration, availability, or authorization
• Whether the service is employee-facing or customer-facing

For example, "access" becomes useful only when paired with the target and action:

• Create cloud account: Cloud Platform
• Add application role: Application Support
• Restore workforce account: Identity Operations
• Approve building access: Facilities

The routing system still reads natural language, but the definition tells it which evidence has operational meaning.

Model missing context explicitly

Many routing failures begin before classification. The ticket may not name the affected application, distinguish a customer from an employee, or say whether authentication succeeded.

For each boundary, ask:

1. What fact decides ownership?

2. Is that fact reliably present in the subject or body?

3. Can it be added from a form, user profile, service catalog, or asset record?

4. What should happen when it remains unknown?

Write that requirement into the definition and workflow. A route that depends on an application name should not auto-assign a ticket where the application field is empty.

This is also a testable property. The companion guide on how to test AI ticket routing changes before production includes missing-context and boundary cases, not only clear examples.

Avoid definition collisions

A collision occurs when multiple groups reasonably claim the same ticket based on their current definitions.

Review the full definition set for:

• Duplicate service names
• Shared request types
• Parent and child teams claiming the same scope
• Product names that also describe a technical capability
• Regional teams overlapping global teams
• Project teams that no longer own production support
• Broad catch-all language
• Conflicting exclusions

Do not solve every collision by making definitions longer. Sometimes the operating model is genuinely ambiguous. The service desk may need an ownership decision, a first-line diagnostic queue, or an intake field that identifies the correct path.

Definitions should reflect resolved ownership, not disguise unresolved organization design.

Build definitions from production evidence

Use four sources:

• Service catalog and ownership records
• Resolver-team interviews
• Recent correctly routed tickets
• Misroutes and reassignments with root-cause labels

Team interviews reveal intended scope. Production tickets reveal actual language. Correction records reveal where the intended scope is not understood or not represented in intake.

Sample across channels and user groups. Email subjects may differ from portal forms. Employees may use legacy product names. A newly acquired business unit may describe the same service differently.

Do not paste sensitive ticket text directly into definitions. Convert examples into concise patterns with only the context needed to demonstrate ownership.

Example: define Identity Operations

A usable definition might be organized as follows.

Owned scope

Identity Operations owns lifecycle and authentication for managed workforce identities in the enterprise directory, including account creation, disablement, restoration, password reset, multifactor enrollment, directory lockout, and directory-group membership.

Included evidence

Tickets should identify a workforce account or enterprise directory action. Common signals include onboarding or offboarding, disabled corporate accounts, directory password reset, security-key enrollment, and enterprise group membership.

Exclusions

The group does not own application-specific roles, customer portal identities, device-local credentials, physical access, or authorization failures that occur after successful network authentication.

Required context

The ticket must identify the user population and the target account or service. Application access requests must identify the application. If account type is unclear, require review.

Boundary examples

• Corporate account disabled after leave: Identity Operations.
• User signs in successfully but lacks a purchasing role: Business Applications.
• Customer cannot access a public account: Customer Support.
• Laptop requests a local recovery key: Endpoint Support.

This format gives the routing system positive evidence, explicit boundaries, and a safe response to ambiguity.

Review definitions with resolver teams

The service desk process owner should facilitate a boundary review with adjacent group owners. Ask each owner to confirm:

• The owned scope is current
• Included requests belong to the team
• Exclusions have a valid destination
• Required context is available
• Examples reflect real traffic
• Fallback behavior is operationally acceptable
• The team can absorb the expected volume

Approval is not a permanent guarantee. Service ownership changes. Add definition review to service launches, reorganizations, acquisitions, platform migrations, and queue retirements.

Test the complete definition set

Test a candidate definition against all other active groups, not only its previous version.

Use:

• Common unambiguous tickets
• Known boundary cases
• Historical high-confidence misroutes
• Tickets missing deciding context
• Rare but high-impact cases
• Examples from adjacent teams
• Current shadow traffic

Compare the recommended team, confidence, and workflow action. A definition can improve the preferred team while also increasing unsafe automatic assignments.

For organizations using score bands, How to Set Auto-Routing Confidence Thresholds for Support Tickets explains why the same score should not automatically imply the same action across every ticket class.

How Layer8 Triage uses team definitions

Layer8 Triage analyzes a ticket's subject and body against the configured team definitions, then returns a recommended team and confidence score.

To use definitions effectively:

1. Supply current, distinct team scopes.

2. Include meaningful boundaries in the definition text.

3. Ensure the ticket text contains the deciding context.

4. Store the definition version with the routing decision.

5. Apply human review or fallback rules outside the definition.

6. Test definition changes before expanding automatic assignment.

A confidence score cannot repair an unresolved ownership boundary. It describes the recommendation under the supplied ticket text and definitions; it does not establish which team should own the service.

Common definition mistakes

Describing only the team name

Names such as Platform or Operations are labels, not routing instructions.

Listing every observed keyword

Long keyword inventories amplify overlap and become stale. Prioritize owned objects, actions, and boundaries.

Omitting negative examples

Positive examples show what fits. Negative examples explain the nearest alternatives.

Encoding workflow policy in the definition

Priority, escalation, and automation gates change for different reasons. Keep them governed separately.

Forcing a route when context is absent

An explicit review path is safer than making the definition pretend that an ambiguous ticket is classifiable.

Conclusion

Strong resolver-group definitions translate service ownership into consistent classification evidence. State the owned scope, included request types, exclusions, required context, boundary examples, and fallback behavior in a common format.

Review adjacent teams together, test the entire definition set, and version every production change. Clear definitions improve AI recommendations, but their larger value is operational: they force the organization to decide who owns what and what evidence is required to make that decision safely.