vaayaa Inclusive Education

Executive Assistant Services Case Studies

Professional5 Case StudiesUpdated Sep 2026

Executive assistant work sits between a senior leader's calendar and the operating machinery of an organization. When it goes well, nobody notices. When a meeting slips or a board packet arrives late, the assistant gets the call. The five cases below follow one assistant pool and the teams around it through problems that look different on the surface: missed targets, an angry stakeholder, a workflow that loops back on itself, a policy nobody asked for, and initiatives chosen on thin evidence. Each case applies the same lenses: roles, service levels, workflow data, stakeholder expectations, and delivery targets.

1

Case Study 1

Missed targets in a shared executive support pool

Ostrander Vale Advisory, a regional advisory firm with 180 staff across three offices and a shared executive support pool of eleven assistants

The situation

Ostrander Vale's executive support pool handles calendars, travel, board materials, and expense submissions for nineteen partners. Eleven assistants were organized into two informal groups. One group took requests from the managing partner's office and the other took everyone else's. Nobody had written down which group owned travel changes, which owned room bookings, or who could say no to a last-minute request. By the end of the second quarter, the pool had missed its target of confirming partner calendars within one business day on roughly a third of requests, and the partners had started copying the managing partner on complaints.

The challenge

Desmond, the managing partner, wanted the pool to hit its service target without adding headcount, which was frozen. Lucia, the pool coordinator, believed the misses came from volume spikes around board cycles rather than from effort. Both views had some basis, and neither rested on data. The pool logged requests in a shared spreadsheet that recorded submission time but not completion time, so nobody could say where the delay sat.

Analysis

The first problem was ownership. Two groups held overlapping authority, and neither had a written boundary for travel changes, room bookings, or refusals. When a request bounced between assistants, it aged without anyone noticing, and the shared log could not show that because it recorded submission time but not handoffs. Lucia's volume explanation was partly right, since requests roughly tripled in the week before board meetings. Yet when we filtered out those weeks, the miss rate remained near one request in five. Volume explained part of the gap. Unclear ownership explained most of the rest.

Expectations were the second layer. Partners read a one-day confirmation as a final calendar, while the pool counted a holding reply as confirmation. The metric looked like a failure when much of the work was done. Teams grounded in Executive Assistant Services tend to separate the question of who decides from the question of who does the work, and this pool needed both answers in writing. The delivery target itself was also too blunt. It treated a simple room change and a multi-leg international itinerary as the same kind of request, which guaranteed misses on the complex ones.

Where requests lost time before confirmation
Unclear ownership8/10
Overlapping groups with no written boundary; requests bounced between assistants unnoticed.
Holding replies counted6/10
Pool treated holding replies as confirmation, so partners saw misses that were not misses.
Blunt delivery target5/10
One target applied to simple changes and complex itineraries alike.
Board-cycle volume4/10
Real spikes, but filtering them out still left about one miss in five.
Skill gaps2/10
Little evidence that individual assistants lacked capability.

Scores set by the review team in this scenario, 10 = highest priority.

Actions taken

  1. Write a one-page ownership map that assigns each request type to a named assistant and a named backup, and get Desmond to sign it before anything else changes.
  2. Add a completion timestamp and a handoff column to the shared log, then review the aging report with Lucia every Monday for the next six weeks.
  3. Split the delivery target into three tiers by request complexity, with simple changes held to one business day and multi-leg itineraries given a stated lead time agreed with each partner.
  4. Define confirmation in writing as a final calendar entry, not a holding reply, and send partners a short note explaining the change and the new tiers before the next board cycle.

Results

Within two cycles the aging report showed that most requests moved to a named owner on the same day they arrived. The miss rate on simple changes fell below one in ten, and the complex itinerary tier was met on most requests once partners had agreed lead times. Lucia kept the Monday review, but it shrank to fifteen minutes. Desmond said the ownership map was the first document of its kind the pool had ever produced, and he asked for the same approach in two other groups. Complaints copied to the managing partner dropped to almost none.

Questions for discussion

  • Which handoff in your own team would you instrument first, and what would you expect the timestamps to show?
  • How would you decide whether a holding reply counts as confirmation when partners and staff disagree about it?
  • If the managing partner refused to sign an ownership map, what evidence would you bring to change his mind?
2

Case Study 2

A board chair escalates over late packet delivery

Pelham Crest Holdings, a privately held group of four manufacturing subsidiaries with a small corporate office and a shared executive services desk

The situation

Pelham Crest's executive services desk prepares board packets for four subsidiary boards and the group audit committee. The standard is delivery five business days before each meeting, with final numbers locked two days earlier. Over the last two cycles, packets for the audit committee went out late. The first arrived one business day late, and the second reached members about three hours before the call. Rafael, the audit committee chair, wrote to the chief executive and copied the general counsel, describing the process as careless with information that members needed to read properly.

