Ticket console · the agent workspace

The ticket console is where your team works tickets: the queue with saved views on the left, the customer conversation in the center and the context with SLA clocks and AI on the right. It also holds the inbound email address, macros, routing, automations, incidents, the knowledge base and the team's metrics.

The ticket console is SellioCRM's service workspace: one place to work tickets in a queue, from the customer's first email to the satisfaction survey. It uses the CRM's own Ticket object, so everything you already record (subject, company, contact, category, channel) still holds and shows up in the customer's 360 view.

Open it from the side menu, in the Service group, under Ticket console. The Tickets object stays in the same group for people who prefer the form, the board by status and the list views.

A three-pane layout

The console opens in three panes, designed for people who work service all day: views and queues with counters on the left, the customer conversation in the center, the ticket's context on the right. On a phone the views pane becomes a selector at the top of the list, so it takes no space.

The queue and saved views

• The left column brings ready-made views with the number of tickets in each: Open, Unassigned, Mine, Pending (waiting on the customer or on a third party) and Resolved today.
• Saved views: create a named filter by status, priority, assignment and group, for example Urgent for the support team. It appears in the list with its own counter.
• Above the queue sit the search (by subject or requester), the priority filter and the sorting: newest, oldest, by priority or by SLA due date.
• Each row shows the subject, the requester, the status, the priority, the assignee and the SLA state, with colored badges for a quick read.
• Bulk actions: check the box at the top to select several tickets and apply a status or an assignee all at once.

The agent console

When you open a ticket, the conversation appears in the center in chronological order and the properties sit on the right: requester, inbound channel, tags, status, priority, category, assignee and group. Changing any property saves immediately.

1. In the composer, choose Reply to customer to write something the customer will see, or Internal note to record something visible only to the team.
2. The internal note appears highlighted in a different color, so it is never confused with what was said to the customer.
3. Click Attach to send files along with the message (up to 25 MB each). On a public reply, the attachment links also go in the body of the email sent to the customer.
4. Write and click Send (or Add note).

• Ticket number: every ticket gets a sequential number per organization, in the format #000123. It is immutable and appears in the queue, at the top of the ticket and in the reply email.
• Timeline: the Timeline tab merges, in order, the public and internal messages and the change events (creation, status, priority, assignee and other properties).
• Mentions and followers: in an internal note, use Mention to pull in a coworker. They get a notification and start following the ticket. Anyone can follow or unfollow from the properties pane and is notified on every update.

Macros and variables

1. Click Manage macros to create canned replies with a title and a body.
2. Optionally, the macro sets the status and the priority to apply when it is used.
3. In the composer, select the macro under Apply macro: the body drops into the reply field and, if configured, the status and priority are applied.

Macros and replies accept variables in double braces, filled in at send time: {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} and {{org_name}}, among others. Under Channels and routing you set a Service signature, appended to public replies; the agent's personal signature, when there is one, takes precedence.

SLA: targets, pauses, hours and holidays

The SLA state appears in the queue and on the ticket: On time or SLA breached while it is open, and Resolved on time or Resolved late once it is resolved. On the right, the first response, next reply and resolution clocks count down and change color: green, amber near the target and red once it is past due. When you change the status to Resolved or Closed, the resolution date is stamped automatically.

• Automatic pause: moving the ticket to Waiting on customer or Waiting on third party pauses the resolution clock and shows an SLA paused badge. Returning to an active status resumes the clock. Time spent waiting counts neither against your target nor in the metrics.
• Next reply: each policy can set a next reply target. The clock starts when the customer replies and resets on every new public reply from the agent.
• Business hours: on the SLA and hours tab you set days, hours and the time zone (enter a zone such as America/New_York so daylight saving is respected). Turn the restriction off to count elapsed time (24x7 service).
• Holidays: register holidays by date. On those days the office counts as closed and the target is pushed to the next business day.
• Policies: each policy matches by priority, group or category (blank means any) and sets targets in business minutes. They are evaluated in list order and the first active one that matches wins. With no policy matching, the hours per priority under Settings, Service apply.
• Breach risk: an estimated bar shows whether the ticket is at low, medium or high risk of missing the target, along with the reason.

Inbound email: the email becomes a ticket

