When booking a pastor isn't simple
Booking a pastor 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 pastor meant a chain of phone calls. A funeral home called the parish office. The parish office checked who was on call, then called the pastor. The pastor checked the cemetery's hours and their own calendar, then called back. Every round of calls happened while a family waited.
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. Pastors 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 pastor'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 pastor 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.
The whole filtering chain in one picture. The pastor enters availability once, as an event in the calendar they already use — everything else on that calendar, the cemetery's hours, and the booking option's own prep and follow-up time cut themselves out, and what survives lands on the booking option's start grid: hourly for funerals, 15-minute increments for appointments and video calls. A slot only reaches the funeral home if every constraint resolves true; every booking is still a request the pastor confirms. Diagram source: treppmanndesignportfolio video/churchdesk-booking-system-glm/diagram-src/availability-pipeline.html.
Read the reasoning behind this decision
That filtering logic isn't special-cased for pastors. A booking option can carry both opening hours and one or more resources, a room, or a physical asset like a projector or a barbecue set, and every resource lives on the same calendar as the people. A time only ever surfaces on the booking page if every person and every resource attached to that option is free at once. It's one availability-resolution mechanism, reused for people and equipment alike, which is what let the same system carry room rentals and equipment bookings without a second engine being built for them.
Every booking is a request, not an automatic booking. The pastor confirms or declines. That single decision is what kept the system from feeling like pastors were being booked over their heads. Bookings also carried a 48-hour minimum lead time, so no one was asked to confirm a slot that was logistically impossible to fulfil — control that holds before the pastor ever has to say no.
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.
Coordination fell from days to hours
Coordination dropped from days to hours. The 90% acceptance rate came directly from the filtering: if a funeral home could see a time, the pastor 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, weddings and youth-camp sign-ups as well, each reusing the same availability model and form builder, including the required follow-up form for the document each use case actually needs
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?