---
title: "Service"
id: "2156"
type: "page"
slug: "service"
published_at: "2026-10-04T08:29:34+00:00"
modified_at: "2026-10-22T16:38:23+00:00"
url: "https://xedant.com/agents/crm/addons/service/"
markdown_url: "https://xedant.com/agents/crm/addons/service.md"
excerpt: "The add-on Service turns customer requests into tickets: every appeal — a letter to the…"
---

# Service

[https://xedant.com/agents/crm/addons/service/.md](https://xedant.com/agents/crm/addons/service/.md)

The add-on **Service** turns customer requests into tickets: every appeal — a letter to the support mailbox, a form, a chat, a messenger message, a phone call or a record from an outside system — gets one queue, one owner, one status and one deadline. The work is gathered in the Service console, whose tabs are Workspace, Classification, Routing, Intake, Macros and Triage.

![Service add-on, Classification tab: request categories with default priority and queue beside the type and priority dictionaries](https://xedant.com/wp-content/uploads/2026/10/crm-agent-addon-service.png)## Why you need it

Requests arrive from everywhere at once: a letter to the shared mailbox, a question in the website chat, a messenger message, a call. While they are sorted by hand, some get lost — someone already answered, someone else has been waiting three days. The customer does not know what is happening to them, and nobody in the office can say how many requests are open right now or where the pile-up sits.

Service gives every request one place, one responsible person and one deadline. You can see what is waiting for an answer, what is waiting for the customer and what is already done; the queue hands new requests out by itself, ready-made replies speed up the work, and nothing is left “in someone’s memory”. It is the root add-on of the service contour: SLA, Feedback, Portal and ITSM build on top of it.

## What it does

- **One ticket for any request.** The channel is an attribute of the ticket, not a separate product: an email, a website form, a chat, a messenger message, a phone call, the external API or a manually created record all produce the same ticket with a number, a subject, the requester, the company, a queue, an owner, a status, a priority and a category. The door a request came through is configuration. A second letter from the same contact on the same subject inside 24 hours is appended to the standing open request instead of creating a twin, and an outside system that delivers one event twice gets an answer about the standing request and writes nothing.
- **A ticket and a conversation are not the same thing.** A mailbox rule picks one contour — conversations or tickets — and a mailbox configured for both is refused by name, so the same correspondence never lives in two places. A chat becomes a ticket only when an employee runs the conversion verb: the whole dialogue, the bot’s turns included, travels as the ticket’s first system message with the last customer message as the description, so nothing is lost in the handover. Later messages in that chat stay dialogue.
- **A queue and an owner at every moment.** Both are stamped at birth, transfers are journaled handoffs that record from whom, to whom, by whom and why, and a request that no rule can route lands in its queue flagged unassigned in triage — visible and counted, never ticking silently without an owner.
- **Statuses that mean something.** A request moves through new, in progress, waiting for the client, waiting internally, resolved and closed. Resolved means answered and awaiting the client’s confirmation; closed means done. Reopening is a journaled event allowed inside a seven-day window, and it counts into the reopen rate.
- **Classification kept small and honest.** Priorities, categories, types and a request’s own custom fields are curated value sets; a value that tickets reference can only be switched off, never deleted, because history must keep resolving its own words. The taxonomy stays at five to seven types and three to four required fields, and “unknown” and “needs clarification” are legal outcomes. What the sender calls “critical” is kept as the perceived severity — the working priority comes from the queue’s impact and urgency matrix, never from the person who wrote in.
- **Routing and queues as data.** Rule conditions are built from the same filters the lists use, and each queue carries its own assignment strategy: manual, round robin, least busy or by skill. Every automatic assignment writes an explained decision row, the rotation cursor is derived from that journal instead of being stored, and the routing probe answers “where would this request go” with zero writes.
- **When nobody can take it.** The assignment walk skips everyone whose status board says offline; past the stuck threshold the request falls into the triage queue flagged, and the engine stops walking it — a person works it. An absence substitute gets the unstarted requests once, each move journaled with who, when and why, while work already started stays with its owner.
- **Working together inside the request.** Internal notes never move the status, the clock or the owner. A note can mention colleagues by name — a mistyped name refuses the whole note by name — and each person is notified once per note. Watch seats subscribe someone to a request’s correspondence or its whole life, transfer demands a reason, and a split births the second problem as its own child request with its own number and clock and a typed link to the parent. A hint showing who else has the request open is ephemeral and leaves no database rows.
- **The internal line is a server-side rule.** Internal notes and attachments are removed at one serialization seam that every surface walks — the office console, the customer cabinet, the external API and every export — so a customer cannot ask their way to an internal note. Attachments ride the one files surface, and a re-delivered letter re-joins by its own key instead of doubling the thread.
- **What needs attention today.** The Workspace tab groups requests by due soon, already breached, unassigned, awaiting the client, mentions of you and what you follow, beside the load per queue and per colleague. Every number is derived from the journals the moment you read it, so a widget and a board can never disagree. Saved views are personal or shared with a team, with a “me” token that resolves to whoever is reading, plus three ready ones: “Mine today”, “Burning by SLA” and “Waiting on client”. The main list shows the last message and the deadline on every row and puts the nearest deadline on top.
- **Suggestions that never act on their own.** Every new request walks a rules adapter once, which proposes a queue, a category, a priority and matching articles from the knowledge base. A confident proposal is highlighted, a middling one is shown as a hypothesis, a weak one is hidden but still journaled — and when no rule matches, the request carries a counted “unknown” row instead of being folded into “other”. Accepting a suggestion only runs the ordinary office action, with the provenance journaled, and nothing is ever sent to a client on a suggestion’s word.
- **Macros, ready replies and bulk work.** A macro is an ordered bundle: status first, then fields, tags and assignment, and the message last, so a reply can never outrun its own status. Placeholders come from a closed set — an unknown one refuses the save, and a body with no personal field is refused as a form letter — while an unresolvable value blocks the whole application by name rather than sending half an empty message. A public reply demands a dry-run and a confirmation; internal notes do not. One macro can run over a selection of up to 100 requests, showing how many rows it will touch, and every run is journaled.
- **One console.** The Service console gathers the Workspace, Classification, Routing, Intake, Macros and Triage tabs. It only reads: changes are made by agent commands, which can be copied straight from the interface.

## How it relates to other add-ons

Service declares no required add-ons: it is the root of the service contour and switches on by itself. Other add-ons lean on it — [SLA](/agents/crm/addons/sla)
, [Feedback](/agents/crm/addons/feedback)
, [Portal](/agents/crm/addons/portal)
 and [ITSM](/agents/crm/addons/itsm)
 will not install without it, and [Contracts](/agents/crm/addons/contracts)
 rests on Service, SLA and ITSM together — so the practical order is Service first, then whatever builds on it. The product will not let you switch Service off while a dependent add-on is running, because those contours would lose their base.

Two of Service’s own conveniences have add-on-shaped neighbours. Turning a chat into a ticket and the online-or-offline check come from [Inbox](/agents/crm/addons/inbox)
: without it the conversion refuses by name, and the assignment walk simply holds the request in its queue instead of naming a phantom owner. Article suggestions in triage come from the [Knowledge base](/agents/crm/addons/knowledge)
 and work without it. Deadlines on the Workspace tab come from [SLA](/agents/crm/addons/sla)
: without it everything still works, and the times shown are honestly called wall-clock time. Mentions reach people through [Notifications](/agents/crm/addons/notifications)
, and the public form a customer fills in lives in [Portal](/agents/crm/addons/portal)
 — here a request arrives as a finished ticket.

## Honest limits

- An external language model is not connected to triage. The suggestions come from a set of rules, and that is said plainly: the journal names the source “rules”, not “artificial intelligence”. The seat for a future model is prepared; the model itself is a deferral.
- Side conversations inside a request, a manager reviewing a draft before it is sent and shared drafts are not built. Splitting is also simpler than one might expect: the child request carries its own wording rather than moving selected messages out of the parent.
- There is no public request form in this add-on. The form a customer fills in lives in [Portal](/agents/crm/addons/portal) , and the Intake tab shows the mailbox, external API and chat-conversion settings, not a form builder.
- A priority named by the client — “critical” on a form, for instance — never sets the clock. It stays a hint for the agent, while the working priority is decided by the impact and urgency matrix.
- A category, type, priority or custom field value that requests reference cannot be deleted, only switched off, or history would stop understanding its own words. “Unknown” and “needs clarification” remain legal classification outcomes.
- The seven-day reopening window is a fixed constant in this version; making it a per-workspace setting is a recorded deferral.
- Speed and quality reports are numbers for growth, never a competition between employees. No screen builds a “who is best” table: every share shows the denominator it was computed from.

All add-ons → [Add-ons catalogue](/agents/crm/addons)

[← CRM Agent documentation](/agents/crm/docs)