Odoo for Multi-Branch Service Companies: One Calendar, One Customer View

Service chains usually grow one branch at a time, and each new branch copies whatever the first one did: its own booking book, its own spreadsheet of customers, its own price list on the wall. By the fourth or fifth location, head office no longer knows which branch is profitable, customers are treated as strangers when they visit another branch, and prices differ for no reason. This guide covers what breaks, what a shared structure provides, how to set it up in Odoo step by step, and the decisions to make before you start.

What breaks when branches run in isolation?

• A returning customer at a different branch is treated as new, losing service history that matters.
• Scheduling and resource availability are not visible across branches, so one location turns away a booking another could have handled.
• Management compiles branch reports manually to get a company-wide picture.
• Pricing and promotions drift inconsistently between branches without anyone noticing.

What does a shared structure provide?

• One customer record, visible and updatable from any branch.
• Shared or branch-specific scheduling, depending on how your resources actually work.
• Consolidated reporting across branches, alongside branch-level detail for local managers.
• Consistent pricing and promotion rules, with controlled local exceptions where genuinely needed.

How do you set up multiple branches in Odoo step by step?

The building blocks below exist in both Odoo Community and Enterprise; scheduling apps such as Appointments, Planning and Field Service are part of Enterprise. Menu names follow recent Odoo versions.

1. Choose the legal and accounting structure

If each branch is a separate legal entity with its own tax registration, set it up as its own company in a multi-company database. If branches are locations of one legal entity, keep one company and add the branch as a dimension on transactions; recent Odoo versions can also model branches under a company. This decision affects invoices, tax returns and access, so take it with your accountant.

2. Give every transaction a branch

Create the branch dimension once and use it everywhere: an analytic account per branch for revenue and costs, a sales team per branch for bookings and quotations, and a warehouse per branch in Inventory → Configuration → Warehouses if branches hold their own stock of parts or consumables.

3. Keep one customer database

Share customers across branches, with a single record per customer and their full service history. Use tags or the salesperson and team fields to show which branch looks after them, rather than creating the same customer once per branch.

4. Set up scheduling the way your resources work

If staff and rooms belong to one branch, schedule them by branch; if technicians or specialists move between branches, schedule them centrally. Depending on the service, this is done with Appointments for customer bookings, Planning for staff shifts, or Field Service for on-site jobs.

5. Control pricing centrally

Enable pricelists in Sales → Configuration → Settings, keep one standard price list, and add branch-specific lists only where there is a real reason, such as a different market or a local promotion. Head office then sees every exception in one place.

6. Give each branch the right access

Branch staff should see and work on their branch's bookings, stock and cash, while head office sees everything. In a multi-company setup, each user is allowed only their company; within one company, access rules and default teams and warehouses keep each branch focused on its own work.

7. Build the branch report pack

Group the sales, margin, utilisation and receivables reports by branch, and save them as favourites for branch managers and head office. The same data then serves both views, without anyone compiling spreadsheets at month-end.

What should you plan for specifically?

Decide early which resources are genuinely shared across branches (a customer's history, pricing rules) versus which are branch-specific (local staff schedules, local stock), since forcing everything into one model or fragmenting everything into separate silos both cause problems. The right balance depends on how your business actually operates day to day.

What does an implementation look like?

Here is how this typically unfolds, in an anonymised, illustrative example: a chain of maintenance service centres in Egypt with four branches, each keeping its own customer spreadsheet and price list. The work starts with the structure: one legal entity, so one company with an analytic account, sales team and warehouse per branch. Customer lists from the four branches are merged and deduplicated into one database before go-live. Head office agrees one price list, and two branches keep a short list of local exceptions. Branch staff see their own bookings and stock, managers see their branch reports, and the owner sees all four side by side without waiting for anyone to send a file.

Which numbers should head office compare across branches?

Once every transaction carries its branch, the same few numbers can be compared side by side:

• Revenue and gross margin per branch, after the branch's own costs.
• Utilisation: booked hours against available hours for staff, rooms or technicians.
• New versus returning customers, including customers served by more than one branch.
• Average ticket or invoice value, by service type.
• Receivables per branch: what each location has billed but not yet collected.
• Price exceptions used: how often local price lists or manual discounts were applied.

Comparing branches on the same definitions is often the first time an owner sees which locations carry the network and which need attention.

What are the common pitfalls?

• One database per branch: it looks simpler, but customers, prices and reports split again.
• Duplicate customers: importing each branch's list without merging recreates the original problem.
• Branch on some transactions only: if purchases or expenses carry no branch, branch profit is wrong.
• Too many local price lists: every exception is a future inconsistency. Keep them few and visible.
• Wrong legal structure: treating separate legal entities as one company, or the reverse, causes tax and reporting problems later.

Frequently asked questions

Can branches still have their own pricing where needed?

Yes, branch-specific pricing or promotions can be set while still sharing the core customer and scheduling data.

Does this work for franchise-style operations with different owners per branch?

It can, with appropriate access controls separating what each franchise owner sees versus what head office sees across the network.

How many branches before this structure becomes worth setting up?

Even two branches benefit from shared customer recognition; the case gets stronger with each additional location.

Should each branch be a separate company in Odoo?

Only if it is a separate legal entity with its own tax registration. Branches of one legal entity are usually better kept in one company, with the branch recorded on every transaction.

Can a customer book at one branch and pay at another?

Yes. With one customer database, bookings, invoices and payments are linked to the same customer record, whichever branch handles them.

Can we add a new branch later without a new project?

Yes. Once the structure is in place, a new branch is mostly configuration: a new analytic account, team, warehouse and users following the same pattern.

Give every branch, and every customer, one consistent experience

ExtraMile sets up multi-branch service company operations on Odoo, from the company structure to shared customers, scheduling and branch reporting.

Ask about multi-branch service operations or message us on WhatsApp: Egypt · Gulf

This article was drafted with AI assistance for ExtraMile Business Solutions.