When booking a priest isn't simple

Head of Platform and Design

1 designer + engineering team, Berlin

Booking a priest for a funeral looks like picking a date. Underneath sit rotating on-call rotas, cemetery opening hours, and a grieving family waiting for an answer. ChurchDesk asked me to run this in a dual PM and design role, owning the build-vs-buy and standalone-vs-integrated decisions, on a system that would keep the surface simple, and become something the rest of the platform could build on, not just funeral booking.

The problem was the phone

Before this system, booking a priest meant a chain of phone calls. A funeral home called the parish office. The parish office checked who was on call, then called the priest. The priest checked the cemetery's hours and their own calendar, then called back. Every round of calls happened while a family waited.

A flipchart sheet from a design-thinking workshop with the church customer, handwritten goals per stakeholder: funeral directors, parish assistants, priests
Fig. 01

The vision sheet from the church's own design-thinking session. The headline ‘Das Herumtelefonieren hat ein Ende’, ‘no more phoning around’, is the customer's phrase, not mine. So is the goal in red, ‘Damit Angehörige planen können’: so that bereaved families can plan.

Read the reasoning behind this decision

The scheduling underneath is genuinely hard. Priests rotate on call, but many keep standing commitments to particular cemeteries. They plan availability about six weeks ahead. Each cemetery has its own opening hours. The first customer, the Evangelische Kirche von Kurhessen-Waldeck, ran the pilot in their Kurhessische Riviera cooperation region, where one priest's on-call rota touches several cemeteries at once.

What the customer brought to us was rare and useful: they had already run their own design-thinking workshop and arrived with a vision sheet that named the three stakeholder groups and the goals for each. I started from their synthesis rather than running primary research from scratch.

Layered on top was a ChurchDesk business goal that the customer didn't ask for and didn't need to: build this so the platform can reuse it. Funeral booking would be the launch use case; the underlying capability had to be general enough to carry room rentals, equipment, counseling appointments, anything resource-and-availability-shaped.

The constraints were tight: €20,000 of client funding and two months to development release. Both were already fixed, the deal was closed before I joined ChurchDesk, and I was brought in to lead the delivery. The internal expectation was a standalone add-on module. What I delivered instead was a booking capability embedded in the platform: general enough to carry the use cases customers asked for most, and a stronger answer on funerals specifically than the add-on would have been.

How the system fits together

The design rests on one composition: a priest sets their availability in the calendar, the cemetery's opening hours and any standing commitments are layered on, and what remains is what the funeral home sees. A slot only reaches the funeral home if every constraint resolves true.

Every booking is a request, not an automatic booking. The priest confirms or declines. That single decision is what kept the system from feeling like priests were being booked over their heads.

The availability model was deliberately general. The business goal was never a funeral-booking feature in isolation but a booking capability that could carry funeral booking as its launch use case and then expand across the platform: room rentals, equipment reservations, counseling appointments, anything resource-and-availability-shaped. Funeral booking shipped first; the deeper capability was what made the investment pay back.

What changed

Coordination dropped from days to hours. The 90% acceptance rate came directly from the filtering: if a funeral home could see a time, the priest could take it. The longer-term outcome, the one that justified the investment to the business, was the availability model itself: built once for funeral booking, reusable across the platform without redesign. The funeral feature was the visible deliverable; the platform-wide capability behind it was the strategic one.

Coordination time
Days of phone calls between three parties Hours to arrange a funeral booking: around 70% less time
Booking acceptance rate
90%, because funeral homes only ever saw times that were genuinely free
Delivery
Two-month deadline, €20,000 budget Met both
Adoption
Became a core ChurchDesk feature. The launch customer needed funerals bookable for and by 20+ cemeteries, and the module then shipped to the whole customer base for room rentals, baptisms and weddings as well

Want to hear more?

  • Curious why turning down the faster, standalone-module path was the right call, or how a funeral-booking tool built in two months ended up running weddings, baptisms and room rentals for ChurchDesk's whole customer base?
Get in touch