Service Cloud

The Service module helps your support team receive customer issues, prioritise them, resolve them inside SLA, and escalate when things go wrong. Every case is tied back to the account and contact, so you always see the full customer history while you're solving the problem.

What's included

A typical case life

New ──► In Progress ──► Waiting on Customer ──► Resolved ──► Closed
                  ╲                          ╱
                   ╲ Escalated ────────────╱

1. Case is created (via email, web form, phone log or the AI assistant triaging an inbound message).
2. Priority is assigned — Low, Medium, High or Critical. Critical alerts the case owner immediately, not a support manager: the alert's recipient list is {caseRecord.owner_id} alone.
3. SLA target is calculated — every case gets a deadline based on priority.
4. Agent works the case, moving status as they go.
5. If it's Critical (or its SLA due date passes), the escalation process flags the case as Escalated, hands it to the least-loaded Service Manager, and alerts the agent it came from. The hand-off is to a flat position pool, not up a reporting line, and with nobody holding that position the case simply keeps its owner. No escalation condition reads the account, so a Customer's case gets no branch of its own.
6. Resolution is recorded, the resolution time is auto-stamped, and the case is closed.

What the system does for you

• Auto-prioritise with the Case Triage skill (the AI assistant reads the case and recommends a priority).
• Auto-escalate Critical cases — the flow flags them Escalated and alerts the agent who had them, and the case moves to the service manager with the fewest open cases (or stays put, if nobody holds that position). A High case is never escalated automatically, whatever the account is: raising one is the manual Escalate Case button.
• Notify on critical — inbox message + email to the case owner whenever a case is set to Critical. That is the Case Escalation flow's notify node, whose recipient list is {caseRecord.owner_id} alone; there is no support_manager@example.com recipient anywhere in this app.
• Notify on escalation — no email goes to an escalation team: escalation_team@example.com exists nowhere in this app. What the Escalated status fires is the case_status_side_effects hook, which opens an Urgent follow-up task due tomorrow for the account owner.
• Stamp resolution time automatically when a case is closed.
• Flag SLA breaches once the SLA target passes — the case is marked SLA Violated, escalated, and its owner alerted by inbox + email. No red banner: this app has no banner mechanism.
• Block bad closes — you can't mark a case Closed without a resolution written.

Service AI skills

The service skills are built into every case. Ask the assistant:

• "Triage this case" — assigns a priority based on subject, description and customer tier.
• "Suggest a resolution" — two skills, not one. Customer 360° reads the published knowledge articles (crm_knowledge_article is an ordinary object it queries), and Email Drafting writes the customer reply. Case Triage does neither: it has no query tool, and no drafting step.
• "Summarise this customer" — Customer 360 view including past cases and open opportunities.

Standard dashboards & reports

• Service Overview (the dashboard's own title is Customer Service) — the KPIs Open Cases, Critical Cases, Avg Resolution Time and SLA Violations; the charts Cases by Status, Cases by Priority and Cases by Origin; Daily Case Volume; an SLA Compliance gauge; an Open Cases by Priority table; and the knowledge-deflection row — a KB Deflection Rate tile with its two halves, Resolved by KB and Closed Cases, printed beside it so the percentage can be checked rather than trusted, plus a Top Resolving Articles table ranking articles by the closed cases they resolved. What it does not carry is a top agents tile or an oldest open cases tile, and neither is merely a widget nobody has built yet: case_metrics, the dataset behind every service widget, declares no owner dimension, so nothing in analytics can rank agents — the Cases page says the same — and a dashboard table aggregates its dataset instead of listing records, so the oldest individual cases cannot be shown there either.
• Cases Opened by Priority × Day — daily inflow, as a matrix of priority in the rows against day in the columns, in that order.
• Cases by Status and Priority — current snapshot: case count and average resolution time, by status and priority.
• SLA Performance Report — case count, SLA Violation Rate and average resolution time, by priority, over closed cases only. It does not report a compliance percentage: that is the service dashboard's SLA Compliance gauge, which plots sla_compliance_rate from the same dataset. See SLA & Escalation.

See Analytics › Dashboards and Reports.

Where to find things

In the HotCRM app, the Service group contains three items:

• Cases — the case list.
• Knowledge — the knowledge articles the Copilot reads from (crm_knowledge_article).
• Service Overview — the service dashboard. That is its sidebar label; no sidebar item is called Service Dashboard.

Two names people look for under Service are not there:

• Tasks — crm_task reaches the sidebar as My Tasks and All Tasks, both under the My Work group, not under Service.
• Service Board — nothing in this app carries that name. The kanban is the view case_workflow, labelled Service Workflow, and it is not a sidebar item at all: you reach it from the Workflow tab in the case list's view switcher.

Start here

• Cases — the core ticket record.
• SLA & Escalation — how priorities drive deadlines and escalation.
• Knowledge Base — what the AI Copilot reads from.