1. Open the ticket console and go to the Channels and routing tab.
2. Click Generate support address. The CRM shows an address in the format support+your-code@domain.
3. In your email provider, forward your support inbox to that address.
4. That is it: new emails open tickets and the customer's replies land in the same conversation.

The sender is matched to a Contact by email; the first time around the Contact is created, and the ticket's channel is set to Email. Every reply sent to the customer carries the ticket code in the subject, in the format [#XXXXXXXX]. When the customer replies keeping the code, the message joins the same conversation instead of opening a new ticket; if the ticket was resolved or closed, it reopens.

Automatic acknowledgement: under Channels and routing, turn on Acknowledgement and write the text with variables. When an email opens a new ticket, the requester immediately receives the acknowledgement with the ticket number. It starts off.

Merging tickets and side conversations

When the same subject turned into two tickets, open the one you want to keep as the main one and click Merge. The other one's messages move into the main ticket and it is closed with a note pointing to where it went.

Need to talk to a vendor or another team without the customer seeing it? Use Side conversations, right below the main thread: enter a subject and the participants by email, write the message and the CRM sends it. Everything is recorded on the ticket, kept apart from the conversation with the customer.

Auto-assignment and automations

Under Channels and routing, set for each team how tickets are distributed as they enter the group: Round-robin (rotates among the agents) or By load (the agent with the fewest open tickets goes first). Leave it Off to always assign by hand.

On the Automations tab you build rules of the form when something changes, then act. Each rule has an event (the ticket is created, or a property changes), optional conditions on status, priority, category, group and assignee, and one or more actions.

• Actions: set the status, priority or category; assign to an agent or to a group; apply a macro; notify the assignee; notify the whole group; send the satisfaction survey.
• Rules run at the exact moment of creation or change, anywhere in the CRM: the console, editing the record or an integration.
• Drag by the handle to the left of the name to reorder; they are evaluated top to bottom.
• Time-based automations: these run on their own periodically and act on the clock, for example escalating a ticket with no first response for X business hours, warning when the target is close to breaching, or closing tickets resolved N days ago. Each one acts at most once per ticket.
• Outbound webhooks: under Channels and routing, notify external systems on every ticket event (created, updated, resolved, new message), sending to a signed URL or to the messaging channels already connected in the Integrations hub.

Artificial intelligence on the ticket

With AI enabled, the right-hand pane analyzes the ticket and suggests: category and urgency, customer sentiment scored 0 to 100, a summary of the history, similar tickets and knowledge base articles. In the composer, the Suggest reply (AI) button drafts a reply from the conversation, in your interface language. The AI never sends anything to the customer on its own: you review, edit and decide.

Knowledge base and help center

Your knowledge base feeds a public self-service portal with search across titles, content and tags. At the bottom of the page, the still need help form suggests related articles as the person types (deflection) and, if it is still necessary, opens a ticket straight in your CRM.

• Under Marketing, Knowledge base, the Articles tab lets you write, edit and send for review; the Review tab is the approval queue (Approve and publish, or Reject with a reason); the Import tab creates a draft from a URL; the Feedback tab shows the most helpful articles and the ones that need attention, based on reader votes.
• Every save keeps a history and you can restore an earlier version.
• Each article has a language, and the public search can filter by the reader's language.
• On the SLA and hours tab you build the portal's intake forms: beyond name, email, subject and message, add your own text, list or email fields, with conditional display. Mark one as the default for the help center to use.

Incidents and status page

1. Open the console's Incidents tab and create an incident with a title and a severity.
2. Link the tickets affected by the same event.
3. Publish updates on the incident's timeline and notify everyone affected at once, by email to the requesters of the linked tickets.
4. When you resolve it, record the root cause and the post-mortem.
5. Mark it as public to expose a status page open to your customers.

Satisfaction and metrics

When you resolve or close a ticket, the CRM automatically emails the requester a satisfaction survey, with a 1 to 5 rating and a comment. It goes out once per ticket. When the customer answers, the rating appears in the console's Satisfaction block and is written to the ticket's own fields. Turn it on or off under Automations, Satisfaction survey, and use Resend survey whenever you want to ask again.

On the Metrics tab you follow a 7, 30 or 90 day window: tickets created, resolved and open, average first response time, average resolution time, percentage within SLA, average satisfaction with the response rate, backlog, first contact resolution, reopen rate and load per team, broken out by channel and by category plus a table per agent. The indicators show the change against the previous period and a small daily chart, and the reports can be exported to PDF or XLSX.

