Service desk

Where a request comes from

An employee submits it on the corporate portal. 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 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 for how a thread on a record works, and Connectors 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 you can open, change and version - not features you wait for.

What it is made of