Every branch has its own website, agreement and publishing habits. A shared platform sounds like a way to simplify things. It can be, but first establish what can genuinely be standardised.
Do not start by multiplying one website's price by the number of branches. Shared components may reduce repeated work, while differences between branches can introduce additional scope.
Map what is shared and what stays local
Collect examples of typical content from each unit. Compare news, contact details, services, events and documents. Check whether the differences are only in the content or also in how it is managed.
Agree which elements are common: design, navigation, page layouts or search. List local needs separately, such as their own menu, bookings or an additional language. An exception at one branch does not automatically need to become a requirement for every branch.
Agree who can change what
Can the central team publish a notice across all sites? Can a branch edit that notice? Who approves a new page type? What happens when an employee moves to another unit?
Walk through these situations during a demonstration. A shared platform needs a working publishing arrangement as well as a shared login screen.
Ask what the next branch will cost
Separate the platform foundation, individual site setup, migration and maintenance. Ask for the cost of adding another branch using existing layouts, and the cost of creating something new for it.
Consider a pilot with one typical branch and another with meaningful exceptions. That gives you a way to check whether the model works in practice. Include editor preparation and training in the plan: shared technology will not prepare their content or decide who keeps it current.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database