Common questions

• Sending the survey depends on the requester's email, from the ticket field or the linked Contact, and on email sending being configured.
• When you export or anonymize a data subject under Settings, Privacy, the content of that requester's messages and ratings is included or anonymized as well.
• Integrations with external help desks create tickets in the CRM automatically; once created, you work them here like any other.
• In the mobile app you can also follow the queue, open a ticket, reply and change the status.
• For the customer to follow their own tickets, reply and reopen them, see the customer portal article.

Parent and child cases, auto-reply rules and channel mapping

A case can now hang from another one. Set the parent on the case and the children show up as a list, with a guard that refuses a loop or a chain that is too deep, and a warning when you try to close a parent that still has open children. Auto-reply became **rules** instead of one fixed text: each rule has its own conditions (channel, category, priority, business hours, first message only, keywords) and its own message, and the first one that matches wins. The anti-loop guard is not switchable, on purpose: answering an automatic mailbox is how two answering machines end up talking to each other forever. And the channel of a case now comes from a **mapping table** you control, so a case that arrived by phone in your help desk stops being recorded as "portal" and your reports by channel stop lying.

Where these live: the parent and the children appear on the case itself, in the **Related cases** panel. The rules are in **Settings → Automatic replies**, and the mapping in **Settings → Ticket channels**; both are for whoever administers the account.

The case has a third tab, **Context**, and it is where the console stopped sending you to another screen. It brings the ticket's own fields (including the ones you created), the related records, the activities and tasks, the files, the parent and child cases, and the other open cases from the same customer. If you designed a Canvas for the Ticket object, that layout governs this tab too, so you do not draw the same thing twice.

Closing a case with an outcome code

Resolving a case used to mean typing free text into Resolution. That describes what happened, but it does not classify it: two agents write the same outcome ten different ways, and nobody can answer how many cases last month were a product defect and how many were a misconfiguration. The Category field does not help either, because it classifies the subject when the case opens, not the outcome when it closes.

So the outcome is now a short list you control, in **Settings → Outcome codes**. Each code has a label, a scope, and a switch for whether choosing it requires an explanation (use that one on "Other", which otherwise explains nothing). The same list serves cases and phone calls, so you keep one vocabulary instead of two that say the same thing.

1. Open Settings → Outcome codes and click Seed defaults, or write your own list.
2. Turn on "Require an outcome when resolving" if you want it enforced.
3. In the console, pick the outcome in the Wrap-up box on the right before you resolve the case.

Three behaviours worth knowing, because they are deliberate:

• **Turning the requirement on before you have any codes does not block anything.** It would otherwise freeze every case in the company on the day someone ticked the box, with nothing available to choose.
• **The requirement is enforced by the server, not by the screen.** Closing from the list, from a macro, from the API or from the terminal goes through the same check.
• **A code that has already been used cannot be deleted, only deactivated.** Deleting it would take away the meaning of every case closed with it, and your old reports would quietly start lying.

Quick text: ready phrases behind a typed shortcut

Until now the only ready-made text in the console was the macro, and a macro also applies a status and a priority: dropping in a phrase changed the ticket without anyone asking for it. Quick text writes nothing but the text. That is why it can be light, personal, and reachable by a shortcut you type.

1. In the composer, type :: followed by the start of a shortcut, for example ::hi.
2. Keep typing to narrow the list, or type :: on its own to see the whole library.
3. Pick a phrase from the list, or finish the shortcut and confirm to insert the one that matches exactly.
4. Read the text before sending: variables in double braces, such as {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} and {{org_name}}, are filled in when the reply is sent, exactly as in macros.

There are three libraries: **personal** (only you see it), **team** (whoever is in that team) and **company** (everyone who answers). The same shortcut may exist in more than one, and the one closest to you wins: your personal phrase beats the team phrase, and the team phrase beats the company one. So you can keep your own version of ::hi without asking anyone to change the house standard.

• **A shortcut has no spaces and no colon**, and is at most 40 characters. A shortcut with a space could never be typed after ::, so it is refused when you save instead of becoming a phrase that never shows up.
• **The shortcut is unique inside its own library.** The same ::hi can exist as a personal phrase and as a company phrase; two company ones cannot.
• **The search ignores case and accents** and looks at the shortcut, then the title, then the folder. The body is never searched: one common word would match half the library and the shortcut would lose its point.
• **The order is always the same**: shortcut that starts with what you typed, then shortcut that contains it, then title, then folder. A list that changed order between two openings would make you pick the wrong phrase from muscle memory.
• **The folder is free text** and only groups the library on screen. There is no separate list of categories to maintain.

