Service & Support manages the full lifecycle of customer contact across every intake channel. Omni-channel intake receives issues by email, web portal, chat, telephone, self-service form and machine-generated alert, and lands them as structured cases in the appropriate queue. Case and ticket management then drives each item through triage, categorisation, assignment, work and resolution, with the complete conversation and internal working notes held against the record.

On top of the helpdesk sit the three ITIL-aligned disciplines. Incident management restores service quickly and records every step taken. Problem management investigates the underlying cause of recurring or major incidents and maintains a library of known errors and workarounds. Change management governs any alteration to the service estate through a request-for-change, risk assessment and formal approval. Service level agreements and escalation run underneath all of it, timing every case against its committed response and resolution targets and escalating before a breach. Field service and field actions extend the same control to work that must happen on site, dispatching engineers, capturing what was done, and closing the loop back to the originating case.

At the centre of the module is the case: a single customer issue with an owner, a state, a priority, a channel of origin and a full history. Every other concept in the module either raises a case, governs how it must be handled, or records what was done to resolve it. Cases are grouped into service queues, each a stream of work for a particular team, product line or customer segment, so that routing and workload are explicit rather than accidental.

Governing every case is a service level agreement, the promise that defines how quickly a case of a given priority must be responded to and resolved. The agreement is not a static document but an active clock: it calculates targets against business calendars, pauses when a case waits on the customer, and drives escalation as deadlines approach. This is what makes a commitment measurable rather than aspirational.

Where the helpdesk handles individual contacts, the ITIL practices handle patterns. An incident is a single interruption to service. A problem is the underlying cause behind one or many incidents, and its investigation yields a known error: a documented fault with a proven workaround that agents apply immediately while the permanent remedy proceeds. A change is a controlled modification to the service estate, carrying its own risk assessment and chain of approvals so that nothing alters the environment without review. Finally, a field action represents work that leaves the desk: an assignment to an engineer, scheduled, dispatched and reported against the case it serves. These concepts relate as a natural chain, from the question asked to the fix delivered and the recurrence prevented.

The everyday workflow is the ticket journey. A contact arrives on any channel, is captured as a case, and is triaged into a queue with a category and priority that in turn select the governing service agreement. An agent picks up the case from the knowledge-driven desktop, works it with suggested articles and prior resolutions to hand, corresponds with the customer, and resolves or escalates it. Comments, both customer-facing and internal, build a complete audit of the exchange.

When an interruption is significant, the incident workflow takes over: severity is set, updates are posted at intervals appropriate to the impact, and stakeholders are kept informed until service is restored. Recurrence or major impact triggers the problem workflow, where root cause analysis produces a known error and, ultimately, a request for change. That change moves through the change workflow: a request-for-change is raised, assessed for risk, scheduled, and put before an approval board before implementation, then reviewed once complete. The field workflow dispatches on-site work, tracks assignment and travel, and captures completion, parts and time back against the case. Each workflow feeds the next, so a single reported fault can flow cleanly from incident to problem to change without leaving the module.

The module is built to the substance of the ITIL service management practices, not a nod to their vocabulary. Incident, problem and change are distinct disciplines with their own states, roles and records, and the boundaries between them are enforced rather than blurred. Change carries a genuine control regime: every request-for-change holds a categorisation of type and risk, a defined implementation and back-out plan, and a formal approval sequence that stands in for a change advisory board, so that emergency, standard and normal changes each follow the path their risk warrants.

Service level management is equally exact. Targets are evaluated against defined operating calendars and priority matrices, so a four-hour target means four business hours, correctly accounting for pauses while a case awaits customer input. Escalation is tiered and time-based, raising ownership and visibility as a deadline nears rather than after it passes. Every case, incident, problem, change and field action carries a durable, human-readable reference, and the full state history is retained, giving a complete and auditable trail of who did what and when. The knowledge base is treated as a first-class control surface: known errors and articles are surfaced in context, so that a proven workaround reaches the agent at the moment of need and resolution quality does not depend on individual memory.

Service & Support is deliberately not an island. It draws the customer, contact and entitlement context it needs from the CRM and Sales module, so that every case is anchored to a real account and its commercial relationship. Service agreements are honoured against the terms held in Contract Management, so the response a customer receives matches the service they bought. Where a case turns billable, whether for out-of-scope work, parts or an on-site visit, the costs flow to Finance for invoicing and revenue recognition rather than being tallied by hand.

Field actions coordinate with Inventory and Asset Management for the parts consumed and the equipment serviced, and with the workforce records in Human Resources for the engineers dispatched and the skills they hold. Changes that touch the service estate reconcile against the same asset records, so the configuration a change alters is the configuration the rest of the suite sees. Because every module shares one identity, permission and data fabric, a support agent, a finance controller and a field engineer all act on the same underlying record, and a resolution recorded once is visible everywhere it is relevant.

AI Workers are first-class users of the module, holding the same permissions and leaving the same audit trail as their human colleagues. Through conversational query, a manager asks in plain language which agreements are at risk this afternoon or how many incidents trace back to a single problem, and receives an answer drawn from live case data rather than a stale report. Workers execute actions directly: triaging and routing an incoming case, drafting a customer reply from the knowledge base, posting an incident update, or dispatching a field action to the nearest qualified engineer.

They watch continuously for anomaly and exception. A Worker flags a case drifting toward a service breach, a cluster of incidents that signals an emerging problem, or a change scheduled into a risky window, and raises it before it becomes a failure. On intake, Workers perform document and data extraction, reading an inbound email or attached report to populate category, priority and affected asset without manual keying. They offer decision support to agents and change managers, summarising a case history, proposing a probable root cause from prior known errors, or assessing the risk of a proposed change against past outcomes. A Worker can also stand as an approval or review node in a workflow: sitting on a change advisory sequence to approve low-risk standard changes within policy while escalating anything outside it to a human, so that routine throughput stays fast and genuine judgement calls still reach a person.