IT Service Management and Enterprise Operations Case Studies
Technical5 Case StudiesUpdated Sep 2026
Enterprise operations rarely fail in one place. They fail in the gaps between a ticket queue, a monitoring dashboard, a change calendar, and a finance team that wants a number by Friday. The five cases below follow fictional organizations that live in those gaps: a claims network, a retailer, a credit union, a freight booking platform, and a municipal water utility. Each began with a situation that looked manageable until someone asked a sharper question. The same evidence can support very different calls depending on what the business can tolerate and who absorbs the cost of waiting.
Case Study 1
Claims intake stalls after a Thursday release
Tallgrass Claims Network, a claims processor serving sixty regional clinics and two hospital systems
The situation
Tallgrass Claims Network processes roughly 4,000 claims a day for sixty regional clinics. On a Thursday evening it released a change to the adjudication service that tightened how diagnosis codes were validated. Within forty minutes, the intake queue climbed from about 1,200 messages to more than 9,000, and the share of submissions returning errors went from under one percent to nearly a third. Clinics started calling the help desk before any alert paged anyone. The on-call lead, Priya, a senior site reliability engineer, was the first to see the pattern in the error logs.
The challenge
The release had a second purpose. Compliance asked for the new validation rules before the end of the quarter, so reverting the whole package would reopen a gap an auditor had already flagged. Patching forward looked faster, but nobody yet knew which messages had been rejected, dropped, or stored in a partial state. The change freeze also meant any fix needed sign-off from two directors who were not reachable until morning.
Analysis
Teams grounded in IT Service Management and Enterprise Operations usually begin by separating what the business is trying to protect from what the dashboards happen to show. At Tallgrass the first objective was continuity of claim intake, because clinics had a contractual window to submit before the payment cycle closed. The second was data integrity, since a claim stored half processed is harder to recover than one that never arrived. The evidence was uneven. Queue depth and error rate were trustworthy, but the logs did not yet show whether rejected messages were retried, so the team treated that gap as the most urgent unknown rather than a detail to fill in later.
Stakeholder impact shaped the sequence more than the root cause did. Clinic billing staff were losing a few hours of submissions each day, which hurt but could be recovered. The bigger risk was a blind replay, which would leave partial records for the claims team to reconcile by hand. Operationally, a rollback meant draining in-flight messages for roughly forty minutes, while a forward patch needed a change approval nobody could grant overnight. The team paused intake for the worst clinics, preserved failing messages in a dead letter store, and shipped a narrow validation fix only after the replay logic was tested against a copy of the queue.
Actions taken
- Freeze further deployments and page the adjudication and intake owners together, so one incident lead holds the timeline and every change request is logged against it.
- Pause intake only for the clinics generating the worst error rates, and move their failing messages to a dead letter store with original timestamps intact.
- Test the replay logic against a copy of the queue, confirm idempotency on claim identifiers, and only then release the validation fix to a single intake node.
- Add an alert on rejected-message rate per clinic and a runbook entry that names who approves a rollback during a change freeze, so the next decision is faster.
Results
Intake was restored for all clinics within the same shift, and the dead letter store held 3,400 messages that were replayed in batches over the following two days. Reconciliation found 212 claims that had been partially written, all corrected by the claims team before the payment window closed. The validation fix went out after a second test pass and caused no further rejections. Clinics did not lose a submission window. The review that followed added a rejected-message alert and a named approver for emergency rollback, and the next release in the quarter passed through the same path without an escalation.
Questions for discussion
- Which evidence would have changed the rollback decision in the first hour, and who needed to be in the room to act on it?
- How should a team weigh an audit commitment against the risk of a partially applied change during an active incident?
- What belongs in an emergency runbook so that a change freeze does not force a slower decision than the incident requires?
Case Study 2
Conflicting sales totals before the budget review
Redfern Outdoor Supply, a retailer with 38 stores and a growing online channel
The situation
Redfern Outdoor Supply reports sales from three systems: the point of sale in its 38 stores, the online order platform, and a marketing attribution feed. Ahead of the annual budget review, the merchandising team's regional totals did not match the finance ledger. The gap was about 4.1 percent in one region and under one percent elsewhere. Two dashboards showed the same quarter with different returns treatment, and a third used a refund date instead of a sale date. Nobody could say which number was correct, and the review was set for the start of the next month.
The challenge
The analytics lead, Marcus, a data engineering manager, needed a reconciled figure within ten working days. The team had no shared definition of a completed sale across channels, and the store feed arrived late on some Mondays after a nightly batch. Changing a transformation in the shared warehouse would affect eleven downstream reports that finance used for covenant tracking. The question was not only which number was right, but how to fix the path that produced the disagreement without breaking reports people already trusted.
Analysis
A disputed figure is rarely a single bug. In practice the disagreement at Redfern had three sources, and the business objective decided which one to chase first. Finance needed a number it could defend to lenders, so the ledger was the anchor. Merchandising needed a view that showed sell-through by store, which pulled in returns differently. The available evidence was the lineage metadata, the row counts at each transformation step, and a sample of 600 disputed transactions that someone had exported by hand. That sample was the most useful artifact in the room because it showed the disagreement was about definitions and timing, not missing rows.
The constraints were practical. Changing the shared warehouse meant a change window that only opened twice a week, and eleven downstream reports depended on the current logic, so a quiet fix would have surprised people who relied on those figures. Stakeholder impact was asymmetric. Finance carried the reputational and lender risk, merchandising carried the buying decisions for the next season, and store managers would notice any change in their rankings before anyone explained it. The team therefore wrote down the agreed definition of a completed sale, versioned the transformation, and added a reconciliation check that compares channel totals to the ledger every morning before the dashboards refresh.
- Trace lineage Map each figure back to source tables and the transformation that touched it.
- Validate transforms Compare row counts and channel totals at each step against the agreed definition.
- Monitor reconciliation Check against the ledger each morning and alert past an agreed threshold.
- Review changes Version each transformation and review downstream effects before it reaches a shared report.
Actions taken
- Write the definition of a completed sale as a shared document, signed by finance and merchandising, before any query is changed.
- Trace each disputed quarter total through lineage metadata, starting from the 600 sampled transactions, and label every step where the logic diverged.
- Version the revised transformation and run old and new logic side by side for one full reporting cycle, comparing every downstream report.
- Add a morning reconciliation check with a named owner who can hold a dashboard refresh when channel totals drift past the agreed threshold.
Results
The merged definition moved the online figure by about 2.8 percent and the store figure by less than half a percent, which explained most of the gap. The remaining difference came from refund timing, and the team kept it as a labeled reconciling item rather than forcing agreement. The budget review went ahead with one set of numbers and a footnote that named both treatments. Afterward the morning check flagged two drift events, both traced to a late store feed, and neither reached a published report. Finance now asks for the reconciliation sheet before it asks for the dashboard.
Questions for discussion
- Which of the disputed definitions should have been settled before the warehouse was built, and who would have had authority to settle it?
- When a reconciling item stays on a report, how should the team decide whether it is a permanent difference or a defect waiting to be found?
- What evidence would convince the merchandising director that a changed number is more accurate rather than simply different?
Case Study 3
Suspicious logins point to a possible compromise
Lumen Vale Credit Union, a member-owned lender with 22,000 members and eleven branches
The situation
Lumen Vale's security operations team received an alert from the fraud model that a cluster of member logins came from a residential proxy range it had not seen before. Over roughly three hours, 47 accounts showed successful sign-ins followed by changes to contact details. Two of the accounts belonged to staff members with access to the core banking admin console. The on-call analyst, Tomas, escalated to the incident lead before any member had reported a loss. The credit union had 22,000 members across eleven branches, and a wrong call in either direction would cost something real.
The challenge
Dana, the security lead, had to decide how far to contain before the scope was known. Locking all 47 accounts would stop the activity but would also block members who were trying to pay bills that morning. Forcing a password reset on the staff accounts was clear, yet the two staff members were in the middle of a payroll run. Evidence was thin: the proxy ranges were shared with a legitimate mobile carrier, and the logs from the authentication provider arrived in batches.
Analysis
Member trust and regulatory duty pulled in the same direction on paper but not in practice. The credit union's first objective was to stop unauthorized money movement, and its second was to keep ordinary members able to reach their accounts. Authentication logs, the fraud model's scores, and the admin console audit trail were the three sources that could show what had happened, and each one rolled over on its own schedule. The team snapshotted the log stores and hashed the exports before anyone began filtering, so that a later review could show the evidence had not been reshaped by the people investigating it.
Containment was constrained by who depended on each service. Blocking the proxy range would have been fast, but it could also cut off members on a mobile carrier that used the same addresses, and the branch staff would field those calls. Forcing resets on staff accounts reached the right people but interrupted payroll processing, which had its own deadline and its own audience. The response plan the team followed was documented in advance, which mattered because the authority to disable accounts sat with a named officer rather than the analyst on shift. Each step was logged with a time, an owner, and the evidence that justified it.
Actions taken
- Snapshot the authentication, fraud scoring, and admin audit stores, hash each export, and record who accessed them and when, before any filtering begins.
- Reset credentials and revoke console sessions for the two staff accounts within minutes, then coordinate with payroll on a controlled restart.
- Apply a narrow block to the proxy addresses that matched the attack pattern, excluding the carrier ranges, and have branch staff use a scripted reply for affected members.
- Document each step with time, owner, and justifying evidence in the incident record, and file a notice with the regulator only after counsel and the officer confirm the facts.
Results
Of the 47 accounts, 36 showed no sign of compromise after full review and were restored without a reset. Eleven were confirmed compromised and locked, and the two staff accounts were reset within the first hour. The narrow proxy rule briefly caught 16 members on a carrier range before the exception was added, and branch staff logged nine calls from them. No funds left member accounts after the first containment step. The officer and counsel found no member data had been exported, so no regulator notice was needed, and the file closed with the full evidence set.
Questions for discussion
- How should a team decide when the evidence is strong enough to lock a population of accounts, knowing that the lockout itself harms people who were not involved?
- What would have to change in the escalation path for the on-call analyst to act on the two staff accounts without waiting for the officer?
- Which parts of the evidence preservation step would you document differently if counsel later asked for the chain of custody?
Case Study 4
Choosing a booking architecture as quote volume climbs
Quillon Transit Booking, a freight platform connecting shippers with 340 mid-size carriers
The situation
Quillon's booking platform lets shippers request rate quotes from carriers and confirm a load within minutes. Over the last several quarters quote volume roughly tripled, and the single regional database cluster began to show p95 latency above two seconds during the afternoon peak. The product team wanted sub-second quotes for shippers in three new regions. Finance had a monthly infrastructure ceiling that the current growth would breach within a quarter. The platform team, led by Oleg, a principal platform engineer, had four candidate designs on the table and a short window to choose one.
The challenge
Each design had a different answer to the same problem. Vertical scaling was cheap to build but had a hard ceiling and a long failover. Partitioning by region would meet latency targets but duplicated carrier rate tables and made security reviews harder. Anything that pushed quotes to a cache risked showing shippers stale rates, which carriers had contractually promised not to allow for more than a few minutes.
Analysis
The evidence pointed somewhere narrower than the proposals did. Load tests showed that most of the latency came from synchronous rate lookups across carrier tables, not from raw compute, which pointed toward caching or read paths. Cost data came from the cloud billing export, grouped by service, and it showed that the database tier accounted for well over half of spend. Business objectives were clear on one point: shippers in new regions needed quotes inside a second, and finance needed the monthly total to stay below its ceiling after the next two onboarding waves. Those constraints interact, so the team scored each option against all three.
Security and operations added constraints that do not show up in benchmark results. Partitioning by region meant carrier credentials and rate data would live in more places, and each copy would need the same access controls, retention rules, and audit coverage. Only five engineers could operate the database, so a new messaging tier had to justify its runbook cost. Stakeholder impact was uneven: carriers cared about rate accuracy and shippers cared about speed. The team chose a design that kept one authoritative rate store, added read replicas and a short-lived quote cache with per carrier expiry, and deferred regional partitioning until the cost ceiling forced the question.
Actions taken
- Load test each candidate against replayed afternoon peak traffic, measuring p95 latency for quotes separately from booking confirmations, since the two have different tolerance.
- Model monthly infrastructure cost for each design across the next two onboarding waves, including replica count, cache capacity, and cross-region transfer.
- Review each design with the security group for credential placement, audit coverage, and retention, and record the controls a regional copy would inherit.
- Ship the replica and cache change behind a feature flag to one region first, with a rollback path that restores direct lookups within minutes.
Results
The replica and cache design went live in one region first, and p95 quote latency fell from above two seconds to under 600 milliseconds at afternoon peak. Monthly infrastructure spend rose by about 9 percent, which kept the team below the ceiling for the next two onboarding waves. Two stale-rate complaints reached carrier support during the first week, both traced to a cache entry that outlived its carrier expiry, and the expiry was shortened. Regional partitioning stayed on the roadmap as a fallback, with a trigger tied to spend and replica lag rather than a fixed deadline.
Questions for discussion
- How much weight should a team give a single peak-hour load test when the traffic pattern for new regions has not yet been observed?
- When a cache shortens latency but introduces a staleness risk, who should own the decision about acceptable expiry for each carrier?
- What signals would justify moving from a shared rate store to regional partitioning, and who should be accountable for watching them?
Case Study 5
Automated billing dispute triage with bias risk
Marlow Creek Water Authority, a municipal utility serving about 180,000 residential and business accounts
The situation
Marlow Creek's customer operations group handles roughly 3,100 billing disputes each month, and median time to resolution sits near eleven days. A vendor offered a classification tool that reads each dispute, proposes a category, and approves credits below a set amount without a staff member reviewing them. The vendor's sales material promised a median of three days. During a pilot on a sample of 2,400 closed disputes, the tool matched staff decisions in most cases, but a closer look showed it sent disputes written in several non-English languages to manual review far more often, which added delay for exactly the customers the utility was trying to serve better.
The challenge
Ines, the customer operations manager, had a board commitment to shorten resolution times and a union agreement that required human review of any decision denying a credit. The pilot results were mixed enough that neither a full launch nor a clean rejection was defensible. The team also lacked a labeled set of past decisions broken out by language, so they could not yet say how large the disparity was or what caused it. Meanwhile the vendor offered a discount for signing before the end of the quarter.
Analysis
Start with what the metric is supposed to protect. The business objective was faster resolution without a rise in wrongful denials or uneven treatment, so a single accuracy figure would hide the problem. The team defined four measures before any rollout: median resolution time by language group, the rate of credits reversed on second review, the share of disputes routed to manual review by ZIP code band, and escalation rate after an automated decision. The evidence set was limited to the 2,400 sampled disputes, so the team treated the pilot as a way to find questions rather than as proof that the tool was safe.
Human oversight had to be designed into the workflow, not added as a policy line. The union agreement meant any denial needed a person to sign it, so the tool could recommend but not decide in that category. Staff reviewers were already stretched, and a queue filled with low-confidence cases would only move the backlog. Customers with limited English were most exposed, since they could not easily dispute an automated outcome. The team agreed a staged rollout: first, the tool would suggest categories only; then it could approve small credits in one region with a daily sample audit; expansion depended on metrics holding for a full billing cycle.
- 1Suggest categories onlyTool proposes categories and staff accept or correct them; no customer sees its output.
- 2Approve small creditsAutomatic approval in one region, below an agreed amount, with daily sampling.
- 3Check metrics each cycleExpand only when all four measures hold through a full billing cycle.
- 4Denials stay manualAny denial goes to a named reviewer, as the union agreement requires.
Actions taken
- Define four evaluation measures and their thresholds in writing before the next pilot, with the language group and ZIP code band recorded for every disputed decision.
- Build a labeled sample of past decisions split by language group, so the disparity in manual routing can be measured and its cause traced before any launch.
- Keep denials under named human review, and give the vendor a written scope that excludes automatic approval until the staged gate is passed.
- Decline the quarter-end discount in favor of a contract clause that lets the utility pause automatic approvals within one business day of a metric breach.
Results
The vendor agreed to the scope in the end, and the labeled sample showed that disputes in two language groups were routed to manual review at nearly twice the rate of English disputes. The team traced most of the gap to free text notes that the model read as weak evidence, and the vendor retrained the category model on a corrected set. The metric gate held in the first region for one full billing cycle, with median resolution down from eleven days to five. Denials stayed manual throughout, and the pause clause was not needed.
Questions for discussion
- Which of the four measures should carry the most weight when the tool is faster but slightly less even across customer groups?
- How much human review is enough for a low-value credit, and at what point does review become a formality that staff cannot actually perform?
- What should a utility require from a vendor about retraining and disclosure before a pilot result is allowed to support a purchase decision?
Learning Resources
Technical CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.