The Christmas Operating Model Test
What peak season reveals about how your organisation really works—and how Business Architecture helps you fix it.
It’s almost Christmas. The lights go up, the out-of-office messages multiply, and suddenly the organisation is asked to do something very simple on paper:
Deliver on promises.
Whether those promises are “gifts arrive on time”, “customers can get help quickly”, “claims get settled before year-end”, or “month-end closes cleanly despite half the team being on leave”, December has a habit of turning polite assumptions into hard facts.
In Business Architecture terms, Christmas is not just a season. It is an operating model stress test.
And like any stress test, it doesn’t create new problems. It reveals the ones you already had.
Why December is the most honest month of the year
Most organisations can look reasonably efficient in steady state. Demand is predictable, capacity is stable, and the exceptions feel manageable.
Then December arrives and three things happen at once:
- Demand spikes (volume goes up, but more importantly, variability goes up).
- Capacity dips (leave, sickness, year-end fatigue, supplier constraints).
- Tolerance for failure collapses (because the customer’s deadline is emotional, not operational).
That combination exposes the true operating model—not the one described in governance slides, but the one customers and colleagues actually experience.
If you want a quick diagnostic question, it’s this:
When things get busy, do we get better at doing the right work—or do we get louder at doing more work?
The four failure patterns Christmas reliably uncovers
1. The “value stream breaks at the handoffs” problem
In calm periods, handoffs are an inconvenience. In peak season, they become the bottleneck.
A customer journey might look linear (“order → fulfil → deliver”), but the operating reality is a chain of dependencies: Ops, Finance, Risk, Technology, suppliers, contact centres, logistics partners—each with their own priorities and constraints.
At Christmas, hand-offs fail in predictable ways:
- work queues build between teams
- ownership becomes unclear (“it’s with them”)
- exceptions bounce around as “not my process”
- customers feel like they are chasing the organisation rather than being served by it
Business Architecture move: Map the value stream end-to-end and mark every handoff with:
- the “definition of done”
- decision rights (who can approve/override)
- failure paths (what happens when it goes wrong)
- time expectations (not just SLA, but how long it actually sits idle)
You will often find that cycle time isn’t spent doing work; it’s spent waiting for work to be accepted.
2. The “exceptions run the business” problem
Peak periods don’t just increase volume; they increase exceptions:
- address changes
- stock issues
- payment errors
- identity/KYC queries
- complaints and refunds
- supplier delays
- policy edge cases
The uncomfortable truth: many organisations are optimised for the happy path and “hero their way through” the exceptions.
And heroics don’t scale.
Business Architecture move: Treat exceptions as first-class citizens in the operating model:
- quantify top exception types (frequency × effort × customer impact)
- redesign the flow so exceptions are routed with intent (not dumped into generic queues)
- simplify rules where possible and automate the predictable parts
- create clear escalation patterns so teams aren’t improvising under pressure
A useful framing is: “Design the operating model for the messy reality, not the tidy diagram.”
3. The “governance slows down exactly when you need speed” problem
In many organisations, decisions are cheapest when they are early, and most expensive when they are late. Christmas makes late decisions brutally expensive.
This is where governance often becomes a paradox:
- more risk, so more sign-offs
- more urgency, so more meetings
- less capacity, so decisions take longer
- more pressure, so decisions become less consistent
The result is predictable: people bypass governance, or escalate noisily, or make local decisions that create downstream cost.
Business Architecture move: Shift from governance as permission to governance as pace:
- establish a clear decision cadence (weekly is often sufficient, daily in peak)
- use a simple “options and consequences” format instead of long documents
- agree a small set of patterns that teams can reuse without re-approval
- define the “stop list” (what must not be done, even under pressure)
If you want one practical test: Can a frontline team make a safe decision in minutes without escalating to five committees?
4. The “metrics tell you what happened, not what will happen” problem
Many organisations measure outcomes when it’s too late to intervene:
- backlog size (after it’s already large)
- customer complaints (after trust is already damaged)
- SLA misses (after the clock has run out)
December demands leading indicators:
- queue ageing (how long work has been waiting, not just how much work exists)
- first-time-right rate (how often work avoids rework loops)
- contact drivers (why customers are calling, not just how many called)
- exception rate by type
- handoff time between teams
- “promises at risk” (orders/claims/cases likely to breach before they do)
Business Architecture move: Tie measures to the value stream, not to functions. The customer doesn’t care that “Team A hit their metric” if the end-to-end promise failed.
What “good” looks like in a Christmas-ready operating model
A Christmas-ready operating model isn’t one that never fails. It’s one that fails gracefully and recovers quickly, without depending on individual heroics.
It tends to have five characteristics:
- Clear ownership of end-to-end outcomes (not just local activities).
- Designed exception handling (triage, routing, and resolution paths are explicit).
- Fast, consistent decisions (patterns and decision rights are clear).
- Controls that protect without suffocating (risk managed through design, not endless approvals).
- Measures that predict problems early (leading indicators linked to intervention actions).
In other words: it is engineered for reality.
A light-hearted way to run the “Christmas Operating Model Test” in January
When the festivities are over and everyone has recovered, do a short retrospective that avoids blame and focuses on design.
Here’s a simple three-part test:
Part 1: Where did the promises bend?
Pick one or two promises that mattered most (delivery, response time, claims turnaround, month-end close, onboarding, refunds). Identify the moments the promise broke or nearly broke.
Part 2: What was the real constraint?
Was it:
- a handoff?
- a decision bottleneck?
- an exception overload?
- unclear ownership?
- lack of tooling/automation?
- supplier dependency?
- missing data?
Be disciplined: choose the constraint that governed throughput, not the most visible pain.
Part 3: What is the smallest architecture change with the biggest effect?
Not a multi-year transformation. A targeted move such as:
- redesigning a single handoff with explicit “definition of done”
- creating an exception triage lane with clear routing rules
- introducing a weekly decision clinic for peak-season issues
- standardising one reusable pattern so teams stop reinventing it
- adding two leading indicators that trigger action early
The goal is momentum: fix one structural weakness that will be exposed again next December.
The closing thought: Christmas is your free consultancy report
Peak season gives you something rare: a concentrated view of what truly drives (or damages) outcomes.
If you’re a Business Architect, it’s also your moment to shift the conversation from:
- “Who worked hardest?” to
- “What in our design forced people to work that hard?”
Because the best compliment an operating model can receive is not “we survived.” It’s: “We delivered calmly.”
And that is the kind of Christmas magic worth engineering.
Merry Christmas to all my readers. Please let your comments and suggestions coming.
