An acquirer grown by acquisition was collapsing separately run brand and product websites into one corporate site, one content management system, one analytics stack and one CRM. The build had a plan. The question with no answer was who would run the result on the Monday after launch, and with what authority.
The challenge
The starting estate was the residue of the acquisitions: more than six legacy brand and product web properties, plus per-unit sites, campaign pages, servicing portals and a careers site, hosted and instrumented in different places by different people. The target state introduced four shared substrates at once: a common CMS, common analytics, common hosting, a common CRM.
The organisational constraint was set before the design work began. The steering group agreed there would be no group marketing function, so the estate had to be managed by the three existing business units: an e-commerce unit and two regional units. Governance, standards and pan-group direction were needed, and no box on the chart existed to hold them.
The capability baseline made the gap concrete. About 13 full-time equivalents were deployed on specific digital activity across marketing and product, excluding IT, HR, support and an acquired brand's own team, and the spread was uneven. The larger regional unit carried 8 digital-specific roles, plus 3 to 4 FTE in that brand's team. The e-commerce unit had 2 and a demand generation lead. The other regional unit had about 3 roles, one of them the sole developer. Only one unit had dedicated content specialists; elsewhere the work sat with a web producer, or with the developer who was also the whole development function.
Stakeholder interviews produced seven principles that pulled against each other. Units had benefited from autonomy and wanted to keep it, while accepting that a shared site needs shared rules. Commercial ownership of journeys had to stay local, but the parts every journey ran through, the site structure and the filtering rules, needed consensus before anyone changed them. The skills required did not all exist in the structure.
Two assumptions bounded the design: the platform would stay hosted for roughly 18 months on an initial 12-month contract, and the model was built around release 1.0 of the English-language site.
The approach
The scope was fixed first. A capability taxonomy of four pillars and about 17 named capabilities, from digital strategy and user experience through publishing, analytics and legal requirements to helpdesk and agency management, went to the steering group in the opening week, before the analysis started.
Every capability was decomposed into tasks, and each task assigned to one of two owners across nine domains: commercial, content development, analytics, content management, application development and maintenance, third-party management, governance, strategy and social. Pan-group tasks included global content and content architecture, the analytics and CMS roadmaps, hosting and agency management, and running the forums and the prioritisation process. Local tasks included owning local content, defining unit journeys through to fulfilment, and local social presences, inside federated access to the shared tools.
One line in that split did more work than the rest. Under commercial, the pan-group column carried a task to identify and resolve lead routing issues: the only entry that anticipated the units competing for the same customer rather than coordinating.
The tasks were then mapped onto a catalogue of 11 roles, 6 in marketing and product teams and 5 in group HR and communications, IT or operational teams, each classified existing, modified, or new. Three came out as new or new and modified: a digital leader, a webmaster and PMO support. Two more were classified existing and modified. The other six were marked existing, with the pack noting that their profiles would need rewriting only where their scope came to include pan-group tasks, the analytics manager being the worked example.
The digital leader role is the honest part of the design. It was scoped to shape the digital plan, bring thought leadership to the governance forum so it could make investment decisions, and act as key contact for the lead agency. With no group function to sit in, the role had to work through people who reported elsewhere, and the pack said so in its own risk column: the distributed option requires more influencing skills of the digital lead. Influence was the mechanism, by construction.
Four configurations of the same tasks and roles were written up with pros and cons: a group hub with the units as spokes, a leaderless shared model, concentrated leadership in one lead unit, and distributed leadership with topic owners across units. The hub scored well on impartial governance, then fell to the prior decision that no group function would exist. The leaderless model was rejected because without leadership the loudest voice wins. The two survivors were argued on where the resources already sat and which unit would carry the most traffic at launch.
Both survivors leave the same arithmetic behind them. Nine domains of pan-group work, each owned by one unit and needed by all three, is eighteen unit boundaries somebody has to cross without line authority over the people on the other side. That count holds whether the nine sit together in one lead unit or are spread across topic owners in all three. Choosing between the two options changed who did the crossing and never how much crossing there was, which is why influencing skill ended up in the risk column rather than in a job description.
The cost answer was deliberately small: a net increase of 1 or 2 FTE depending on the option, meaning 3 or 4 gross new roles offset by 2 existing roles removed in the larger regional unit. Cost from upgrading roles was acknowledged and left unquantified rather than guessed.
The outcome
What was handed over was a design and a decision, not a delivered organisation: the task split, the role catalogue, two shortlisted configurations, the headcount impact, and a transition plan running from launch into the months after it, across 11 workstreams and three new governance bodies. The steering group would agree it, then put the recommendation to the executive team, because there were people and budget implications.
Five areas were still open when the pack closed: team sizing and costs, definition of the new and modified roles, terms of reference for the forums, the standards themselves, and third-party support. An operating model that names its own unfinished business is more useful than one that pretends to be complete.
The transition summary was blunter than the org chart about what would actually break. Continued support was available from the same external individuals, but the pack recorded that it had to be confirmed very quickly, to stop the loss of the people who had built up deep knowledge and relationships over the build.
The risk was never losing a supplier. It was losing the specific people who held the context.
Read more than a decade on, the shape of this problem is unchanged in payments and the load has gone up. The estate an acquirer runs is no longer a corporate site and some social pages; it is checkout, merchant onboarding, dispute handling, developer documentation, status pages and pricing, each with a commercial owner who wants control of the journey and each governed by rules nobody can afford to enforce by hand.
Applied AI changes the economics of three of the nine domains outright. Standards adherence was a human tax: guidelines documents, education sessions and sign-off queues existed because no one could inspect every page. A policy engine with model-based checks now reads every change against brand, legal, accessibility and regulatory rules as it is proposed, which turns the pan-group standards task from a standing committee into a test suite with an owner. Analytics was scoped as one person defining common reporting methods; an agent can produce per-journey analysis on request, so the durable pan-group asset becomes the semantic layer, the shared definition of a lead, a merchant or an application, rather than the report templates on top. Lead routing, that single conflict-resolution line, belongs in running code with every routing decision logged, not on a forum agenda once a month.
Those three stop being three improvements the moment they are wired to each other. A routing decision writes into the same semantic layer the analysis reads. A failed standards check returns the change to its author with the rule it broke attached. The governance forum receives the exceptions instead of the queue. That is an interconnected pipeline rather than a set of tools: agents carrying a real share of how the estate runs, each with a scope, a named owner and a log, moving work between systems the way a merchant application already moves between them. Autonomy in it is graded, not granted. An agent publishing a local page inside a template nobody disputes is a different risk from an agent changing the filtering rules every journey runs through, and the task-by-task split this engagement produced is the line along which that grading gets drawn.
The half of a payments estate this engagement never had to model is the half where the work arrives as documents and images. Merchant onboarding takes in incorporation papers, identity documents, bank statements and premises photographs. Dispute handling takes in receipts, delivery evidence and screenshots. Vision models read those where they land, pull the fields, flag the trading name on the application that does not match the one on the bank statement, and hand an underwriter an assembled case rather than a folder. The web estate is the same problem in a smaller frame: alt text, contrast and asset licensing across a multi-brand migration are checks a model runs on every image, not a sample a web producer gets through before the next campaign.
What does not automate is the part that made this engagement hard. No group function existed because of ownership and budget, not tooling. Agentic systems do not decide which unit owns the customer journey, whose profit and loss pays for the shared platform, or what to do when a local campaign cannibalises another unit's traffic. Those are decision rights, and they still need a named holder and a forum with a prioritisation process.
The practical lesson for an executive today is sequencing, and then speed. Agents can only be given work that has been written down as work. An explicit task inventory, a decision-rights map, and standards precise enough to be checked are what this engagement produced on paper in ten weeks, and what any organisation needs before it can hand a piece of that estate to software. What has changed is how long the half after that takes. It is loop and harness engineering now: a loop that plans a change, executes it against the real CMS, analytics and CRM, and tests its own output against the standards; a harness holding the fixtures, the evaluations, the permission boundary and the audit trail, so the loop runs unattended and stops at the gates the model already names. Read that way, the nine-domain split is close to a harness specification, because every pan-group task with an owner is a check waiting to be written. A team working from it is not staffing a standing committee per domain. It writes the checks once and lets the loop run them against every change, which is a far shorter road than the transition plan of that era assumed. Firms that skipped the writing-down step do not have an AI adoption problem. They have an operating model problem that AI has made visible.