The Inherited Front Door: Auditing a Combined Service Model in the First Hundred Days

Most merger integration plans are written around functions, systems and cost. The service model arrives later, usually as a workstream labelled 'customer experience' with a delivery date somewhere after the synergies have been banked. By then, two contact routes are already live, two sets of service-level agreements are being quoted to the same customers, and two teams are interpreting the word 'resolved' in different ways.

The first hundred days are not the period in which the combined operating model is finished. They are the period in which its faults become visible and, if left unmanaged, become inherited. An audit in this window is less about producing a target blueprint than about establishing an evidence base for the decisions that follow.

Why the front door matters more than the org chart

Customers do not experience a merger as a change of ownership. They experience it as a phone number that now goes somewhere else, a portal that behaves differently, or a complaint that appears to restart when it crosses an internal boundary. The combined front door is therefore the first place where the deal becomes real, and the first place where inconsistent promises become a conduct risk rather than an integration inconvenience.

Three conditions tend to appear early. First, duplicated intake: two web forms, two telephony queues, two mailbox structures, each with its own triage rules. Second, conflicting clocks: one estate measures first response in working hours, the other around the clock, and neither has reconciled the difference. Third, inherited obligations: supplier contracts, outsourced tiers and legacy system support arrangements that were designed for a service model that no longer exists in isolation.

None of these is solved by a new operating model document. They are solved by a sequence of decisions, each with an owner and an evidence trail.

Days 1 to 20: Map the estate as customers meet it

The opening phase should produce a service estate register, not a target design. The register should record, for each customer-facing route, the channel, the entry point, the queue or triage logic, the published promise, the internal owner, the supplier dependency and the system of record. Where two routes appear to serve the same need, record both rather than resolving the duplication prematurely.

Two distinctions are worth enforcing from the start. The first is between brand and route: a customer may see one brand while being routed through two separate operational estates. The second is between a published promise and an operational target. The published promise is a contractual or regulatory commitment; the operational target is an internal aspiration. Integration plans frequently conflate them, and the conflation is where customer harm begins.

A short evidence pack should accompany the register: sample complaint journeys, call recordings where permissible, queue abandonment data, and the current wording of every customer-facing service commitment. This pack becomes the baseline against which later decisions are tested.

Days 21 to 45: Protect the promise before harmonising it

The instinct in weeks three to six is to harmonise service levels as quickly as possible, usually by adopting the more economical of the two. That instinct should be resisted. Harmonisation is a legitimate end state, but it is not a safe early move when customers on one side of the merger have been promised something better.

Instead, establish an interim service promise bridge. This is a documented statement of which commitment applies to which customer group, for how long, and who authorised any temporary divergence. Where a regulatory clock applies, such as complaint handling timeframes, the bridge should state explicitly that the stricter interpretation prevails until a formal change is approved. Where vulnerable customers are identified under either estate's processes, the bridge should specify which support route applies and how staff will recognise it.

The bridge is not a permanent arrangement and should carry an expiry date. Its purpose is to prevent the integration programme from quietly downgrading a promise while the operating model is still being decided.

Days 46 to 70: Decide who owns the call

By the middle of the hundred days, the audit should be able to name the decision rights for the combined estate. This is usually the weakest part of a post-merger service model. Two teams may share a queue while reporting to different leaders, each with authority to change priorities, escalate differently or grant exceptions. The result is a queue with two masters and no single accountable owner.

A decision rights schedule should cover intake ownership, prioritisation, exception approval, supplier change requests, complaint escalation and the authority to amend a customer-facing promise. For each, record the accountable role, the consulted roles and the forum in which disputes are resolved. Where the two legacy models conflict, record the conflict rather than papering over it with a joint committee that has no decision power.

This phase should also surface inherited supplier arrangements that sit inside the customer journey. A contract that was proportionate for one estate may be disproportionate, duplicated or misaligned when two estates combine. The audit does not need to renegotiate terms, but it should flag which suppliers now serve a route they were not designed for.

Days 71 to 100: Keep, merge or retire

The final phase converts evidence into decisions. Each component of the combined estate should be tested against three questions. Does it support a promise we intend to keep? What does it cost to serve through this route compared with the alternative? Can we control it, including its supplier dependencies and its data flows?

Components that pass all three are kept. Components that serve the same need with comparable control and cost are candidates for merge, with a named owner and a cut-over date. Components that fail the promise test, or that cannot be controlled, are retired. Retirement should include the customer communication plan, the internal decommissioning steps and the evidence that the replacement route is live before the old one closes.

The output of day 100 is not a finished operating model. It is a decided set of components, a decision log, a customer promise bridge with an expiry date, and a named accountable owner for the combined front door. That is enough to move into business-as-usual delivery without inheriting the ambiguity of the deal itself.

An audit of this kind is judged less by the elegance of its target design than by the quality of its decision trail. In a merger, the operating model is not what the programme says it will be. It is what the combined front door actually does on the Monday morning after the announcement, and every Monday after that.