The challenge

Imani, who leads the executive services desk, saw the late packets as a symptom of slow finance inputs, which arrived from four subsidiaries on different schedules. Rafael saw a desk that had stopped being reliable. The chief executive wanted the matter closed before the next committee meeting, about four weeks out. Nobody had agreed in writing what on time meant for the committee, and the desk had been working from the group standard rather than the committee's own preferences.

Analysis

The service level was clear on paper and loose in practice. The group standard set five business days, but the committee chair had asked, informally and earlier, for a full week, with a shorter confirmation window for changes. Nobody had recorded that request. The workflow data made the problem concrete. Of the input files due from the subsidiaries, two of four arrived late in each cycle, and the late ones always came from the same subsidiary, whose controller had changed roles. The desk had been absorbing those delays by compressing its own review time, which is why the packets were late and also why they contained errors.

Rafael's complaint had two parts that needed separate answers. The first was about timing, which the data supported. The second was about trust, the sense that the desk no longer checked its own work. Trust is rebuilt through specifics, so the response had to name a delivery commitment the committee could hold the desk to. We proposed a draft packet seven business days out, reviewed by Rafael's office, with the final version locked three days before each meeting. A short dispatch log, recording send time, review time, and any corrections after release, would show whether the commitment held.

Restoring confidence on committee packets
  1. 1Acknowledge and clarifyConfirm the committee's real preferences in writing with the chair.
  2. 2Fix the input chainAgree a submission calendar with the subsidiary and a named backup contact.
  3. 3Commit to datesSeven business days for the draft, three for the locked final version.
  4. 4Publish the dispatch logShare send time, review time, and corrections with the committee each cycle.
  5. 5Review the evidenceJudge the commitment on two full cycles before changing the standard again.

Actions taken

  1. Call Rafael within the day to acknowledge the two late packets, confirm the committee's actual preferences in writing, and ask which parts of the packet matter most to his members.
  2. Ask the controller's replacement to agree a fixed submission calendar with the subsidiary, with a named backup contact, and escalate any missed input to the CFO before the desk starts its review.
  3. Put the seven-day committee standard and the three-day final lock into the desk's runbook, and have Imani walk the committee secretary through both before the next cycle begins.
  4. Start the dispatch log on the first day of the next cycle and send Rafael a one-page summary of timing and corrections at the close of each meeting cycle, whatever the result.

Results

Rafael accepted the seven-day standard in a short reply, though he asked for the dispatch log to be shared with the full committee, which the desk agreed to. The next packet went out six business days before the meeting, and the final version locked on schedule. The subsidiary's new controller confirmed a submission calendar, and the one late input in the following cycle was flagged to the CFO before review began rather than discovered during it. Two corrections were issued after dispatch in the first cycle and none in the second. Rafael's office still asked for a call before each packet went out, which the desk treated as renewed attention rather than doubt.

Questions for discussion

  • What would you say on the first call with the chair if you did not yet know whether the late inputs were the root cause?
  • How should a commitment be phrased so that someone outside the desk can check it without asking anyone?
  • When is a dispatch log more likely to reassure a stakeholder than a formal apology, and when is it less likely to?
3

Case Study 3

A recurring expense reconciliation loop

Thornbury Lake Engineering, a firm of 260 employees that designs municipal water systems, with an internal assistant team of six supporting its operations group

The situation

Thornbury Lake's operations group sends roughly forty field engineers on travel each month. Each trip generates receipts, a mileage log, a pre-approval form, and a reimbursement claim. The assistant team of six reconciles these before claims go to finance. In the most recent full cycle, about one claim in four came back from finance for correction, and the average claim took nine business days from submission to payment, against a target of five. The assistants described the work as chasing the same documents twice. Nobody had mapped the full path, so each person blamed the step before theirs.

The challenge

Lucas, who manages the assistant team, needed a process that cut rework without adding a seventh person. Ayodele, the finance controller, wanted receipts complete before a claim reached her queue and was not willing to accept partial claims. Both wanted fewer returns, but they disagreed about where checking should happen. Improvement options were piling up: a new intake form, a tighter pre-approval rule, a receipt scanning tool, or moving the assistants' review earlier in the cycle.

Analysis

Mapping the handoffs showed the loop. The claim left the engineer, went to an assistant for reconciliation, went to finance for approval, and came back to the assistant when finance found a missing receipt or a mileage mismatch. Each return added about two business days, because the claim waited in a queue that nobody watched for returns. The workflow data was enough to show the pattern without a deeper study. Returns clustered on claims that included international legs and multi-day stays, which had the most receipt types. Those trips were also the ones where the engineer's pre-approval form was least likely to match the final itinerary.

