vaayaa Inclusive Education

Business and Management Consulting Case Studies

Professional5 Case StudiesUpdated Sep 2026

The five cases below come from advisory work with operating teams, service groups, and internal change programs. Each starts with a unit missing its own commitments, and each asks what a practitioner should do first. The organizations are fictional, but the patterns will be familiar to anyone who has sat through a steering meeting where nobody could say who owned a number. Every case uses the same lens: roles, service levels, workflow data, stakeholder expectations, and delivery targets. Read them in order, since later cases build on the habits from the first two.

1

Case Study 1

Claims desk misses targets as roles blur

Brightwater Benefits Desk, an internal claims support team of 46 people serving three regional insurance offices.

The situation

Brightwater's claims support desk answers benefit questions and reviews documents for three regional offices. Over two consecutive quarters, the desk closed about 71 percent of standard cases within three business days, against a committed level of 85 percent. Leadership read the gap as an effort problem, and the team lead, Marisol, responded by adding weekend shifts without changing staffing or handoff rules. Two senior agents believed they owned all escalations. The intake group assumed escalations went to a shared queue that nobody checked on Fridays. Nobody had written down who could approve an exception.

The challenge

Diagnose why the desk keeps missing its targets, then design an accountability plan that gives each role a clear remit and a visible measure. The sponsor, Gerald, the operations director, wanted movement within the month and ruled out any new reporting layer. The team had already sat through two process workshops, and the notes from both were still sitting in a shared folder with no owners attached.

Analysis

Teams grounded in Business and Management Consulting usually start by separating role confusion from capacity shortfalls, because the two look identical on a dashboard and need opposite fixes. Here the workflow data pointed to confusion first. The queue log covered 12,800 cases over the period, and about 19 percent were reassigned at least once before anyone made a first touch. Median time from intake to specialist was short, so the delay sat in the reassigned tail. Weekend coverage had not moved the closure rate, which suggested that more hours were being spent re-sorting the same cases. Service levels had been written as a single closure target, so no one was measured on the step where cases stalled.

Stakeholder expectations had drifted from the written target. The business units expected a first-contact answer, while the committee that set the 85 percent figure had never looked at intake. Delivery targets therefore pulled in two directions. The plan kept the closure target and split ownership along the workflow: intake owns triage within four business hours, specialists own resolution, and the team lead owns any exception with a decision due within one business day. A secondary measure tracks reassignments, with the goal of bringing them under 10 percent. The sponsor reviews all three measures together.

Handoff path where cases stalled
  1. 1Intake triageCases sorted by category within four business hours.
  2. 2Specialist assignmentOwner named in the log, with one reassignment allowed.
  3. 3Exception reviewTeam lead decides within one business day.
  4. 4Closure and sign-offClosed only after the named owner confirms the outcome.

Actions taken

  1. Publish a one-page role card for every desk member, covering cases owned, approvals granted, and the point where a case must move. Lead agents confirm the cards at the Monday huddle.
  2. Create a single escalation log with a named approver for each exception type. Any escalation without a logged owner after one business day goes to the team lead automatically.
  3. Reset the service level to three staged measures: triage within four business hours, closure within three days, and reassignments below 10 percent. Report all three on one screen, updated each morning.
  4. Run a four-week trial of the new handoff rules in one office, comparing reassignment and closure rates with the two offices on the old rules.

Results

Within the trial period, the pilot office's closure rate rose from the desk average of about 71 percent to 83 percent, and reassignments fell from 19 percent to 11 percent. The other two offices moved only slightly. Gerald accepted the three-measure view but asked that weekend shifts be judged against reassignment numbers before they were extended. Two of the four original complaints about unclear ownership were closed by quarter end. The team lead now spends less time chasing handoffs and more time on the exception log.

Questions for discussion

  • Which of the three measures would you have chosen as the sponsor's headline, and what would you expect it to hide?
  • How would you separate a capacity shortfall from a role confusion problem if the only data available were closure timestamps?
  • What would change in your plan if the team lead had resisted giving up the exception decisions?
2

Case Study 2

Shipyard account escalates over late component deliveries

Halden Marine Components, a supplier of hydraulic fittings with two plants and about 620 employees.

The situation

Halden supplies hydraulic fittings to a shipyard that builds coastal ferries. Over the previous two months, three shipments arrived late, and a fourth arrived short by 18 units. The account director, Teodor, had sent two written complaints and then requested an in-person review. The shipyard's procurement lead, Priya, told the team that she could no longer plan her own dock schedule around Halden's promised dates. Internally, the plants had been reporting on-time performance against a dispatch date, while the customer expected delivery against a receiving date that was usually two days later. Both figures were true, and neither side had said which one counted.

