Unifying customer service after forty-four mergers

Context

I was product owner for a customer-service platform at a Danish energy and utilities company built through successive mergers of 44 regional companies. The mergers had happened over decades, not in one event, and the application landscape had accumulated with them.

The three main product areas had been kept separate. Energy used two ERP systems and one CRM; mobile used one of each. Digital began with five ERP systems and two CRMs, although one ERP was retired early in our work. That left seven ERP and four CRM systems across the company. A long-running migration programme was simplifying the digital stack, but it was still in progress when I left.

Customer-service staff used several applications even within a single product area. New employees could spend months learning enough of the landscape to handle the full range of calls.

The presenting problem

The company wanted its first-line teams to support customers across product areas and take part in cross-selling. The initial scope covered six teams: two in energy, three in digital, and one in mobile.

This required both training and technical support. Agents could learn the products, but they still needed a practical way to identify a customer, see which products the company already supplied, and recognise obvious problems without reconstructing the answer across several systems.

The underlying problem

The most difficult cases involved products in motion: a new order, a change, a termination, or an internal migration. Those changes were often the reason a customer called. They were also the moments when the application landscape gave staff the least reliable view of what was happening.

We did not set out to replace the underlying systems. We needed to reduce the friction of identifying customers, their products, and the state of those products while the wider migrations continued. One early example was a simple indication that a customer was scheduled for, or already undergoing, an internal ERP migration. It gave staff an explanation that had previously been difficult to find.

What I did

The platform was one of four connected programme tracks, alongside the data lake, customer-record matching, and a cross-company order portal. A lead architect had conceived the platform, and a project manager coordinated the tracks. My product team included a lead developer, two successive UX specialists, a QA specialist, a Scrum Master, and about eight developers over the life of the work.

We began with large EventStorming workshops and then held weekly calibration sessions with customer-service change managers and education specialists. The product manager facilitated those sessions. I used them to decide which problems mattered, balancing things we could improve soon against work with a longer lead time. My contribution was to translate the team’s technical capabilities into feature options and give the group a high-level view of their likely cost.

I also visited customer-service departments around Denmark a couple of times a month. I sat with staff and listened to their daily work. The UX specialist often joined me, and sometimes the whole team came. Those visits gave us direct input, included the delivery team in the conversation, and gave me first-hand evidence when I argued for or against a feature.

Inside the programme, I argued for delivery in small slices rather than planning the complete platform and releasing it at the end. Working software, shown early to customer-service staff and adjusted with them, made the case more effectively than a roadmap could.

What changed

Staff gained one place to see a customer’s relationship with the company across product areas, including information that had previously required several applications and specialist access. The overview spread quickly beyond the six first-line teams to support, second-line service, back-office, retention, and sales staff.

The platform also became part of the practical sequence for introducing cross-selling targets. In many departments, the target was added to performance boards and incentive structures after staff received access to the overview. Mobile customer service had started earlier without that support; agents sometimes offered customers products they already had. The overview reduced that particular source of friction.

Evidence

In the final year, Google Analytics recorded more than 600 unique users on a normal weekday and between 1,000 and 1,200 over a week. We configured the tracking around employee GUIDs rather than relying on Google’s ordinary user identification. A separate access audit with the compliance team, organised by department and user, supported the scale shown in the analytics.

Monthly KPI boards showed cross-selling continuing to meet its targets, and the strategy managers gave the programme direct positive feedback. I cannot attribute that result to the platform alone. It was one of several initiatives, including training, performance measures, incentives, and organisational change. What I can substantiate is that many departments received the technical capability before cross-selling became part of their measured work.

Limits

The platform reduced the cost of navigating a fragmented stack; it did not remove that stack. The digital migration programme had been running for years before our work and had not finished when I left.

The clearest product failure was a recommendation engine for “Next Best Actions.” I inherited it as part of the business case. It was meant to reduce training by telling an agent which service or sales opportunity to raise. It attracted attention as a separate AI-enabled line of work and consumed many sprints over several years.

Repeated iterations produced the same result. The available data infrastructure could support only simple recommendations, while experienced staff could make better judgements from the overview itself. Requiring agents to follow the recommendations added friction and ran against how the departments worked. I argued against making it compulsory, but I did not persuade the programme to remove a feature tied to strategic rollout plans and company KPIs. It remained in the product, produced little value, and was periodically reopened without resolving the underlying constraints.

What this demonstrates

The useful product was not the one that tried to make decisions for customer-service staff. It was the one that made a complicated situation legible enough for them to use their own judgement.