# Service desk

> The agent-facing side of employee requests - a triage queue, category-to-team routing from editable reference data, an SLA dashboard on live request data, Telegram alerts, email replies threaded back onto the request, and two-way REST sync with an external ticketing system

Source: https://aipril.dev/docs/solutions/service-desk

## Where a request comes from

An employee submits it on the [corporate portal](https://aipril.dev/docs/solutions/corporate-portal.md). The desk does not
own its own request process - it **consumes the shared one** the portal provides, by reference.

That matters more than it sounds: the employee's view of their request and the agent's view of it
are the same record, in the same process, with the same status. There is no submission form that
copies into a ticket system and then has to be kept in sync with it.

## The agent's queue

One surface to pick up work and route it:

- **Every incoming request**, with its category and priority
- **Category and priority as editable reference data** - your categories, named the way your company
  names them, changed by an administrator rather than by a release
- **Routing rules that map a category to a handling team** - declared reference data, not logic buried
  in code. Adding a category and pointing it at a team is a row, not a change request.

So a request reaches the right team automatically, and when it does not, the fix is editing a table.

## SLA, on live data

A dashboard for managers built on a **request data model** - status, category, priority, resolution
dates - reading current records through the [engine](https://aipril.dev/docs/engine.md) instead of a report somebody
exports:

- **Volume** - how much is coming in
- **Status mix** - what is open, in progress and resolved
- **SLA compliance across categories and priorities** - which is where the answer usually lives:
  the desk is meeting its targets overall and missing them badly on one category

## It reaches people where they are

- **Telegram** - an agent is told when a new request is routed to their handling team, so nobody has
  to watch the queue.
- **Email**, with reply threading - an agent's reply from their inbox **lands back on the same
  request as a comment** instead of starting an unrelated thread. That is the difference between
  email being a leak in the process and being part of it.
- **Resolution notices** go back out the same way.

See [Collaboration](https://aipril.dev/docs/collab.md) for how a thread on a record works, and
[Connectors](https://aipril.dev/docs/platform/integrations/connectors.md) for the delivery path.

## Two-way sync with the ticketing system you already run

Not every company can retire its existing service management tool, and this desk does not require you
to.

- **Outbound** - request updates are pushed to an external system over a generic REST connector:
  Jira, ServiceNow, Zendesk, or an internal tool with an API. **Generic, so there is no bespoke
  integration per vendor** - the target is configuration.
- **Inbound** - the desk accepts updates back over a webhook, so a status changed on the other side
  arrives here without anybody re-keying it.

## Why it is a process rather than a ticket table

Because the demands that actually arrive are process demands: a request type that needs an approval, a
category that escalates past a threshold, a resolution the requester has to confirm.

Those are transitions and rules in a [process model](https://aipril.dev/docs/processes.md) you can open, change and
version - not features you wait for.

## What it is made of

| Part | Built as |
|---|---|
| The request itself | A shared process, provided by the portal |
| Categories, priorities, routing rules | Reference data |
| The queue and the dashboard | Pages and live queries through the engine |
| Notifications and reply threading | Automations over the messaging and email connectors |
| External sync | Generic outbound REST and an inbound webhook |