Guide

How to Manage Multiple Laboratory Branches

Running branches as one lab, not two shops that share a name — shared catalogues, central pricing, one patient record and per-branch numbers.

Test analytics screen in A Pulse Solution showing tests performed, completion rate, distinct tests and busiest month, with a tests-per-month chart and a per-test monthly breakdown table

The first lab runs on the owner's eyes. They are physically there — they see who is at the counter, they notice the day the queue is short, they know which technician is having a bad week. None of that is written down anywhere, and it does not need to be.

The second branch is where that stops working. From the day it opens, everything the owner knows about half their business arrives second-hand and a day late, reported by people with their own view of events. That is the moment most owners start looking for a system, and it is usually the moment after they needed one.

This article is about running branches as one lab operating in several places rather than as several shops that share a name. We build multi-branch lab software, and multi-site operation sits on our Premium plan, so the product references below are one worked example.

What Actually Changes When You Open Branch Two

Three things break at once, and they are all versions of the same problem.

Direct observation ends. Every number about the second branch now reaches you through somebody. That is not an accusation of dishonesty — it is that people summarise, round, forget, and describe a bad day as an unusual day.

Standards start to drift. Left alone, each branch develops its own rate list, its own report habits, its own way of handling a discount request. The drift is gradual and nobody decides on it. It becomes visible about a year later when a referring doctor mentions that your two branches quote different prices for the same test.

Data fragments. If the branches keep separate records — separate registers, or worse, separate software installations — a patient who used one branch is a stranger at the other, and you have two half-histories that can never be cleanly merged.

The rest of this article is the work that prevents each of those.

Standardise the Catalogue and Rate List First

Before software, before staffing, before anything: one master test catalogue. A test must mean the same thing at every branch — same name, same units, same reference ranges. If Branch A's "Blood Sugar Random" and Branch B's "RBS" are separate entries with separate ranges, you do not have a chain, you have two labs.

On pricing, per-branch differences are legitimate. A branch in a different neighbourhood genuinely faces a different market, and forcing the flagship's rate list onto it can be a straightforward mistake. What matters is that any difference is decided centrally and deliberately, not improvised at a counter by a receptionist trying to keep a customer.

So settle two rules explicitly and write them down:

  • Who is authorised to change a price, and by what process.
  • How a price change reaches every branch the same day — which, if you are on paper, is genuinely hard, and is one of the plainer arguments for a shared system.

Do this cleanup before you migrate anything. Digitising a messy catalogue produces a digital mess, and it is much harder to fix once every branch has been trained on it.

One Patient Record Across All Branches

Central record numbers are the difference between a chain and a franchise. A patient walks into whichever branch is convenient today, and their history is there — previous visits, previous results, the identity they already have.

This is where the software architecture decision becomes irreversible. Separate local databases cannot be merged cleanly later. Not "with difficulty" — cleanly. Two branches that each ran their own installation for two years will have overlapping record numbers, the same patient under different identities, and no reliable key to match them on. The migration that fixes it is expensive and lossy, and it is entirely avoidable by choosing a shared system at the point you open branch two.

A browser-based system makes this the default rather than a project: every branch logs into the same system, sees the same catalogue, and writes into the same patient record set. In our implementation, patients, orders and invoices are tagged per branch, so the records are shared while the reporting stays separable.

Consistent Reports, Whichever Branch Prints Them

A referring doctor should not be able to tell which branch issued a report by looking at it. Same layout, same logo, same reference ranges, same flagging rules.

This matters more than it sounds because the report is your lab's public document. When one branch's reports look different — a different header, a different arrangement, ranges that disagree with the other branch's — the reasonable conclusion a doctor draws is not "that branch uses a different template". It is that the lab is inconsistent, and inconsistency in a laboratory implies something worse than formatting.

QR verification helps at exactly this scale. A code on the report lets a doctor, employer or another lab confirm the document was genuinely issued by your lab — which matters most in a branch network, where your name travels further than any of your staff can personally vouch for. It is a Premium feature in our plans, alongside multi-branch operation, and the pairing is deliberate.

Daily Numbers Per Branch, Without the Phone Calls

What the owner should see each evening, without asking anyone: registrations, revenue, discounts and dues, broken out by branch.

