Multi-Site CRM with Unified Messaging for a UK Services Group

A UK services group came to us with a problem that looked simple from the outside and messy from the inside. They had three live locations, each with its own team, its own diary pressure, and its own way of handling new enquiries. The group wanted a single CRM, but not a head-office spreadsheet pretending that every branch worked the same way. They needed one system that could give leadership a clear view without flattening local operations.

The real pain was not the lack of a CRM. It was the lack of ownership. New leads arrived through WhatsApp, SMS and email, then disappeared into shared inboxes that nobody fully owned. One site might reply within ten minutes. Another might leave a promising enquiry sitting in an inbox until the next morning. A lead could be copied to the wrong person, forwarded twice, or marked as dealt with because somebody thought another team member had picked it up. We built the system from scratch because the existing CRM options forced the client to compromise on the parts that mattered.

The problem

The group had grown faster than its operating model. What worked for one location did not work across three. Each site had different opening hours, different team members, different follow-up habits and different levels of comfort with digital enquiries. Head office wanted consistency, but the local teams needed a tool that reflected how they actually worked during a busy day.

The channels were the second problem. WhatsApp was where fast conversations happened. SMS was still useful for short confirmations and reminders. Email carried longer questions, documents and payment threads. In theory those channels all served the same customer journey. In practice they lived in different places, were checked by different people and left no reliable shared history.

The third problem was accountability. Shared inboxes create a comforting illusion of visibility, but they do not answer the operational question that matters most: who owns this lead right now? The client had a handful of cases where a prospect had shown clear buying intent, asked a follow-up question, and then received silence because the message was treated as someone else’s job. That was the failure we designed around.

The approach

We started by mapping the journey site by site. We did not begin with screens or features. We asked how a lead arrives, who replies first, what information has to be captured, when the enquiry becomes an opportunity, when payment matters, and when head office needs to see the state of play. The answer was similar across sites, but not identical, which is why a rigid off-the-shelf CRM would have caused friction.

The architecture followed that operating reality. Each location has its own inbox and pipeline, with group-level visibility above it. Permissions are per site, so staff can focus on their own work while managers can see the wider picture. We built the application in Next.js because the team needed a fast, tailored interface that could handle messaging, pipeline movement and payment context in one place.

The messaging layer was the centre of the build. We normalised WhatsApp, SMS and email into one conversation timeline so the team could see the whole history before replying. A customer who starts on WhatsApp and later sends an email does not become two separate people. The conversation stays joined, the owner stays visible, and the next action is clear.

We also built the AI template wizard because the client did not want staff improvising every reply. The wizard suggests approved responses based on the stage, location and enquiry type, then lets the user edit before sending. That kept the tone consistent without making the team sound automated. It also helped newer staff respond confidently without asking a manager to check every message.

What the system actually does

Every inbound enquiry becomes a lead record with a channel history, site assignment and current owner. The Kanban pipeline shows the operational state: new lead, contacted, waiting on customer, booked, payment pending, won, lost or follow-up later. Moving a card can trigger stage-based actions, such as a reminder, a payment link, a template suggestion or a manager notification.

The system keeps the everyday workflow simple. Staff live in one inbox for their site, reply through the same screen, and move the lead through the pipeline as the conversation develops. They do not need to check a phone, an email account and a spreadsheet to understand what happened. The context is already there.

Leadership gets the view they were missing. They can see enquiry volume by location, response status, bottlenecks, overdue leads and conversion movement. The important change is that the numbers are tied to real conversations, not manually updated status fields that go stale by Friday afternoon.

The outcome

Three locations are live. Fourteen months after launch, the group has recorded zero leads lost to email. The system has been in daily production for fourteen months, which matters more to us than a neat launch story. It has survived staff changes, busy weeks, new message templates, payment process changes and the normal friction of a growing services group.

The anonymised client summary was blunt: “We stopped arguing about who had seen what. Every site can run its own day, and head office can finally see what is happening without chasing people.”

What we would do differently next time

We would define the reporting layer earlier. In the first version, we focused correctly on the front-line workflow: receiving enquiries, assigning owners, replying quickly and moving leads through the pipeline. Reporting came after that. It worked, but it meant we had to revisit a few event names and status changes once managers started asking better questions.

We would also spend more time on staff onboarding content before launch. The interface was clear, but a multi-site CRM is still a behavioural change. People need to know not only where to click, but why ownership matters, when to move a lead, and what counts as a completed handover. The product did the job, but the training could have reduced the first week of hesitation.

The other lesson is that custom CRM work should stay close to the client’s real operating model. The temptation is to design a perfect central system. The better answer is usually a clear local workflow with enough shared structure for the group to manage performance.

This is the kind of CRM we build when the business has outgrown inboxes, but is not willing to bend its operations around a generic tool.