How a Province rolls out lodge operations without merging records

Give each lodge its own home (records, branding, site), pilot the operating system on three to five lodges, then offer the rest a path that includes one-click annual returns and a console the Province can actually use.

If the first workshop is a debate about merging every member into one warehouse, you are solving a problem this article refuses to set.

Lodges already have a Secretary, a Treasurer, a bank account, a charity story, and a way they speak to members. A Provincial rollout that overwrites those is not a rollout. It is a takeover the lodges will quietly refuse.

Separate lodge records, branding, and sites are the unit of work. A brother who sits in two lodges is two memberships, not a reason to smash the databases together. Provincial officers switch context to look at a lodge. They do not live inside a blended register.

Shared rollout support is real: training, a named contact, a pattern for summons, dues, and Gift Aid that each lodge can adopt. Shared support is not shared gossip. Welfare cases and candidate cards stay in the lodge that owns them.

LodgePay's published buying path is the one on the pricing and Provinces pages. Most provinces start with a small pilot of three to five lodges, prove the case at provincial council, then roll out. Help is offered on the business case, data migration, and officer training. This article will not invent a different sequence.

Pick lodges that will actually run the year: a Secretary who will send a summons, a Treasurer who will import a bank CSV, a Master who will look at the board. A pilot of lodges that only want a brochure site will prove nothing about annual returns.

Agree in writing what "proved" means before you start. Typical operational tests, not rules from above: can two lodges send a summons from the same platform without sharing members. Can a Provincial officer switch context and see only what that lodge's permissions allow. Can annual returns come out as CSV without a summer of retyping. If you cannot name those tests, council will hear a software pitch instead of a result.

The painful Provincial task most teams still rebuild by hand is the annual return. Each lodge types. Someone chases. A spreadsheet is merged. A figure is argued. The year is late.

LodgePay publishes a one-click CSV export across every lodge on the platform. That is the product claim. This page will not invent the columns of a return, or a UGLE filing rule, or a Provincial by-law. If your Province already has a format, the export is raw material for that format. It is not a ruling about what the format must be.

One click only works if the lodges kept the year. A CSV of empty attendance and guessed dues is faster fiction. The pilot should include at least one lodge that will complete a real quarter before you show council a demo file.

Provincial officers need a place to stand that is not "log in as the Secretary of Lodge X". LodgePay publishes an operator console, province-wide dashboards, lodge context switching, bulk lodge operations, and health-style portfolio signals. Those are the public words. We will not invent a surveillance suite behind them.

Context switching means the officer chooses a lodge and works inside that lodge's home. Dashboards mean a portfolio view of which lodges are live, not a merged brother graph. Bulk operations mean you can do the same administrative step more than once without merging the underlying records.

Permissions still matter. A Provincial user who can see every welfare case in every lodge is a design failure, not a feature. Keep discretion where the Almoner article left it: cases belong to the lodge that opened them.

Migration planning is included on the published Province tier. That does not mean a promise to swallow every historic spreadsheet on a Saturday. It means you plan which records must move for the pilot (sitting members, officers, a dues year, a meeting calendar) and which history can wait.

Officer training is the actual adoption work. A Secretary who has always mailed a PDF needs a week with send history, not a slide about strategy. A Treasurer who has always used a cash book needs a bank import on a real CSV. Train the collars that will run the next meeting, not a room of people who will never log in.

Do not require lodges to pause their year. Run the old summons in parallel for one meeting if you must. Cut over when the lodge can see its own members, not when the Province is tired of waiting.

It is not a merged brother database. It is not a Provincial membership warehouse that lodges must feed. It is not a requirement that every lodge abandon a tool that already does one job well.

It is not an invented UGLE programme. If your Province has its own digital policy, follow that policy. This page is how to roll out lodge operations on a platform that keeps homes separate. It is not a ruling you can wave at a lodge.

It is not a reason to put every Almoner case on a Provincial desk. Oversight is portfolio health and annual returns, not pastoral detail.

The Working Tools is a real secretary operating system. On 25 August 2026 its pricing page listed £5 a month per lodge, £3 a month for each extra lodge, and a 30-day trial. Extra lodges at £3 is a serious number if the brief is a cheap digital secretary desk in many buildings. It is not, on the pages we checked, a Provincial operator console with one-click returns across a portfolio.

Lodge Master 5, Lodgical, and Lodge Manager remain lodge-level admin tools on the public facts already used in the summons article (meetings, summons, dining, and Lodge Manager's £50 or £70 a year). We will not invent a Province tier for them.

Some Provinces will keep a cheap secretary OS in lodges that only wanted minutes, and put money, Gift Aid, and returns on a different desk. If you try that, name the source of truth for each job. Two systems that both think they own the member list is how the CSV lies.

Once the Province owns the job (separate homes, a pilot, a definition of proved), LodgePay is the platform: operator console, dashboards, lodge context switching, shared rollout support, and annual returns as a one-click CSV. Each lodge keeps separate records, branding, and site.

Province pricing is published from £2k a month plus £35 per lodge, typically £4,500 a month, as on the pricing page. The same page lists Essentials at £149 a month billed annually for a single lodge, Complete at £229, and Group at £349 for two to six lodges. Group is not a Province. Do not quote the typical Provincial figure for a hall of three lodges.

Talk to the team about a pilot. The published path already says Provincial pricing depends on lodge count and rollout scope. This article will not invent a discount table.

That is the end of the pitch. If the Province cannot name three lodges that will run a real quarter, buying a console will not produce a return.