The challenge

Clarify what the shipyard actually needs, calm the immediate problem of the next two shipments, and rebuild trust with commitments the customer can check without calling us. Teodor wanted the review to focus on apology and recovery plans. The operations director, Anil, wanted to avoid agreeing to receiving-date terms that the plants could not meet. The review was set for the third week, and both men wanted a position they could defend.

Analysis

Start with the expectation gap, not the delivery gap. The plants were not lying about performance. They were measuring a different event. Workflow data from the dispatch system showed on-time departure at about 91 percent over the period, but receiving confirmations showed only 74 percent arriving on the date the shipyard had scheduled. The difference came from carrier pickup windows that Halden did not control and from a receiving dock that accepted deliveries only on certain weekday mornings. Expectations had been set during contract discussions that the operations team never saw. The first job was to get both measures on one page and agree which one would govern the commitment.

Roles had also blurred at the account level. Teodor held the relationship, Anil held the plant schedule, and the logistics planner, Sunil, held the carrier bookings, with no one owning the promise made to Priya. The service level in the contract was defined as a percentage of orders delivered within two days of the agreed date, which the plants had never been asked to hit. The target had to fit what the plants could influence. The team proposed a receiving-date commitment for the next two shipments, with a buffer of one day and a weekly joint call that ran for six weeks, after which the terms would be reviewed.

Recovery steps over six weeks
  1. Day oneCall with the procurement lead to confirm at-risk shipments.
  2. End of first weekShared delivery definition signed by both operations leads.
  3. Second weekNamed account owner begins approving every date change.
  4. Third weekShipyard asks for dock slot data, which joins the weekly scorecard.
  5. End of sixth weekReceiving-date terms reviewed against the scorecard results.

Actions taken

  1. Call Priya within one business day to confirm the two shipments at risk, the new receiving date for each, and the named Halden contact who will report status every morning.
  2. Agree on a single delivery definition in writing, a receiving date confirmed by the shipyard dock, and attach it to the account record so every team works from the same measure.
  3. Assign one accountable owner for the Priya relationship, with Teodor as the single point of contact and Anil approving any date change before it reaches the customer.
  4. Publish a weekly scorecard showing receiving-date performance, open shortages, and recovery actions, and send it to the shipyard every Monday for the next six weeks.

Results

The two at-risk shipments arrived inside the agreed receiving window, and the short shipment was made whole within the following week. Priya accepted the scorecard as the working reference and asked for it to include dock slot availability, which the team added. By the end of the six weeks, receiving-date performance on the account had reached 96 percent, and Teodor's in-person review became a planning session rather than a complaint meeting. The receiving-date terms have since moved into the renewal discussion, where the plants still have concerns about the one-day buffer.

Questions for discussion

  • If the shipyard had rejected the receiving-date definition outright, what evidence would you have offered to keep the dispatch measure in place?
  • Which person in this account should have owned the promise to Priya from the start, and what would have changed if they had?
  • How would you decide when a temporary buffer should be removed from a customer commitment?
3

Case Study 3

Artwork approval loop drives rework and late cartons

Corvane Packaging Works, a folding carton manufacturer with one plant and about 410 employees.

The situation

Corvane prints and folds cartons for food and personal care customers. Every new job goes through a proof cycle: prepress builds the artwork, the customer service desk sends it to the client, and the client returns changes by email. In the previous period, jobs needing a second proof reached the press floor late in about 40 percent of cases. Press scheduling held slots against the original proof date, so a late approval often meant a lost slot and a three-day wait. Rework was not recorded as rework. It appeared as revised file tickets, which the monthly figures counted as new orders.

The challenge

Map the handoffs in the proof workflow, find the root causes of delay and rework, and compare improvement options against the service levels the plant had promised. The plant manager, Olu, wanted a fix that needed no new software and no extra prepress headcount, since prepress was already at its limit. The customer service lead, Ingrid, wanted proofs out faster. The prepress lead wanted fewer changes after approval. Those goals were not the same, and the team had to decide which one governed.

Analysis

Mapping the handoffs took three weeks of shadowing and a review of 2,300 proof tickets from the period. Each ticket showed the time spent waiting in four states: awaiting prepress, awaiting customer service, awaiting client, and awaiting press scheduling. Waiting on the client accounted for roughly half of total cycle time, but the client wait was the one stage Corvane could influence least. The more useful finding was that 28 percent of proof cycles returned to prepress with changes that had already been approved in a previous round, because the approval was given by email to the customer service desk and never reached the artwork file.