Ayodele's expectation that claims arrive complete is reasonable, and it points the fix toward the front of the process. Lucas's team had been measured against a five-day target that assumed no returns at all, so the target itself was part of the problem. We compared four options against four criteria: build cost, speed, effect on returns, and effect on engineers. A new intake form was cheap but depended on engineers filling it in correctly. A tighter pre-approval rule would slow travel. A scanning tool helped with receipts but not mismatches. Moving the assistants' review ahead of submission addressed mismatches at the source and cost only a change in sequence.

How one claim moved through the loop
  1. Day zeroEngineer submits receipts, mileage log, and pre-approval form together.
  2. Day twoAssistant reconciles claim; mismatches discovered only after itinerary review.
  3. Day fiveFinance finds a missing receipt and returns the claim to the queue.
  4. Day sevenAssistant re-collects documents, often from engineers already in the field.
  5. Day nineClaim finally approved and paid, roughly four days over the target.

Actions taken

  1. Redraw the claim path as one map with named owners at each handoff, and mark every point where a claim can return, with the expected wait at each.
  2. Move the assistants' mismatch check ahead of submission, so the engineer's itinerary is compared against the pre-approval form before the claim enters finance's queue.
  3. Add a required itinerary field to the pre-approval form, and ask Ayodele to accept a claim only when receipts match that itinerary, with any exception logged by name.
  4. Restate the target as a tiered standard, five days for single-leg trips and eight for international legs, and review it against the returns data after two full cycles.

Results

The mismatch check moved ahead of submission early in the trial, and returns on single-leg trips fell noticeably within two cycles. International claims improved more slowly, because some itineraries changed after pre-approval for reasons outside the team's control. Average time to payment dropped from nine business days to six over the trial period, and the tiered standard was met on most claims. Ayodele accepted the new sequence but asked for an exception log, which the team had already planned. Lucas kept the intake form because it cost almost nothing and gave engineers a clear place to record changes.

Questions for discussion

  • Where in your own team's recurring workflow would a claim or request most likely loop back, and how would you find out?
  • Which improvement option carries the most risk of moving the problem somewhere else rather than solving it?
  • How would you weigh a tighter upstream rule against the friction it adds for the people who must comply with it?
4

Case Study 4

Moving executive calendars into one shared system

Corran Field Logistics, a freight brokerage with 430 staff and an executive office of nine people

The situation

Corran Field's leadership team decided that all executive meetings, including those booked through personal assistants, would live in one shared scheduling system from the start of the next quarter. Until then, four executives kept their calendars in personal tools, and assistants held shadow copies in spreadsheets. The policy also asked assistants to decline any invitation that had not come through the system, a rule that had not been discussed with the executives who would receive those declines. Adoption was measured as the share of meetings created in the system, with a target of ninety percent by the end of the second month.

The challenge

Vera, who runs the executive office, supported the move but worried that the decline rule would make assistants look obstructive. Kwame, the chief operating officer and the most frequent user of personal tools, said his calendar was too complex for a shared template and that he would not give up his own workflow. Two assistants had said privately that they would keep their spreadsheets as a backup. The rollout needed to win over the people with the most to lose, without letting exceptions swallow the policy.

Analysis

Resistance was not one thing. Kwame's objection was about fit: his meetings involved rolling holds, recurring site visits, and short-notice changes that the template could not represent. The assistants' objection was about role. The decline rule put them in the position of enforcing a policy they had not written, against the people they served. Vera's concern sat between the two. The early adoption data was useful. Meetings created in the system rose for executives who had assistants on the team, but stayed flat for Kwame, whose bookings came mostly from his chief of staff working in a separate tool. The team had been counting the wrong population.

The sequence of adoption mattered more than the announcement. A rule that starts with the most resistant user invites a failed test, so the team began with the executives whose calendars were already simple, then built a recurring-hold pattern for Kwame's office before asking for full compliance. The decline rule was softened from an automatic refusal to a prompt that routed the invitation back to the organizer with the booking link. The ninety percent target stayed, but it was split by executive so that one exception did not hide an overall gain. A four-hour change window for in-system meetings gave assistants a defined answer to offer.

Whether to make the calendar rule mandatory
Has the executive reached the adoption target?
YesMove to mandatory ruleApply the decline rule to that executive's meetings and remove the prompt fallback.
NoKeep prompt-only approachKeep the prompt, review gaps with the executive and assistant, and recheck at the next cycle.
Mandatory use is set only where the data supports it

