The incident table has no idea who your customer is
Most of the mess I get called into starts with a sensible decision. A company already owns ITSM, the platform team knows how to build on it, and somebody in support asks whether external customers could raise incidents too. Six months later the incident table holds laptop tickets and contractual customer work side by side, and nobody can say which clock the account team is accountable for.
The structural problem sits in the record. An incident identifies the affected party through caller_id, which points at sys_user, which assumes an employee with a manager and a department. Customer service management splits that apart into an account and a contact, with entitlement hanging off the account. When a contact leaves the customer, the history stays with the account. When a caller leaves your company, the history walks out with the person.
Entitlement is the part people skip and then regret. Incident priority comes from impact and urgency, which your own support organisation sets and can quietly adjust when the queue is deep. A case SLA comes from what sales sold, and support does not get a vote. Those are two different promises, and the incident table only knows how to keep one of them.
The outage where two clocks disagreed
The version I watched happen involved a payments integration inside a B2B billing product. It went down at 04:12 on a Tuesday. Internal ops opened INC0294771 at P1. An intermediate certificate on a middleware node had expired, the on call engineer found it inside two hours, and service came back at 09:47. The incident closed with a restore time of five hours thirty five, which went into the monthly availability pack.
Meanwhile 47 customer tickets landed on the same table, through a portal bolted onto incident the year before. They came in at P2 and P3, because the intake form calculated priority from impact and urgency the way an employee request does. Nine of those accounts held a support contract with a two hour response and a four hour restore commitment for a severity one interruption. Nobody read those terms during the outage, because there was no entitlement record to read. Agents worked the queue in order and the last ticket closed at 15:20.
The account team found out three weeks later at a quarterly review, when a customer's head of operations pulled her own ticket log and asked why the service had taken eleven hours to come back. Our report said five thirty five. Both numbers were accurate. They measured different events, and nobody on our side had compared them, because an incident has one resolved_at and no concept of when the customer stopped being affected. The service credits were small money. The caution that settled over that account for a year was not.
A test for which side a work type belongs on
Start with who the affected party is in a contractual sense. If the person raising the issue is covered by your employment relationship, it is ITSM work. If they sit under an agreement with a renewal date and a procurement contact who can escalate to a lawyer, it is customer service work no matter how technical the fault turns out to be. Dull, and it settles most arguments in a minute.
Then ask whether resolution requires telling somebody outside the company something. An internal incident finishes when the thing is fixed. A customer work item finishes when the customer has been told, in a record you can produce during a contract review. Notification is part of the work. On incident, that communication lives in additional comments, a field rather than an obligation, and fields get skipped at 5am.
The third question is whether one underlying fault can hit several paying relationships at once. A single outage produces one internal incident and as many customer records as you have affected accounts. Forcing that into one table gives you either one incident with 47 watchers or 47 incidents chasing a single root cause, and neither reports honestly. Anyone who has argued about who owns a queue versus who owns the work knows the shape.
What actually justifies standing up CSM
I do not push CSM at every team with external users. If your outside parties are a few dozen vendors raising access requests, with no restore commitment in the paperwork, extend ITSM and keep the licence money. The governance around external access requests is well understood by now.
My threshold is three of four conditions holding. Restore or response commitments that differ from one customer to the next. More than one product version, where the answer depends on which build the customer runs. A support organisation funded from revenue rather than the IT budget. A need to show customers the state of their own work in a portal you would defend in a security review.
That last one is where extending ITSM leaks first. Incident ACLs were written for employees who are allowed to see most of what sits on the form. Every customer portal built on incident that I have reviewed exposed something: an assignment group name containing an outsourced vendor, a close_notes value naming the failing host, a parent CI reference telling a customer their traffic shares a cluster. Repairing that means rewriting ACLs on a table your whole IT organisation depends on, and the first false positive breaks an employee workflow at seven in the morning. A separate case table exists because that boundary is the deliverable, the same argument behind what a shared customer record has to carry.
How the handoff should actually run
When a customer case turns out to be an internal infrastructure fault, the shape is a parent and child relationship, never a transfer. The case stays open and keeps running against its entitlement. The incident carries the engineering work and closes on restoration. Major issue management was built for this, one major case linked to child cases across accounts and linked in turn to the incident. Without CSM you can wire the same relationship between tables, but most teams build the link and forget the clock.
Write the rule down: closing the incident never closes the case. Restoration and resolution are separate events with separate owners. The case closes once the customer has been told and that step has been logged. Put that in the workflow, because the runbook gets read on the first bad night and never again.
Assign the communication to a named person too. On the certificate outage, the bridge had an incident commander and nobody responsible for telling accounts anything, which is how a customer executive heard it from her own team instead of ours. Give that role standing authority to send an update before root cause is known, the same discipline behind the first thirty minutes of a platform incident. Subscribe the account team to the major case, and hold the notification step to the formality you already give a catalog item as an operating contract.
Pull the two numbers before your next service review
Take the three worst customer affecting outages from last quarter. Pull the internal resolution duration and the timestamp on the last customer ticket closed for the same event. If those numbers sit more than an hour apart and no report shows the second one, you are running customer work on a model that cannot measure it.
Then put one question to the next service review: which record does the account team read. If the answer is the incident, they are quoting your recovery time to a customer who started counting from a different moment and stopped at another. Fix the record before anybody argues about the SLA.
