Setting up CRM for multiple branches and teams

Tuesday morning, and the phone rings at the western branch of an industrial equipment distributor. It is the purchasing manager at a food plant, and she has two quotes in front of her. One came from the western branch, one from the coastal branch. Same machine, two different product codes, two different lead times, and two discounts that do not agree. She wants to know which one is real. In that call the company is not negotiating its price; it is putting its internal disorder on the table. The deal closes eventually, three points below the margin it should have carried.

Running a CRM across several branches or several teams is not a bigger version of a single-office setup. It is a different class of problem, and most of it is decided before anyone logs in. What follows covers why the org chart cannot be copied into the CRM, how to choose an ownership and visibility model, what happens when the same customer lands in two branches, whether the pipeline should be split, which fields stop being optional, how incoming demand is routed to a branch, who gets credit when two branches close one deal, how branch comparison can be made fair, and where the line between central standards and local freedom belongs.

RegionBranchTeamRepCompany

The org chart is not the CRM model

Most multi-branch setups begin the same way: someone opens the HR org chart and copies it into the system. Managing director, regional managers, branch managers, reps. An org chart describes who reports to whom. A CRM needs to describe how a record moves from one person to another, and under which rules. In most companies those two answers do not match.

A concrete example. The technical sales team sits at head office but works on large projects in all three branches. In the CRM it has to behave like a second interested party on individual records, or the engineer at head office cannot see the very opportunity he is engineering. In setups that copy the chart verbatim, that person opens his own spreadsheet to get the work done, and the system springs a leak in month one.

Branch, team and territory are three different things

A branch is a physical and usually a financial unit: its own stock, its own cash, sometimes its own legal entity. A team is a unit of work, and one team can span two branches. A territory is a market definition and need not follow branch borders at all. Setups that squeeze all three into one field come apart at the first reorganization, because changing the market then forces you to change the branch structure. Separate fields let you redraw territory and account planning without touching the branch model.

Who gets to see whose records?

This is the most expensive decision in a multi-branch setup, usually the most rushed, and it has two layers. Ownership is who is responsible for a record, and it must resolve to one person; an opportunity with two owners is an opportunity with none. Visibility is who may read and who may edit, and it need not sit at either extreme.

Four models are in common use, and the choice follows from how much customer overlap exists between branches. If the branches genuinely serve separate markets, strict separation works cleanly. If more than one branch touches the same customer, it does nothing but manufacture the duplicate-quote accident from the opening scene. Measure the overlap before you decide: over the past year, how many companies were opened as records in two different branches?

Visibility model	When it fits	Side effect
Strict separation	Branch markets never overlap	Double contact on shared accounts
Hierarchical	Managers see below them, not sideways	Lateral cooperation weakens
Shared read, separate write	Several branches touch one customer	Pricing detail travels between branches
Pool and claim	Demand is uneven, capacity varies	Unclaimed records age in the pool

Once the model is set, the work turns into role definitions: which role can read, write, delete and export which object. Export rights are almost always overlooked, and a branch manager who can pull the whole customer list on the way out is the quietest risk in a multi-branch structure. We cover the permission layer in our guide to roles and permissions.

What happens when one customer lands in two branches?

The opening scene is not an accident; it is the predictable output of a configuration choice. When the same company is created as two records in two branches, the system does not register a conflict, because as far as it knows there are two customers. The fix is a uniqueness check at creation time against a key that actually holds: tax number, email domain, or a normalized legal name. Without one, deduplication always arrives late, because it only starts when a human happens to notice.

Decide in advance what happens when a match is found. For most small and mid-sized companies the workable rule is that the company record is single and lives at the center, while opportunities attach to branches. Two branches can then work the same account in parallel, but each sees the other's open opportunity before a quote goes out. The mechanics of that check sit in our article on data quality and validation.

One pipeline or one per branch?

The common advice is to give every branch its own pipeline so each manager looks only at their own board. For most companies the opposite is true. If the branches do the same work, the pipeline should be single and the branch should be nothing more than a field. The reason is simple: the moment stages split, definitions split with them, and six months later one branch means something different by quoted than the other does.

Separate pipelines are justified only when the sales process genuinely differs. If one branch runs survey-led project work on a quarterly cycle while another sells over the counter and closes within the week, a single stage list lies to both. The test is not the branch name but the exit criteria of each stage: if both lines advance a deal for the same reasons, they belong in one pipeline.

The framework for defining stages and deciding how many are enough, set out in our piece on pipeline templates, applies here unchanged.

Which fields stop being optional?

Keeping mandatory fields to a minimum is the right instinct in a single office, since every required field slows entry and erodes adoption. In a multi-branch structure a handful become exceptions, because without them not only reporting but daily operations break.