Actions taken

  1. Hold one working session per executive with their assistant present, and record each recurring pattern the template cannot represent so the team can fix the gaps before the policy becomes mandatory.
  2. Publish a one-page note that explains the decline rule in plain terms, including the prompt wording and who to call when a request genuinely cannot wait.
  3. Run the first two weeks with a daily check of meetings created outside the system, sorted by executive, and send each assistant only their own gaps rather than a team total.
  4. Review adoption by executive at the end of the second month, and move to a mandatory rule for anyone above the target, keeping the prompt-only approach for those still below it.

Results

Adoption reached the target for three of the four executives by the end of the second month. The fourth, Kwame, sat at about seventy percent after his office adopted the recurring-hold pattern, so he stayed on the prompt-only approach. Assistants reported fewer confrontations over declines, because the prompt sent the request back to the organizer rather than to them. Two of the gaps found in the working sessions were fixed in the template, and one remained as a documented exception. The spreadsheets were retired in the third week of the second month, not before. Vera said the decline rule was the part people had argued about most and used least, which she counted as a success.

Questions for discussion

  • Which resistant user in your office would you start with, and what would make that choice fair to the others?
  • How do you separate a real workflow gap from a preference when a senior leader says the tool cannot work for them?
  • What would change your decision to move from prompt-only use to a mandatory rule before the target date?
5

Case Study 5

Choosing among three initiatives with thin evidence

Halvorsen Pike Legal, a mid-sized litigation firm with 320 staff and a shared executive services group of fourteen

The situation

Halvorsen Pike's executive services group was asked to pick one of three initiatives for the coming planning cycle. The options were a shared intake portal for meeting and travel requests, an outsourced travel desk to handle international bookings, and a structured training plan for assistants moving into practice support roles. Budget covered one initiative fully or two partially. The group had internal request counts and some satisfaction survey results, but no reliable estimate of what a portal would save. Nobody could say yet whether the partners would use a portal at all, and the outsourcing vendors' quotes were not comparable to each other.

The challenge

Marisol, the managing partner for operations, wanted a decision the partnership could defend, not one that merely felt right to the group. Tobias, who leads the assistant team, argued for the training plan because retention had been the group's largest hidden cost. Kofi, the finance director, wanted the portal tested before any money went into it. Each argument was reasonable, and each depended on a figure nobody had yet checked.

Analysis

The first task was to agree on criteria before scoring anything. The group settled on four: expected effect on service levels, reversibility of the spend, dependence on data the team did not yet have, and effect on delivery targets for partners. Weighting these mattered as much as the scores. Workflow data showed that roughly a third of requests arrived outside any tracked channel, which made the portal's benefit uncertain in exactly the place Kofi wanted proof. Retention was real but hard to attribute. Tobias had turnover figures, yet the reasons recorded in exit notes were mixed, and training would not address every cause.

Risk was uneven across the three options. The travel desk carried a contract that would be hard to unwind, and the vendors priced international work on different assumptions, so the quotes could not be compared until the group rebuilt them against one request sample. The portal was cheap to pilot and could be stopped within a cycle. Marisol's stated expectation was a decision the partnership could defend, which favored a staged path with explicit checkpoints. The recommendation was to pilot the portal against a defined sample, fund a first training cohort, and defer the travel desk until its quotes were comparable.

Staged decision loop under uncertainty
Staged choice
1Set criteria
2Test cheaply
3Equal footing
4Revisit with evidence
  1. Set criteria Agree weights in writing before any option is scored.
  2. Test cheaply Pilot the portal against a defined sample and log its source.
  3. Equal footing Rebuild vendor quotes on one request sample before totals are compared.
  4. Revisit with evidence Bring the next decision back once the cycle's measures are in.

Actions taken

  1. Agree the four criteria and their weights in writing with Marisol, Tobias, and Kofi before any option is scored, and record who signed off on each weight.
  2. Rebuild the travel desk quotes against one shared sample of forty recent international requests, so every vendor prices the same itineraries before the group compares totals.
  3. Run the portal pilot for one cycle on the untracked request channel, logging every request by source so the team can test whether the benefit holds where the data is weakest.
  4. Fund a first training cohort of six assistants, with a stop point set at the end of the cycle, and bring the travel desk decision back to the partnership with a comparable quote set.

Results

The portal pilot showed that about a third of requests in the untracked channel could be routed through the intake form. That was enough to justify a wider rollout but not enough to claim the savings Kofi had asked about. The first training cohort finished its work, and two members moved into support roles within the cycle. The travel desk comparison, once the sample was applied, narrowed the gap between the two lowest quotes and removed one vendor from contention. The partnership approved the portal rollout and the training cohort, and deferred the travel desk to the next planning cycle with a clear decision date.

Questions for discussion

  • Which criterion in this case would you weight most heavily, and who should have the right to change that weight later?
  • How much of the travel desk's uncertainty could a sample of forty requests actually resolve, and what would it leave open?
  • What would you need to see at the end of the first cycle before stopping the portal pilot early?

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