Test analytics screen in A Pulse Solution showing tests performed, completion rate, distinct tests and busiest month, with a tests-per-month chart and a per-test monthly breakdown table
Volume and completion rate over time, broken down by individual test — available on Medium and Premium plans.

The value is not the individual day. It is the trend line, which shows a branch sliding before any single month looks bad enough to discuss. A branch that is quietly losing ground produces a series of individually explicable weeks — a wedding season, a competitor's promotion, rain — and the pattern is only visible when the weeks are lined up next to each other.

Set the cash discipline explicitly too: who closes the day at each branch, what they compare against, and what happens to a difference. Reconciliation per branch, done the same evening, against a number the system produced rather than a total someone assembled. A difference discovered the next morning is a question; a difference discovered at month end is an argument.

People and Process Across Branches

The organisational half, which software does not solve.

Define what the branch manager owns and what stays central. Local: staffing, the counter, day-to-day service, sample logistics. Central, always: pricing, the test catalogue, report format, and any policy about discounts. Ambiguity here is where drift enters.

Rotate staff between branches. It is the most effective way to keep habits identical, and it also means no branch is a single person's private territory. Staff who have worked at two branches notice when one of them has invented its own procedure.

Centralise training when a process changes. A change explained separately at each branch becomes two slightly different changes.

Plan sample logistics properly if some tests run only at the main lab. Who carries samples, on what schedule, what happens to the last collection of the day, and how results flow back to the originating branch. The collection-centre pattern — several small registration points feeding one testing lab — is common and works well, but it lives or dies on the runner schedule, and patients judge you on the turnaround it produces.

Common Multi-Branch Mistakes

Choosing separate software or registers per branch. The one genuinely expensive mistake in this list, because it is the only one that cannot be corrected later without losing data.

Copying the flagship's rate list into a very different neighbourhood. Prices that work on a main road do not automatically work elsewhere, and discovering this through six months of thin volume is a costly way to learn it.

Expanding before the first branch's processes are written down. If the original lab runs on the owner's presence and a set of habits nobody has articulated, there is nothing to replicate — the second branch will invent its own version of everything. Write the processes down first; opening a branch is the worst possible time to discover you never had any.

Assuming the second branch will behave like the first. Different catchment, different referring doctors, different test mix. Budget it as a new lab, not as a copy.

If you are weighing this decision, it is worth pricing the multi-branch tier before you commit to anything, so you know the number in advance. Ours is on the Premium plan, and if you would like to talk through how your particular network is shaped — full branches, collection centres, or a mix — our team is happy to work through it. Labs inside hospitals have a different shape again, which we cover under hospital laboratory software.

Frequently Asked Questions

Can I run two branches on separate lab software and merge later? Technically something can usually be salvaged, but not cleanly. Separate databases produce duplicate record numbers and the same patient under two identities with no reliable key to match them. If a second branch is realistic within a year, choose a shared system now.

Should branches have different prices? They can, where local markets genuinely differ. The requirement is that any difference is decided centrally and applied deliberately, rather than improvised at the counter — and that you can explain it if a referring doctor asks why two of your branches quote differently.

How do collection centres differ from full branches? A collection centre registers, bills and takes the sample but does not test; the work happens at the main lab and results flow back. They need the same registration and billing tools but no result entry, and their turnaround depends on runner scheduling rather than on bench speed.

What should the owner see every day from each branch? Registrations, revenue, discounts and dues per branch, plus the trend over recent weeks. The trend is what shows a branch weakening before any individual month looks bad.

Which plan covers multi-branch operation? In A Pulse Solution, Premium — unlimited branches with patients, orders and invoices tagged per branch, unlimited staff accounts, and QR report verification. Other vendors tier this differently, so confirm before you sign.

How do I stop branches drifting apart operationally? Keep pricing, catalogue and report format central; rotate staff between sites; train centrally when a process changes; and review per-branch numbers on the same schedule for every branch. Drift is a consequence of separate attention, not of bad intentions.

Every branch network is shaped differently.

A main lab with collection centres runs on different rails than three full branches. Tell us how yours is structured and we will show you what the setup would look like.

Talk to our team