• Owning branch: Which branch carries the record. Reporting, targets and permissions all rest on this field, so it must never be allowed to sit empty.
• Source branch: Where the request first landed. It can differ from the owning branch, and it is the only field that shows which branch a marketing spend is actually working for.
• Servicing branch: The unit that delivers, installs or supports. When it differs from the selling branch, cost and revenue accumulate in different places and profitability readings distort.
• Owning rep: One name. A team field can sit alongside it, but responsibility must not be shared.
• Applicable price list: When lists vary by branch or region, the record has to carry the answer, or whoever builds the quote is relying on memory.
• Shared account flag: A simple marker on customers touched by more than one branch. It is the cheapest mechanism there is for preventing duplicate quotes.
• Transfer date and reason: When and why a record changed hands. Without it, no transfer dispute ever ends.

Most of these should not be typed by hand, and most need not be. Owning branch follows from assignment, source branch from the form or channel, price list from the branch. Leave only the transfer reason to a person, and reduce even that to a picklist of three or four options; free text answers no question six months later, because everyone phrases it differently.

Which branch does an inbound request go to?

Routing is where a multi-branch structure is genuinely tested. Geography is the best-known criterion, but it is not sufficient alone and in some businesses it is simply wrong: for a company selling online, a postal code carries far less information than which branch holds the product in stock. A sound rule chain usually runs product or service group first, then language, then geography, and capacity last.

Capacity belongs last: apply round-robin first and the wrong branch takes the right branch's work, so the customer's first call reaches someone who cannot help. We set out the underlying logic in our article on lead assignment rules; the only layer multi-branch adds is that the rule chooses a branch first and a person second.

End the rule chain with a catcher

Requests that match no rule always arrive: a form with no address, an unclassifiable product question, a message in an unexpected language. Define an unassigned pool and one person who checks it daily. Without a catcher these requests sit in the system without appearing on anyone's screen, and that blind spot is where most lost leads disappear.

Two branches, one deal: who gets the credit?

Transfers between branches are unavoidable. The request lands with the branch nearest the buyer, the survey is done by the branch nearest the plant, and the contract is signed somewhere else again. Whose number is that deal? Answer it late and two managers put the same figure into their own reports at month end, revenue inflates, and finance is the first to notice.

Three approaches work. Assign the deal to one branch and give the other activity credit only: easiest to configure, and it feels unfair when the contribution was large. Define a percentage split: heavier to set up, highest sense of fairness. Or book revenue to one branch and quota to both: accounting totals stay clean, and nobody feels robbed. Whichever you choose, mark the transfer moment on the record with a date and a reason. How context gets handed over during that transfer sits in our piece on team collaboration.

How do you compare branches fairly?

The first dashboard built in a multi-branch company is almost always the same: branches ranked by revenue. That board does not measure the wrong thing; it rewards the wrong thing. The branch with the larger market sits at the top even with an average team, while an exceptional team in a small market sits at the bottom. The consequence stops being numerical quickly: the best people in the bottom branch leave.

A dashboard that ranks branches by raw revenue rewards the best market, not the best team.

Fair comparison is built on ratios: conversion rate, win rate, average deal size, cycle length and pipeline generated per rep. Add a target normalized to potential, derived from the size of the market rather than last year's billing. How to set and distribute those targets is covered in our article on setting sales quotas.

The other invisible problem is definitional. If one branch means an opportunity touched in the last thirty days by active and another means every opportunity not yet closed, the two figures cannot be compared, and both are internally correct. Past three branches, writing a shared metric dictionary becomes more urgent than designing another dashboard.

Central core, local freedom: where is the line?

Grant every branch the right to customize everything and in six months you have four systems. Allow nothing and branches drift back to their spreadsheets. The split that works: the data model and stage definitions are central, the way of working is local. Field names, mandatory fields, stages and report definitions are governed centrally; saved views, dashboard layouts, reminder cadences and templates belong to the branch.

Change requests need a queue as well. Where a branch manager can add fields directly, five different budget fields appear within months and none of them compare. Testing a change in a separate environment before releasing it is the cheapest route, and our article on sandbox and change management walks through that flow. Keep the audit log on for the same reason: in a multi-branch structure, the question of who changed this field comes up far more often than in a single office.

Where to start and what to avoid

Three mistakes feed each other. The first is designing around one branch's needs and imposing the result on the rest. The second is deferring the visibility decision, opening everything to everyone, and trying to tighten it six months later; a permission taken back generates several times the resistance of one never granted. The third is attaching branch information to the user rather than to the opportunity: when a rep moves branch, every historical deal moves too, and last year's report changes overnight.

A sequence that works: pilot with two branches, at least one of them not head office. Write the visibility model and the transfer rule on a single page, run only those two for a fortnight, and record the objections. If most turn out to be about visibility rather than permissions, you tested the model in the right place. Add the third branch next, and write automation rules only after that; automation written early only accelerates the wrong model.

What a multi-branch company needs is not a separate system per branch, but one data model with a view that narrows by branch. In Rocketly, user roles, record ownership, assignment rules and branch-level reporting run inside the same configuration; create a free account and build your own branch and team structure.