The questions diocesan
secretaries actually ask.

You still do — the platform sits on top of M365, not next to it. Calls run through Teams, email runs through Microsoft Graph, AI runs through Azure OpenAI, single sign-on runs through Azure AD.

We're not asking you to swap vendors; we're asking your existing M365 estate to do diocesan work.

It's the system that lets parishes stop learning systems. Today they juggle a CofE CMS login, an emailed Word document, a paper Form C and three different inboxes for three different teams.

The portal is one login. Two-factor email-based — no passwords to memorise. And it's built around what parishes already do, not what the back-office wants from them.

GDPR is a feature, not a worry. Subject Access Requests are a workflow with a tracked deadline. Right-to-erasure and right-to-correction are typed and tracked the same way. Retention is policy-driven. The audit log shows every decision.

PII is redacted from any AI input before it leaves the diocese. Inspection-ready, not patched-on.

Yes — and you can put your data in. Every entity has a CSV/XLSX export. The reporting layer can produce extracts on a schedule.

The data-mart roadmap exposes a read-only OData feed for Power BI or any third-party tool. There is no lock-in by design.

Diocesan work is church-shaped, not business-shaped. The platform was built around the diocese-episcopal-area-archdeaconry-deanery-benefice-parish-church hierarchy and the canonical structures (Common Tenure, Mission and Pastoral Measure, Form C, A of E, SfM/RoPF/EFT) — not the customer-account-opportunity model bent into a diocesan shape.

You'll spend zero time mapping a generic CRM onto canon law.

Two paths. One: embed your existing Power BI tiles in the platform's dashboards so they're surfaced where staff already work. Two: expose the platform's data through an OData feed so your Power BI dashboards refresh automatically.

Most dioceses do both — quick wins via embedding, strategic answer via the feed.

You take the data with you. The schema is documented, every table is exportable, and the source code can be transferred under the existing licensing agreement.

We've designed for portability because diocesan trust is earned over years, not signatures.

Rollout is incremental: we light teams up one at a time rather than waiting for a big-bang. A new diocese typically sees first-team production use in a quarter, full rollout within a year.

The platform is already built — your project is configuration, data migration and change management, not software construction. See the phase-by-phase implementation story →

The platform is Laravel and Nova — mainstream PHP technology used by many thousands of organisations, with a deep bench of capable developers. There is no proprietary runtime.

If you wanted to run it yourself or hire a different vendor to maintain it, you could.

The platform is licensed per diocese rather than per user — encouraging adoption rather than penalising it.

Total cost of ownership is dominated by Microsoft licences you already pay for, not by the platform itself. We'll model your specific case in a one-page commercial summary.

Usually several systems at once: the national Church of England CMS for people and places, finance software for the DBF, and spreadsheets for everything in between.

A diocesan management system replaces that middle layer with one record. Ours is the Diocese Management System — 25+ operational areas covering engagement, safeguarding, clergy deployment, buildings, finance and the statutory duties, running on the Microsoft 365 estate you already have.

It is the system a diocese runs itself on, as distinct from the national systems it reports into. One record of every person, parish, church and post, worked in by the safeguarding team, the archdeacons, the finance office and the programme team alike.

The test of a good one is simple: do two teams looking at the same parish see the same numbers?

Yes — a ledger per parish and year (requested, paid, outstanding), statements parishes can see for themselves in the portal, and forecasting for the Board of Finance. The annual Return of Parish Finance is imported rather than re-keyed.

Parochial fees are handled separately: quarterly fee returns with the DBF and PCC shares split per fee row. See finance →

Yes. Deployment is modelled against the establishment register — the posts the diocese actually funds — rather than a headcount, and projected ten years forward on assumptions you set and can see: retirement age, ordination age, curacy completion, replacement rate.

Individual posts can be re-modelled (change an FTE, date a departure, add a post that does not exist yet), and proposals freeze the evidence they were discussed on. Projections are labelled as projections; where a figure rests on an estimate, the screen says so. See workforce planning →

This is the gap most diocesan software leaves. We track 19 statutory areas with deadlines computed from the records themselves — parochial fees, electoral roll and APCM, synod elections, the Patronage Measure timers (including deemed approval where a patron does not reply), licences and PTO, Statements of Particulars, conduct under CDM 2003 or CCM 2026, DAC and the quinquennial cycle, closures, glebe, the registers, SIAMS and the diocesan filing calendar.

None of these modules sends email. Deadlines surface as lists and reports a person chooses to act on. See statutory compliance →

Your own installation, your own data — there is no shared tenancy.

The platform is twelve installable domain packages, so you take the areas you want. Table names and vocabularies — programme tiers, urgency scales, ministry types — are configuration rather than code, so a different legacy schema or different local terminology is a deployment, not a rewrite. There is no reference-customer code path that later dioceses inherit and pay to work around.