Parish share and parish returns: collecting the same numbers without re-keying

Most dioceses do not set out to buy software. They set out to stop losing things — a faculty application that stalled because nobody owned the next step, a parsonage gas certificate that lapsed because the reminder lived in one person's calendar, a parish return that had to be re-keyed three times before it reached the annual accounts. By the time a diocese is actively comparing diocesan management software, the spreadsheet estate has usually already failed at least once in a way that cost money or credibility.

This is a buyer's checklist written for the people who actually carry that risk: the diocesan secretary, the property officer, the registrar, the head of finance. It is deliberately not a feature list. Feature lists are how vendors win demos and lose implementations.

1. Does it model a diocese, or a generic CRM?

A diocese is not a sales pipeline with the labels changed. It has parishes, benefices, deaneries, archdeaconries and the diocese itself, and almost every record — a person, a property, a payment, a permission — hangs off one of those levels. Ask any vendor to show you how a single curate who serves two parishes in a united benefice appears in their system. If the answer involves duplicate records or a free-text note, the data model is wrong and every report built on it will eventually disagree with itself.

2. Property and people in one record, not two systems

The expensive failures in a diocese nearly always sit at the seam between people and property. The incumbent moves; the parsonage compliance file does not move with them. The glebe tenant changes; the rent review schedule stays attached to the old name. If property lives in one system and people in another, somebody spends Monday mornings reconciling them by hand — and that somebody is the single point of failure the day they are off sick. One record, one place is not a slogan here; it is the difference between a clean audit and a frantic week.

3. Compliance cycles that are held per property

Clergy housing carries the same statutory load as any let portfolio: gas safety, EICR, EPC, fire risk, legionella, and the quinquennial inspection on top. A diocese with eighty parsonages is running several hundred overlapping renewal clocks. The system has to hold those cycles per property, remind you well ahead of each renewal, escalate when one slips, and produce the evidence chain on demand. We wrote up the full statutory picture in eight property compliance cycles every UK landlord must track — every one of them applies to a parsonage.

4. Parishes can see their own data

The diocese does not generate most of its own data; the parishes do. Returns, electoral roll numbers, contact changes, fabric reports. If the only way that data gets in is a treasurer emailing a spreadsheet to the office, you have re-keying, lag and version drift baked in from day one. A portal where a parish edits its own record — and the diocese sees the change immediately, against one shared record — removes an entire class of error before it happens.

5. It reports without an export

The test of a real system is whether the diocesan secretary can answer a Bishop's Council question in the meeting, not after it. “How many parsonages are out of EPC compliance?” should be a dashboard, not a CSV export pasted into a pivot table. If the demo answers every reporting question by exporting to Excel, you are buying a database with a nice front end, not a management system. We are blunt about why that matters in why dashboards lie.

6. UK-owned, UK-hosted, and yours

Dioceses hold sensitive data about clergy, safeguarding context, finances and vulnerable people. Where that data physically sits, who can be compelled to hand it over, and what happens to it if the vendor is acquired are governance questions, not IT footnotes. Ask where the data is hosted, under whose jurisdiction, and whether you can get a full export of everything on the day you ask. A vendor that hesitates on the export question is telling you something.

7. The implementation is a migration, not a switch-on

The risk in any diocesan system is never the software on launch day; it is the eighteen years of history living in spreadsheets, Access databases and filing cabinets that has to come across without losing the bits that worked. Ask how migration is handled, who validates the data, and what the rollback looks like if a parish's figures come across wrong. We have written separately about migrating off Excel without losing the bits that worked, because that is where these projects actually succeed or fail.

A short scoring sheet

If you are comparing options, score each one out of five on exactly these:

• Does the data model understand parishes, benefices and deaneries natively?
• Are property and people the same record, or two systems bridged by hand?
• Are compliance cycles held per property, with reminders and escalation?
• Can a parish maintain its own data through a portal?
• Can you answer a governance question without an export?
• Is the data UK-hosted, and can you export all of it on demand?
• Is migration a planned, validated project with a rollback?

Anything scoring well below the line on the first three is a CRM wearing a cassock, and it will quietly hand the work back to your spreadsheets within a year.

The system we build for dioceses is organised exactly the way a diocese is — parishes, property and people on one record, with the compliance clocks and the parish portal sharing it. If you want to see it run against your own data rather than a demo dataset, here is what it covers, and you can talk to us directly.