Solution · Customer Service & Engagement
A request that is captured but not assigned is a complaint waiting to occur. This solution converts every incoming request into a managed case with a designated owner, a service clock and a defined path to closure.
One case, from intake to closure
Overview
Case management is effective when the process is embedded in the system, not held in the team's heads.
The case model is designed by X-Shift around your existing service catalogue: the request types handled, the information each requires, the approvals it passes through and the standard against which it is measured. That model is then embedded in the platform so that the lifecycle is enforced rather than remembered. Customers can be given a reliable status, managers obtain an actionable backlog and auditors obtain a defensible record.
The case model resides in X.Orbit. Where intake is automated, X.24 opens and populates the same case object rather than operating a separate queue. Both platforms are owned by X-Shift, so a new case type and its supporting automation are delivered together. This is most significant when a regulator amends a complaint category and intake, SLA and reporting must all change in the same week.
Core capabilities
01
02
03
The hub
Customer Service & Case Management
Connects the three stages: at intake, through the lifecycle, and control and evidence.
In practice
A regulated complaint is received by email at 4 pm on a Thursday. Under the previous arrangement, it remained unopened in a shared mailbox until Sunday morning, by which time the regulatory clock had been running for almost three days.
The email is classified on receipt and opened as a complaint case with its regulatory category already assigned.
The SLA clock starts from the email timestamp, not from the moment it is noticed by a person.
Ageing and breach risk are surfaced on the team's queue before the deadline, rather than in the following month's report.
That sequence is X.Orbit applying your own complaint model. It does not alter regulatory requirements, and it cannot remedy a breach if the case remains unworked.
The challenge
This section is intended as a qualification rather than an argument. Service teams rarely fail through a lack of commitment; they fail because the request resides in an inbox, ownership is implied rather than assigned, and the SLA is discovered only after it has been missed. If none of the left-hand column is familiar, this is not the right programme for your organisation.
Outcomes
What this changes
The change is not that staff work harder, but that the operation ceases to lose work between handovers.
Every request is assigned an owner and a due date from the moment of receipt
SLA breaches become preventable rather than merely reportable
Complaint management consistently meets regulatory requirements
Backlog and ageing become transparent and manageable
Recurring causes are identified and can be eliminated at source
Service status can be provided to a customer without prior internal investigation
Use cases
Each of these is a request type that already exists within the organisation without a designated owner, a service clock or an agreed definition of closure.
A beneficiary submits the same request at two regional offices of the same ministry. Each office processes it independently until one rejects what the other has approved.
One case is visible to both offices, and the duplicate is merged before two conflicting decisions reach the beneficiary.
Commonly applied in Government and across other sectors
A refund request is passed from the branch to operations and then to the card team. Each handover takes place by email, so no one can confirm who currently holds it.
Each handover reassigns a named owner in X.Orbit, and ageing is visible to the manager before the service standard is breached.
Commonly applied in Banking and across other sectors
A patient complaint about a discharge is addressed verbally by the ward and is not recorded. It resurfaces six weeks later, when the family asks what action was taken.
The complaint becomes a case with a classification, an owner and a recorded closure that the hospital can present to the family.
Commonly applied in Healthcare and across other sectors
The approval step has a designated owner and a timer, and escalates by rule rather than awaiting a follow-up call.
UtilitiesEvery enquiry becomes a tracked case with a due date, so the backlog remains visible while the admissions window is still open.
EducationLinked cases expose the repeat pattern, and the underlying cause is referred to engineering rather than closed again at the service desk.
TelecommunicationsThese are illustrative applications of the case model, not client work. The case types prioritised first usually depend on where regulatory time pressure is greatest.
Common questions
This depends on how well defined your service catalogue already is. Where request types, required fields and approval paths are documented, the first wave progresses rapidly; where they are held informally, the design work constitutes the programme and the configuration is the simpler element. Most organisations find their catalogue less settled than anticipated.
A decision-maker authorised to determine what constitutes a case type and what closure means, access to the systems from which the case must read data, and a representative from compliance where regulated complaints are in scope. Defining SLAs by case type will typically surface disagreements between departments that predate this project. These must be resolved in the design phase; otherwise they will be built into the platform unresolved.
Typically as a design and implementation engagement, with platform licensing quoted separately and an optional managed service thereafter. We recommend a phased scope (a first wave of case types, followed by extension), because a fixed price against an undefined catalogue is unreliable and both parties bear the cost later.
In some cases, yes. A CRM with configurable SLAs, rule-driven escalation and an auditable history can support this, and if yours does, the appropriate work is process design rather than replacement. The usual point of failure is complaint management with regulatory classification and evidenced closure, which most general CRM configurations cannot accommodate without significant customisation.
Next
Select your most contested request type (usually a complaint or a refund) and review it modelled with its intake fields, approvals, SLA and closure evidence. This is the fastest way to establish whether the disagreement concerns the platform or the process.
Applicable where a case type is disputed by all and owned by none.
Book a modelling sessionCustomer Service Process Design establishes the service catalogue, the ownership model and the standards against which a case is measured, so that the platform configuration records decisions rather than substituting for them.
Applicable where your request types have never been defined in a single place.
Customer Service Process DesignConfiguring an unagreed case model is the most common cause of programme failure; where this risk is present, we will state it and propose the design work first.
Technology that enables it
These are platforms built and supported by X-Shift. Where your estate already covers one of them, the engagement becomes integration and operating model work rather than a platform deployment, and we will state this clearly.
X-Orbit: Unified Customer Service & Engagement Platform
Contact us
Describe the problem, and we will advise which capability addresses it, including where no platform is yet required.
