A CFO points at the portfolio and asks why two business units need two CRM systems costing £1.4M a year between them, and asks you to consolidate. Walk me through how you would answer.

What the interviewer is testing

Whether you treat "two systems doing the same thing" as a finding or as a hypothesis. Most candidates start designing the consolidation. The senior move is to establish whether the two systems are supporting the same capability or two different capabilities that share a category name, because the answer decides whether consolidation saves £1.4M or destroys two working businesses.

They are also testing whether you can talk to a CFO in the CFO's terms without pretending the technical question is simple.

The clarifying questions that change the answer

• What does each system actually do? "CRM" covers contact management, quoting, pipeline forecasting, service ticketing and marketing automation. Two units may overlap on 20% of that and share nothing else.
• What differs between the units' customers and sales motions? A unit selling six-figure multi-year contracts to enterprises and a unit selling monthly subscriptions online have genuinely different processes, and the system difference may be a symptom rather than a cause.
• Where does the £1.4M sit? Licences, hosting, integration maintenance, or the five people administering each. Consolidation saves licences and hosting; it rarely saves the people, and it adds an integration programme.
• Is a merger or divestment planned? A unit that may be sold in two years should not be merged into a shared platform, and this is the question most likely to change the recommendation entirely.
• What has been tried before? A previous failed attempt is the most useful evidence available, and there usually is one.

A strong answer's arc

Start from the capability, not the system. Decompose "customer relationship management" into the capabilities each unit actually performs, map both systems onto it, and show the overlap as a picture: this is where a capability map earns its existence, as the frame that makes the comparison possible rather than as an artefact for its own sake.

Then present the honest arithmetic. Typical shape: licences and infrastructure are perhaps 40% of the £1.4M and are genuinely recoverable; integration and administration are the rest and mostly are not, because the work follows the processes rather than the software. Against the recoverable share, put the one-off cost — data migration, retraining two sales organisations, a year of reduced productivity — which for CRM consolidation routinely exceeds two years of the saving.

Then give a recommendation with a decision rule, not a study. Something like: consolidate where the capability and the process are the same and only the tooling differs; keep both and integrate the data where the processes genuinely differ. And offer the cheaper intermediate: a common customer identifier and a shared analytical view gives the CFO the cross-unit reporting that is often the real request, at a fraction of the cost and risk.

Common weak answers

• "Yes, we should consolidate." Agreeing before knowing whether the processes are the same.
• "No, the business units are different." Defending the status quo without evidence, which is how architecture functions become the department of no.
• Proposing a six-month study. The CFO asked a question and will interpret a study as an inability to answer it. Give a position in the meeting, with the two or three facts that would change it.
• Talking about system features. The CFO does not care which product has better forecasting.

What a strong answer adds

The organisational reality, said out loud: CRM consolidations fail on adoption, not on technology. The sales organisation of the losing system has every incentive to resist, and the project's success depends on which unit's leadership sponsors it. Naming that in the room, and proposing that the decision be made by the two unit leaders rather than by architecture, is the answer that marks someone who has done this before.

And the reframe worth offering: if the CFO's underlying question is "why can't I see one view of our customers", the answer is a data problem with a much cheaper solution than replacing a system that people are using successfully.