Your personal phrases are yours to create, edit and delete, without asking anyone. Team and company phrases are house standards, because they change what everyone will send to customers tomorrow, so they belong to whoever administers the settings. Nobody edits somebody else's personal phrase, not even an administrator.

Ticket emails: your own text per event, language, category and queue

Five moments of the ticket can carry a text of your own: **opened**, **updated**, **resolved**, **survey** and **closure**. Each template is written in one language and can, optionally, be restricted to a category, to a queue, or to both.

The choice follows a declared order, and it reads best in two halves: the system first decides **what to say** and only then **in which language to say it**. Families are visited from the most specific to the most generic: queue and category, then queue, then category, then the generic one. The queue weighs more than the category because the queue is the team that answers and the text is its voice; the category is only the subject.

• **An empty filter is a wildcard, a filled one has to match.** A template with no category serves any category. A template with a category serves that one only, and never doubles as the generic text.
• **Language, inside the family that was chosen**: the exact one first (pt-BR), then the same base language (pt-PT serves pt-BR), then the reserve language, which is English unless you say otherwise.
• **A family with none of those three languages is skipped**, and the next, less specific one is tried. Sending the generic text in the reader's language is better than sending the right text in a language they do not read.
• **Specificity comes before language.** If the Billing family exists only in English and the generic one exists in Portuguese, a requester who writes in Portuguese gets the Billing text in English. The fix is to add the Portuguese line of the same family, which is exactly what the table asks of you.

The language taken into account is the **requester's**, the person who reads the email, not the agent's. Subject and body accept the same variables as macros and quick text, and the preview shows which template won and in which language before anything goes out.

Swarm: calling people into a hard case, and recording what came out of it

A swarm session records the ritual that until now lived scattered across internal notes: who was called, in what role, to answer which question, by when, and what was concluded. **It records the session; it does not open a Slack channel and does not start a video call.** The conversation keeps happening where it already happens (internal note, mention, followers, internal chat); what starts to exist is the memory of it.

1. On the ticket, open a swarm and write the reason. A deadline is optional, and cannot be in the past.
2. Whoever opens the session is the **reporter**, and starts following the ticket.
3. Call the people you need as **expert** (no limit) or as **scribe** (a single seat). Whoever is called gets a notice carrying the reason, and starts following the ticket.
4. Close the session with the **outcome**. It is written back to the ticket as an internal note, so the next agent to pick up the case reads it without opening anything else.

• **One open session per ticket.** Two would split the attention in half, and the outcome would have no single home.
• **Reporter and scribe are single seats while they are taken**; expert has no limit, because calling people is the whole point of a swarm.
• **The reporter does not leave the session.** The way out is closing it with what was concluded, even when that is 'nothing was concluded'.
• **Closing requires the outcome**, and it ends everyone's participation, so the people-minutes stop growing on their own.
• **Whoever left keeps showing in the record.** Who took part has to still be true tomorrow.

Scheduled follow-up and personal reminder

Two actions that look alike and are not. A **follow-up** is a task about the ticket: it can go to someone else, and it shows up in the day's list like any other task. A **reminder** is always yours, and it rings at the time you asked for, not in the end-of-day summary.

1. On the ticket, choose Schedule follow-up or Remind me.
2. Write when, in your own words: tomorrow 9am, in 2 hours, friday, next week, or a date such as 2026-09-10 14:30. The ten languages of the product are understood.
3. For a follow-up, pick the type (task, call, email or meeting) and, if you want, the person who takes it. A reminder is always a task, and always yours.

• **A day with no time becomes 09:00** in the organization's time zone, the same default the rest of the product uses.
• **A duration keeps the current time of day**, because a duration already carries it. Minutes and hours count in real time; days and weeks walk the calendar, so daylight saving does not move them.
• **A time that has already passed goes to the next day**, the way every reminder app behaves. A day in the past is refused instead of guessed: guessing which day you meant would be inventing.
• **Further ahead than 365 days is refused.** It is the filter for the wrong finger, the 2027 typed in 2026 that nobody would ever see.

