Public sector use case · Zendesk + OpenAI + ServiceNow
Ticket triage and routing
Vague descriptions and inconsistent terminology send similar requests to different queues or hide urgent issues among routine work. Incoming service tickets reach the appropriate team with a recorded category, proposed priority and supporting context.
Systems involved
What each system contributes
The model step runs against the AI provider you choose, including Anthropic, Google Gemini or a model you host yourself. Anything outside a pre-built action runs through an API, protocol or database call, or as Rules + Code in Python, Bash, Go, Java, .NET, PHP, PowerShell or JavaScript/TypeScript, with the same approvals and audit.
Architecture
One governed run
How it starts: A new Zendesk ticket or a materially updated request enters the triage queue.
Step by step
How the process runs
- 01
Read the request
Gather the permitted Zendesk description, conversation and requester context for triage.
- 02
Interpret the issue
The selected model proposes an allowed service category and priority, citing the details that support its assessment.
- 03
Enforce routing policy
Rules map the proposal to permitted queues, preserve required escalation floors and check mandatory service information.
- 04
Route the work
Update the agreed Zendesk fields or create the linked ServiceNow work item, retaining the original ticket reference.
- 05
Review uncertainty
Ambiguous, sensitive or conflicting classifications wait for the designated triage owner before release.
Control
Human decision and exception path
Human decision
A named triage owner decides uncertain or consequential priority changes, including any proposal that would downgrade a required escalation. Routine routing can proceed only within the category and priority bounds approved by policy.
Exception path
- Unrecognized categories route to the general authorized triage queue rather than an invented destination.
- Missing service context prompts clarification while preserving any mandatory urgent escalation.
- Linked-ticket and update-origin checks limit duplicate ServiceNow work and routing loops.
Evidence
What gets audited
- Original request and permitted triage context.
- Model category, proposed priority and cited signals.
- Routing-rule version and any human decision.
- Zendesk updates and linked ServiceNow responses.
Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.
Sovereignty and deploymentRelated
Patterns, connectors and next steps
- ServiceNow-Jira integration
Integration pattern · Incidents and changes reach engineering with context, and status returns to service.
- Zendesk connector
52 pre-built actions
- OpenAI connector
25 pre-built actions
- ServiceNow connector
55 pre-built actions
- Enterprise automation
Governed processes across the systems you already run.
- Citizen request to case resolution
Another public sector use case.
FAQ
Questions about this use case
- Does Nexus replace any of these systems?
- No. Each system keeps its own records. Nexus runs the process between them and records each decision.
- How does the run start?
- A new Zendesk ticket or a materially updated request enters the triage queue.
- What if a step is not covered by a pre-built action?
- The model step runs against the AI provider you choose, including Anthropic, Google Gemini or a model you host yourself. Anything outside a pre-built action runs through an API, protocol or database call, or as Rules + Code in Python, Bash, Go, Java, .NET, PHP, PowerShell or JavaScript/TypeScript, with the same approvals and audit.
- Can the model lower the priority of a critical ticket?
- Not past the policy's required escalation floor; any permitted downgrade that needs judgment goes to the triage owner.
- What happens if the employee or citizen describes several issues at once?
- The model can identify separate topics, but the workflow routes or requests clarification according to the approved service process.
Use case review
Discuss this use case
Bring your version of the process. We will map the systems, approvals and evidence it needs.