Multi-location sales call quality: one standard

Ten branches, ten different sales processes

As a network grows, different companies appear inside the same company. A script written at head office is applied literally in one branch, partly in a second, and has never been seen in a third. The customer calling believes they are calling one brand.

The difference is usually explained as weak management, when the cause is structural. A branch manager makes the daily decisions, staff turnover is local, the phone line is often separate, and no report compares branches on the same unit.

This article shows how one standard is built: what to centralise and what to leave local, the three possible models, routing, comparing branches fairly, and the resistance that meets the change.

Where the difference comes from

The gap between branches appears in four specific places, and each needs a different fix.

1. 1Local decision authorityThe branch manager decides on price, discounts and priorities. That creates flexibility and breaks the standard — both come from the same source.
2. 2Staff and turnoverNew people are hired locally and trained locally. Whoever trains them learned from someone else, so the script shifts slightly at every handover.
3. 3TelephonyEach branch has its own number and its own line. Where calls land, who answered and how long anyone waited is invisible from the centre.
4. 4No measurementBranches are compared on sales figures rather than on the calling process. Sales figures depend on location, footfall and the local market — they do not describe the process.

The fourth cause conceals the other three. When the process is not measured the gap is invisible, and an invisible gap cannot be managed — so it widens as the network grows.

What to centralise, what to leave local

Attempting to centralise everything ends in resistance and is usually rolled back. What works is a split.

• Centralised: the first-response standard, qualification questions, outcome codes, CRM fields, inbound routing
• Centralised: working hours and queue rules, recovery of missed calls
• Local: price negotiation, local campaigns, the personal relationship
• Local: conducting the meeting, the site visit, the service itself
• Shared: the local details in the script — address, delivery times, local terms

The logic is simple: the customer's first experience should be the same everywhere, while later stages can follow local reality. The call is that first experience, which makes it the right place to centralise.

In practice most branches do not resist this split, because they benefit from it — first contact and qualification is the work they like least and it consumes most of their time.

The three possible models

Three models work for networks, and the choice depends on the number of branches, the geography and the product.

1. 1Fully centralised callingAll inbound and outbound calls reach a central team or the AI agent; the branch takes part at the meeting and service stage. Highest standard, most resistance.
2. 2The hybrid modelFirst contact and qualification are centralised, and qualified leads are passed to the branch. The most used option in practice and the one that generates least resistance.
3. 3Local calling, central standardThe branch makes the calls, but the script, the outcome codes and the reporting are shared. Quick to set up; holding the standard requires continuous attention.

Most networks start with the second model and move some segments to the first later. The third is fastest to build and the most likely to drift back over time — local habit is stronger than a written rule.

Routing: which branch gets the call

In a centralised model the most technical part is routing, and it should be written as a business rule.

• Geography: where the customer is, or the area code of the number
• Existing relationship: if the customer already worked with a branch, the call returns there
• Working hours: if the branch is closed, the call moves to the centre or the next branch
• Load: the queue rule when several calls arrive at once
• Product or service type: some services exist only at certain branches

The second line is the most commonly forgotten and the most irritating. If a customer had a conversation at one branch and their next call lands at another, everything starts again — even when the history exists in the system, because the new branch does not look for it.

Testing the rules by simulation before they meet live calls removes this: «if this number calls at 11 on a Saturday, where does it land?» should have a known answer.

One script, local detail

One script does not mean every branch says the same sentence. It does not mean local differences are forbidden — it means they are written down.

• The skeleton is central: opening, fit questions, decision points, close
• Local variables are separate: address, opening hours, delivery times, local promotions
• Local additions are approved and go into the knowledge base — they do not stay verbal
• A change is made in one place and reaches every branch at once
• Which branch is using which version is visible

The fourth line is the real benefit of centralising. When pricing changes, instead of ten emails to ten branches and hope that each was read, the change is made once. In practice that removes the most common cause of a standard breaking.

Comparing branches fairly

As soon as a central model exists, the urge to compare branches appears — and this is where most of the mistakes are made.

• Comparing sales figures is wrong: footfall, location and market differ
• Process metrics can be compared: response time, conversation rate, outcome code completion
• Normalising by volume matters: two out of ten and twenty out of a hundred are the same rate with very different reliability
• Seasonality is accounted for: some branches sit in seasonal markets
• The comparison is shown to the team openly — a hidden ranking costs credibility

Measurement itself — which metrics to track and how to read them — is set out in telesales call metrics. The only addition here is the branch dimension.

Resistance and rollout

Most centralisation projects stall for organisational rather than technical reasons, and the source of the resistance is predictable.

A branch manager worries about two things: losing control, and the effect on their own numbers. Both are legitimate, and both have the same answer — the split is written down, and the branch can see its own leads.

A practical step: choose the pilot branch by volunteering. A pilot assigned from the centre works against resistance; a branch that volunteered defends the result itself, and becomes the most convincing argument for the others.

Limits

Centralising does not replace local knowledge. What a branch manager knows about their market, their customers and their competitors is not held at the centre and cannot be written into a script.

How Vexvon supports this model

On the Vexvon side the network structure and the routing rules provide what this model needs.

• Routing: time policies, destinations and prioritised rules — where a call lands is built as a written rule
• Simulation: rules are tested before they meet live calls
• A parent/child company structure: for multi-brand and network setups, with shared subscription
• Scenarios are configured centrally, and the knowledge base decides which information is approved
• Knowledge base contexts can be targeted — local detail is kept separately, inside the same system
• Outcome codes and CRM fields are identical across branches, while reporting can be cut by branch

Inbound call handling is on the call center page, and the structure of the knowledge base on the knowledge base page.

First step

Over one week, compare two branches on the same three criteria: response time, conversation rate and outcome code completion. The gap is usually larger than expected, and it moves the conversation onto numbers.

To discuss which model fits your network, get in touch.