The screen echoes the time that was actually **saved**, not the words you typed, whenever 09:00 was assumed for you or the time was pushed to the next day. Two different answers to 'when is this due' is exactly the confusion that echo exists to prevent.

Work tabs: several cases open at the same time

The console used to open one case at a time, and picking another one replaced the previous. Whoever works in volume keeps three or four cases going (one waiting on the customer, one waiting on engineering, one being written), and every switch lost the draft and the place in the scroll. The bar of work tabs sits above the conversation, and it appears as soon as there is a second thing open.

• **A single click opens a preview tab**, shown in italics, and the next preview takes its place. Writing in it, or pinning it, makes it permanent. Without that, browsing a queue of twenty cases would open twenty tabs.
• **The same case never opens twice.** Clicking it again only activates the tab, with the draft and the sub-tab you left there.
• **A blue dot means there is a written and unsent reply** in that tab. It is what you need to see before closing it, not after.
• **Each tab remembers its sub-tab** (Conversation, Timeline or Context), so you come back where you were and not at the beginning.
• **Up to eight tabs.** Above that, the oldest tab with no draft is dropped; if every tab has a draft, the limit gives way, because losing written work is worse than a long bar.
• **Closing the active tab activates the neighbour on the right**, and the one on the left when there is no right, the way a browser does.

**Close saved** closes every tab with no draft and keeps the ones with a draft: tidying up never carries written work away with it. The tabs live in your own browser, on this device, so they are yours and not the team's.

Customer context: health, value, plan and support history

The Context tab of a case opens with a block that answers, before you write a single line, whether this customer is doing well, how much they are worth, which plan they are on and how many times they have already been let down. None of it is typed by anyone: it is composed from what the product already keeps about that account.

• **Health** shows the score and, more importantly, **the factors behind it**. A number alone tells you nothing you can act on; the factors say whether the problem is usage, support, money or the relationship.
• **Value** brings won revenue, recurring revenue and the last movement, so an upgrade last month and a downgrade last month do not look the same.
• **Plan** says which plan, since when, and when it renews, and it flags a renewal already marked at risk.
• **Support history** counts earlier cases, how many broke the SLA, this customer's own satisfaction score and whether there is a critical case open right now.

Below the block, the whole conversation with this contact appears on a single line, whatever the channel: chat, SMS, WhatsApp, email and cases together, in order. It is the same history the contact record shows, brought into the console so nobody has to change screens to remember what was already said.

Supervision: the same operation, seen by whoever coordinates it

The console answers "what do I do next?" for whoever is answering. Supervision answers a different question, for a different person: is the operation coping right now. It is a separate screen, built to stay open on a wall, and it refreshes on its own.

• **Is the operation coping?** Open items per queue, how many have no owner, how many are waiting on us, and how many are about to break their deadline in the next hour. Knowing what is about to break is not the same as knowing what already broke, and the panel keeps the two apart.
• **Who is overloaded and who is free?** Open items per person against that person's cap, who stepped out of the rotation, and who leads the queue.
• **Where is the bottleneck?** The queue with the longest wait, the channel bringing the most in, and the queue nobody can pick from, because it requires a skill no one on the team has.
• **What happened in the last hour?** The assignment trail is already append only, so the panel simply shows it.

Supervision is for whoever administers, and that is deliberate: it shows each person's workload and who is out of the rotation. Monitoring people is a declared act of management, not a side effect of opening a screen. The panel is read only, so nothing on it reassigns or reprioritises: it points, and the work is done where it already lives.

Service catalog: a storefront instead of a blank case

Whoever needs something internal today opens an empty case and writes down whatever they remember. The catalog replaces that with a shop window: a list of what can be asked for, each item carrying its own form, its queue and its priority. The request opens a real case, already filled in.

1. Under Settings, Service catalog, whoever administers builds the catalog: categories, items, and the questions each item asks.
2. Anyone opens the same screen, picks a service and fills in its form.
3. The system opens a case in the item's queue, with its priority and the answers inside, in the same format the portal already uses.
4. If the item requires approval, the case opens right away and the pending approval blocks its resolution: nobody closes it before someone decides.