Root causes sat in three places. First, no role owned the approval record, so approvals lived in inboxes. Second, the service level promised a proof within one business day of artwork receipt, but the measure stopped the clock when the proof was emailed, not when the client responded, so the team was graded on activity it could control and ignored the wait it could not. Third, press scheduling still reserved slots against the original proof date. The options compared were a shared approval log with a named owner, a locked artwork version after sign-off, and a rule letting press slots move without penalty. Only the first two reached the root causes.

Choosing the fix for proof approvals
Should approval records move onto the job ticket?
YesAdopt the shared recordApprovals become auditable and rework stops reaching the press floor.
NoKeep email approvalsRework continues and press slots keep slipping.
Pilot the locked file rule and the shared record together.

Actions taken

  1. Create a single approval record on the job ticket, with a required field for the approver's name, the version approved, and the date. Email approvals no longer count.
  2. Lock the artwork file at sign-off so that prepress works only from the approved version, and log any post-approval change as a separate ticket with its own cost.
  3. Change the service level to measure proof turnaround from the moment the client receives the file, and report client wait time separately so both teams see their own share.
  4. Pilot the press reservation rule on two job families for six weeks, then compare slot losses and on-time press starts with the prior period before deciding whether to extend it.

Results

Approval-related rework fell from 28 percent of cycles to 11 percent over the pilot window. Late proofs reaching the press dropped in the two pilot job families, and the plant recovered roughly four press slots a week that would otherwise have been lost. Olu accepted the locked-file rule without argument, which surprised prepress. The approval log did slow customer service slightly at first, because staff needed to record approvals they had previously just forwarded. That cost faded within the month. Ingrid now reports that clients ask fewer questions about status.

Questions for discussion

  • Which of the three improvement options would you have ranked first if the plant could fund only one, and what evidence would have changed your ranking?
  • How would you keep customer service staff from treating the approval log as overhead once the pilot ends?
  • What would a rework measure look like if revised files had never been logged as separate tickets?
4

Case Study 4

New time-entry policy meets resistance across field crews

Merrow Engineering Services, a field engineering firm of about 380 people serving utility clients.

The situation

Merrow adopted a new time-entry and project coding policy requiring every billable hour to be tagged to a work order before the Friday cutoff. Finance wanted cleaner revenue recognition, and the executive team had approved the policy after a long review. Field engineers, who often worked at client sites without reliable connectivity, found the mobile entry tool slow. Two of the four regional managers said the change had reached them without warning. In the first month, about 38 percent of timesheets were submitted after the cutoff, and roughly one in five contained codes that had to be corrected by hand.

The challenge

Identify the specific concerns behind the resistance, sequence adoption so the largest barriers come down first, and set a measure of uptake that the regional managers would accept. The program lead, Dasha, had three weeks before the next payroll cycle would depend on the new codes. The sponsor, Rafael, the chief financial officer, did not want the policy paused, and the field managers did not want blame for a system they had not helped choose.

Analysis

Concerns fell into three groups, and they needed different answers. Field engineers were worried about time and connectivity: entries that failed offline were lost, and the coding list ran to more than 200 items. Regional managers were worried about accountability: they would be the ones chasing late timesheets, but they had no authority over the coding structure and had not been consulted on it. Finance was worried about data quality, a legitimate concern, but its communications had focused on the deadline and said little about why the codes mattered. Each objection was partly right, and lumping them together was the program's first mistake.

The workflow data helped separate the problems. Most late timesheets came from crews with a failed offline sync that week, not from people who disagreed with the policy. A second group had entered time correctly but used the wrong code, usually because the list lacked their main type of work. Adoption therefore had to be sequenced: first fix the sync and add the missing codes, then ask for compliance, then tighten the cutoff. Uptake was measured by a weekly share of timesheets submitted on time and with valid codes, with a target that rose from 60 percent in the first month to 90 percent by the end of the quarter.

Adoption cycle repeated each reporting period
Adoption loop
1Listen
2Fix
3Measure
4Adjust
  1. Listen Collect site concerns through the weekly view and request form.
  2. Fix Remove the blocking issue before asking for compliance.
  3. Measure Track on-time submission and valid codes by site.
  4. Adjust Revise the code list or cutoff based on the evidence.