• **Deactivating an item does not cancel what was already asked for.** It means "stop asking for this", never "cancel what is in progress": cases already open stay open, with the same queue and the same deadline.
• **An item that has already been requested cannot be deleted, only deactivated.** Deleting it would make the history lie about what was asked for.
• **The request freezes a snapshot of the form.** Change the questions later and the old request still shows the questions that person actually answered.
• **The status of a request is not a copy.** It is read from the approval itself every time, so it can never drift from what the approval engine decided somewhere else.

Service catalog · fulfilling the request

A catalog item can carry a fulfillment plan: the things that have to happen after someone asks for the service, in the right order. Each step becomes a **real task**, with an assignee, a due date, a reminder and a place in the daily task list of the person who has to do it, and the dependency between steps is the same one tasks already have. The plan is frozen into the request when fulfillment **starts**, not when the service is asked for: editing the item later never rewrites a request already running, and the new version applies from the next start onward.

Whoever coordinates the work gets the fulfillment queue: what is pending, with whom, and for how long. An approved request that nobody has started yet appears at the **top**, with its age in plain sight, because approving does not start anything, a person still has to put the plan to run. An item with no approval to wait for starts as soon as it is requested.

1. Draw the plan on the catalog item: subject, task type, due date in days counted from the start, who gets it and, when it matters, the previous step it depends on.
2. When someone requests the service, the ticket opens as it always did. If the item requires approval, fulfillment waits for the decision; with no approval to wait for, it starts right away.
3. When fulfillment starts, the plan is frozen into the request and the tasks are created in dependency order, each one with an owner and a due date.
4. The request panel on the ticket shows every step, who is holding it, the due date and what is already done. The steps also show up on the ticket timeline, because they are ordinary tasks tied to the case.
5. Click Delivered when the service actually reached the person. A required step still open blocks it, with the reason in plain sight; a step marked as not required never blocks.
6. Marked it by mistake? Reverse the delivery with a note. That is a new entry: the earlier delivery stays in the history, nothing is erased.

Customer assets · the case is about this equipment

A ticket can now point to the customer's **equipment**, the installed unit with its serial number, and not just to the product model that was sold. On the ticket you pick it from the customer's installed base, searching by serial number, which is how the customer identifies it on the phone. Only equipment belonging to the ticket's customer can be linked, and from that moment on the equipment's own history tells the service story: linked, unlinked and resolved cases sit on the same timeline as the installation, the moves and the maintenance.

Downtime is recorded by **people**, or from the ticket itself. There is no telemetry and no machine signal here, so availability, MTTR and MTBF are worth exactly what the discipline of whoever records them is worth. The screen says that out loud instead of dressing the number up.

• Warranty and coverage: the warranty badge (active, expiring, expired) and the service contract show up before you open your mouth to the customer.
• Location: moving the equipment records where it went, so the location history is the reading of those moves, not a single field that forgets the past.
• Replacement with lineage: replacing retires the old unit and creates the new one inheriting account, contract and location, with an event on each side pointing at the other.
• Life cycle: active, in maintenance, in RMA, retired and written off. Written off does not come back, because writing off is an accounting fact; the way back is registering a new asset with the lineage of the old one.
• Downtime: open and close a stoppage, planned or unplanned. The same asset is never down twice at once, and overlapping stoppages are merged before being added up, so availability never goes negative.
• Availability: the percentage over the window, with the planned share separated from the unplanned one, because a maintenance window agreed with the customer is not a broken promise. MTTR and MTBF stay empty without enough samples.
• Risk and next action: criticality, age, repeated failures, coverage and measured availability add up to an explainable score, and the engine states what it had to assume for lack of data.

Knowledge base · ownership, review and usage

The knowledge base gained the layer that answers who is responsible for each article and whether it can still be trusted: an owner, a reviewer, a review cycle in days and, from those, the article that is **overdue for review**. The governance board is live, it is calculated as you open it, so it never depends on a nightly sweep having run. Only published articles are held to it: a draft is still being written and an archived one is out of circulation.

Visibility stopped being just published or not. Each article now has an audience: **external** is what the help center and the portal show to anyone with the link, and **internal** never leaves the CRM. Every article is born external, exactly as it behaved before, so nothing changes until you decide otherwise.

• Owner and reviewer are people from your team, set per article. Without an owner the article is flagged on the board, which is where a missing owner gets resolved.
• Review cycle in days: the next review is the last review plus the cycle. An article with no cycle never falls due, and nobody is nagged about it.
• The overdue notice goes to the article's **owner**, once per due date. An article with no owner notifies nobody, because dumping the ownerless half of the base into the admin bell every day teaches people to ignore the bell.
• Archiving takes an article out of circulation with an author, a date and an audit trail, instead of someone quietly editing a status field. Unarchiving sends it back to draft, never straight back on air.
• AI draft from resolved tickets: pick up to five closed cases, optionally point at a gap, and the assistant writes one reusable article. It is **always born as a draft** and enters the same review queue as anything written by hand: AI proposes, a person approves. Only resolved tickets are used, because an open case does not have an answer yet.
• Usage per article: how many visits opened each article, through which door, and which published articles nobody read in the period, which is the slice of the base that is not working.

Self-service · the assistant and the deflection rate

The public knowledge base now has an assistant. It answers grounded **only** in your published articles and shows the sources it used, so whoever reads a generated answer can check where it came from. When it finds nothing it says so and points to the ticket form, and the unanswered question is recorded as a coverage gap. It never fills the silence with an invented step, and when no AI is configured it shows the articles it found instead of pretending to be out of order.

That is what makes deflection measurable, and the definition is deliberately strict: an **avoided ticket is an explicit statement** from someone who was on their way to open a case and gave up, after receiving an answer or a suggested article and clicking that it solved the problem. Nothing else counts.

• Reading an article does not count. Whoever reads may be comparing, researching, or reading the wrong article on the way to opening the case anyway.
• Searching without an outcome does not count. Closing the tab is not success.
• The ticket beats the statement: if the person said it was solved and opened a case in the same visit, the visit counts as a ticket. We would rather measure less.
• A visit that decided nothing is left out of the rate entirely, neither on top nor at the bottom, and is reported separately as undecided.
• The rate is the share of the visits that **decided something** and decided not to open a ticket. With no decision in the period the rate is empty and never 0%, because not knowing and zero per cent are different answers.
• The funnel (searches, questions, answered questions) measures reach, not result, and none of it enters the rate.

Service analytics · ready-made reports, findings and forecast

The Analytics tab of the ticket console answers what no screen answered before: how long the queue has been sitting, how much of each promised milestone was met, how much escalated, what voice, bot and messaging have been doing, what incidents cost in tickets, where the volume is heading and, at the end, what to do about it. Every number arrives already calculated by the server, so no two screens can quietly disagree about the same figure.

Two readings that look alike and are not: **age runs on the clock** (calendar time since the ticket was created) and **the target runs on business hours** (the SLA promise, with pauses discounted). They have different names on purpose. Mixing them would give you two numbers with the same label and no way to tell which one was broken.

• Ready-made reports: one click turns a preset into a report of your own, named in your language. From there it is an ordinary report, editable, shareable, exportable and schedulable like any other, with no separate engine behind it.
• Findings: SLA below target, more coming in than going out, an aging queue, reopenings, escalation, knowledge gaps. Each one comes with the numbers that support it, a likely cause and an action, ordered by weight.
• Milestone compliance: first response, next reply and resolution, and not resolution alone. Next reply is every time the customer comes back after already being answered once, and only cases that actually had a target enter the count.
• Backlog aging in bands (under a day, one to three days, three to seven, over a week), overall, per queue and per agent, with the oldest case in sight.
• Bot outcomes are three, not two: contained without a human, handed off to a human, and **asked for a human and nobody came**, which is an abandoned queue and used to hide inside the contained number.
• Voice, messaging and incidents each get their own reading, because a WhatsApp conversation is not a ticket and an incident is measured by what it cost in cases and by the root cause that keeps coming back.
• Volume forecast: trend plus a day-of-the-week index, so Saturday is not projected as if it were Tuesday.

AI that acts on the case, under a policy

The AI already read every case (category, urgency, sentiment, summary) and nobody consumed it. Now it can **write** category and priority on the case, but only under a policy the workspace sets, and it is **off by default**: nothing changes until whoever administers turns it on under **Settings → Service AI**. Field by field you choose between **Do nothing**, **Suggest (a person confirms)** and **Write when confident**. Writing only happens above a confidence threshold you set (50% to 100%, 80% by default); below it, the same proposal turns into a suggestion that one click applies.