Actions taken

  1. Fix the offline sync for mobile entries and add a visible queue count so engineers can confirm that their hours have reached the system before leaving a site.
  2. Cut the coding list to the 40 codes that cover ninety percent of recorded work, and add a request form for any missing code, reviewed by finance within two business days.
  3. Give each regional manager a weekly site view of late and miscoded timesheets, and make them the first point of contact for their crews, with Dasha's team as backup.
  4. Hold a one-hour briefing for each site before the cutoff tightens, covering why the codes matter for billing, and record attendance and questions to shape the next round.

Results

The sync fix went live in the second week, and the queue count removed the most common complaint. On-time submission rose from 62 percent to 84 percent by the end of the quarter, and miscoded entries fell by about half. Rafael held the cutoff but agreed to a two-day grace period for sites with failed syncs. The payroll cycle ran on the new codes without a manual rebuild for the first time. Two managers still think the coding list is too long, and the request form data will settle the question at the next review.

Questions for discussion

  • Which of the three stakeholder groups would you have approached first, and what would you have done if that group's concern had been the least solvable?
  • How would you weigh a finance requirement for clean codes against a field requirement for fewer steps at the point of entry?
  • What would you expect to see in the request form data that the weekly on-time figure would hide?
5

Case Study 5

Choosing among three initiatives with partial data

Tarrant Ridge Credit Union, a regional member-owned lender with nine branches and about 260 staff.

The situation

Tarrant Ridge had budget for one major initiative in the coming year and two smaller ones. The candidates were a digital account opening flow, a commercial lending desk for small contractors, and the consolidation of two branches. Each had a champion on the executive team. The digital flow had encouraging usage data from a pilot in one branch, but thin evidence on whether it would attract new members or simply move existing ones online. The lending desk had demand signals from loan officers but no reliable pipeline data. Branch consolidation had cost estimates that finance had prepared in a hurry and had not tested against member travel patterns.

The challenge

Define criteria the executive team would accept, assess the risk in each option given what was actually known, and recommend a staged decision that did not wait for complete information. The chief executive, Nadia, wanted a recommendation within a month. The chief risk officer, Emeka, did not want commitments that could not be reversed. Two board members had already voiced interest in the lending desk, which made the criteria process politically delicate.

Analysis

The three cases were not built on the same evidence. The digital flow had 4,200 pilot applications, but the pilot branch sat in the most digitally active part of the membership, so it overstated likely uptake. The lending desk had no pipeline data, only loan officer estimates that counted prospects rather than qualified applicants. Consolidation had the most precise costs and the least reliable benefits. Nobody on the executive team owned the member service level in the branch under review, so the consolidation case had no baseline for what members would experience. The criteria had to carry these gaps openly rather than average them away.

The criteria the team settled on were expected member reach, reversibility, the cost of being wrong, and time to a first measurable result. Reversibility carried the most weight. The consolidation decision could not be undone without losing the branch's member relationships, while a digital flow could be paused and a lending desk could be shrunk within a quarter. The recommendation was staged. Fund a second digital pilot across two more branches with a target of new members. Commit a limited discovery budget to the lending desk, with pipeline tracking as the deliverable. Defer the consolidation decision until a member service baseline exists.

Options placed by reach and reversibility
Expected member reach
Branch consolidationBroad member impact that cannot be reversed without losing relationships.
Digital account flowWide reach and easy to pause if pilot data disappoints.
Full lending desk buildModest reach at first and hard to unwind once staff are hired.
Lending discovery budgetSmall, reversible, and tests demand before any hiring is committed.
Reversibility of commitment

Actions taken

  1. Write the criteria and their weights on one page before any option is scored, and get the executive team to sign off on the weights before they see the scores.
  2. Rate each option's risk by what would have to be true for it to fail, and name the evidence that would show it is failing by the first review date.
  3. Approve the second digital pilot with a funded target of new members, a 90-day review, and a stop rule agreed in advance by Emeka's risk function.
  4. Give the lending desk a six-month discovery budget tied to a tracked pipeline, and assign one owner to report qualified applicants, not prospects, each month.

Results

The executive team accepted the weights after one change: member retention moved up. The digital pilot reached its 90-day review with new-member growth in both added branches, and the stop rule was not triggered. The lending desk's first report counted 31 qualified applicants, enough to show a pipeline but not to size the desk. Consolidation stayed deferred while the service baseline was built. Nadia described the result as a decision the board could revisit, which was the point.

Questions for discussion

  • Which criterion would you have been most reluctant to weight heavily, and how would you test whether the weight was justified?
  • If the second digital pilot had shown strong migration but weak new-member growth, what would you have recommended?
  • How would you rebuild the consolidation analysis so that member experience is measured before any branch closure is scheduled?

Learning Resources

Professional 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.

Hourly Active: 48,824 Learners