In the console the **AI suggestions** box lists what is waiting: the proposed value with its confidence and the reason it was not written (policy says suggest only, below the threshold, a person had already chosen a value, daily limit reached), with **Apply** and **Dismiss**. What the policy wrote on its own stays visible in the box's history as written by policy, so the agent knows the category was not their doing. **Classify with AI now** runs the same policy by hand. The box disappears for a workspace that has not turned the policy on and has no suggestion.

• The AI classifies against **your own** category and priority lists. A value that is not one of your options is never written, and with no options registered for a field it stays quiet instead of inventing one.
• A value chosen by a person is not overwritten. By default the automatic mode only fills what is empty or still at the form default; replacing a human choice requires the explicit option **Allow the AI to replace a value a person chose**.
• A reply draft is **never sent**. Accepting one puts it in the composer with **Use in composer**; reviewing, editing and sending remain yours. Resolving and closing a case are never automatic either: there is no mode for that, anywhere.
• Every automatic write counts against the daily action limit shared with the agent (**Settings → AI**, agent autonomy). At the limit the AI goes back to only suggesting and says so in the box and on the policy page, with today's numbers: written, suggested, held back by the limit, waiting for a person.
• Everything leaves a trail: each automatic write in the agent action ledger, each AI call in the AI audit log when that log is on, and the policy change itself in the audit trail.
• **Run when a case is created** applies the policy with no automation configured. With it on, creating a case from the screen waits a few seconds for the AI before the case shows up; if the AI is unavailable (no key, spending cap, provider down) the case is created anyway, with nothing written.
• Case automations and time rules gained two actions: **Classify with AI (per the Service AI policy)** and **Draft a reply with AI (never sent)**. A rule that first sets the category and then asks the AI does not see the AI undo it.
• The same analysis of the same text never produces two suggestions and never counts twice against the limit; repeating a run costs nothing.

Field work from the case

A case that needs a visit no longer gets retyped on another screen. With the Field Service vertical on, the **Field work** box in the console opens the field job straight from the case, schedules the visit, and shows the agent what the customer asks on the phone: next visit, whether it is overdue, last visit, technician, equipment. Everything is read live from the job, its visits and its status history, so a change made on the dispatch board is what the case shows on the next open. The job carries the case's subject and description as the problem, and the case priority mapped to the job's (critical becomes urgent, high stays high, medium normal, low low).

**Open field job** asks for the **property**, which is mandatory because the case does not know the address of the visit: the customer's properties come first and marked, a customer with a single property has it preselected, and a case with no contact or company searches the whole base by name, address or ZIP (the first 50, with a notice to refine). When the case points to an asset whose serial number matches exactly one piece of equipment on that property, the equipment is **suggested** with a checkbox, never chosen for you. Job type (repair by default), technician and arrival window are optional; with a window, the first visit is scheduled at once and shows on the dispatch board; without one, the job stays as a draft with no visit yet.

• **Schedule visit** adds a visit to the same job from the console: a return is visit 2, 3 and so on, never a second job. A case has at most one job, and a second click on open answers that it already exists.
• The job's own arrival window and technician are only filled when they were empty: a second visit does not rewrite what was agreed for the first.
• **Visit overdue** appears when the window has started and the visit is still only scheduled, meaning nobody has left yet. The status change selector offers only the transitions the vertical's state machine accepts from the current status.
• When the field work is **completed**, **could not be completed** or was **canceled**, whoever owns the case is notified in their language with a link to the console, whether the change came from the console, the vertical's screen or the app. Dispatched, en route and waiting for a part stay visible in the box without ringing anyone.
• **The case status never changes on its own** when the field finishes. Confirming with the customer and resolving the case is a decision of whoever attends.
• **Unlink** removes the tie between case and job and nothing else: the job goes on living in the vertical, with its own trail. Canceling it is a transition of the vertical, done there.
• A reminder task on the visit date is optional and reuses the activities module; it appears in the case timeline and in the technician's task list, or the case owner's when there is no technician.
• With the vertical off, the box says so and points to **Settings · Verticals**, instead of showing a button that would fail. It offers the light path every workspace has, **Open a service order instead**, and shows that order and its appointments when one exists.

Where to set these up: **Settings → Quick texts** for the ready-made phrases, **Settings → Ticket email templates** for the transactional text, and **Settings → Skills** for who knows what and what each queue requires. The swarm, the follow-up and the work tabs need no setup: they are already in the console.

Open this article inside the system →