What changed
- Coordination time
- Days of phone calls between three partiesHours 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 budgetMet 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
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.
What I took from it
The best multi-stakeholder design does not try to make everyone happy with one interface. It gives each group the right level of control and visibility. Funeral homes got speed. Priests got control. Parish assistants got oversight.
The tension between those needs is the actual design work, and on this project a lot of that translation was possible because the customer had already done the synthesis themselves. They knew their community: bereaved families, busy funeral directors, stretched parish offices. They handed us the goals. My job was the translation and the validation, not the discovery.
The other lesson is about leverage, and it's where the product role mattered as much as the design role. The most consequential move on this project was the scoping choice rather than any design choice. Once build-vs-buy was off the table (the custom-form requirement ruled out third-party tools), the real fork was between a standalone module and an integrated platform feature. The standalone module would have shipped funeral booking on time, but it would have been one more thing for parishes to learn alongside the platform. The integrated path was deeper and harder: build the booking capability into the calendar and form builder that parishes already used, so it would compose with whatever came after. That choice cost more upfront and paid back across the rest of the product.
Read the full case study
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.
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.
Three groups, three different needs
One system had to serve three groups, and they did not want the same thing.
Funeral homes — Bestatter
Book several funerals a week. They needed to see what was free and get a confirmed answer quickly.
Parish assistants — Assistenzen
Sat in the middle. They answered the funeral home, knew who was on call, and covered for vacancies. They needed a clear view of the whole rota.
Priests — Pfarrpersonen
Needed predictability and a say over their own schedule. The system had to ask them, not assign them.
How I approached it
I owned this initiative end-to-end as both product manager and designer. The dual role mattered: scoping the work as a platform capability (not a funeral-only feature) is a product decision; keeping three stakeholder groups happy on one surface is a design decision. Running both meant the two decisions could reinforce each other instead of pulling against each other.
Build-vs-buy was the first question, and a short one
Competitive analysis ran in parallel with the first customer conversations, and the build-vs-buy question got dismissed quickly. What parishes actually needed, most decisively, a custom intake form per parish (deceased details, funeral type, cemetery section, sterbeurkunde delivery), wasn't something a third-party booking vendor or library was set up to deliver. (Calendly, the obvious reference point, doesn't offer white-labeling at all; its booking form is fixed; the form-builder is a separate product.) The harder question was the next one: build a standalone booking module, or build into the existing platform? A standalone module was the faster path and was floated internally. But ChurchDesk's strategic value is in features that compose with each other, not in module count. So the brief was set: 'a booking capability built into the platform, shipped first as funeral booking.' Everything downstream came from that decision.
Started from the customer's synthesis, validated with stakeholders
The launch customer (Evangelische Kirche von Kurhessen-Waldeck) had already run their own design-thinking workshop and arrived with a vision sheet that named the three stakeholder groups and the goals per group. I started from their synthesis rather than running primary research from scratch. Throughout the project I had extensive calls with the customer's project lead, plus validation conversations with pastors and funeral directors as the first concepts came together. The harder synthesis work belonged to the customer; my work was translation and refinement.
Designed for control, not just speed
Funeral homes get speed. Priests get control. I showed funeral homes only the times that were genuinely free. And I framed every booking as a request the priest confirms, so no one is scheduled without agreeing first.
Extended the existing platform: the right option, not the cheap one
ChurchDesk already had a calendar with people and resources attached to events, and a form builder used everywhere else in the product. Extending both was harder than building a standalone booking module would have been, and a standalone module was the option floated internally as the faster path. But ChurchDesk's magic moments come from deeply integrated features, not from a longer feature list. A separate booking surface would have shipped on time and looked like progress, but it would have been one more thing parishes had to learn alongside the rest of the platform. The integrated approach took more work; it also produced a feature that actually felt like part of the product.
Designed in Figma with my designer; engineering built quickly
I worked in Figma with the designer on my team to develop and prototype the screens, across web (the parish-facing admin and the funeral home's booking pages) and mobile (the priest's calendar on the go). The two engineers on the project built the implementations in React for web and React Native for mobile; they wrote the code, not me. The collaboration was tight throughout the two-month build, with daily contact and frequent handoffs, but the division of labor was honest: design in Figma, build in code.
Why it stays simple when the underneath is complex
Three design decisions did the work of keeping the surface clean. None of them are visible to a funeral home, they're the reason the funeral home only ever sees green time slots.
On-call lives in the priest's calendar
This is the design choice that most distinguishes the system from Calendly-style booking tools. In Calendly, you set your availability inside a separate booking-page settings area. Here, a priest sets their on-call rotation as recurring events in the same ChurchDesk calendar where they already plan their week. The calendar is where priests live, so I extended that surface instead of asking them to learn a new one. Recurring events handle the rota; vacation cover slots into the same view.
One event covers several cemeteries
In the pilot region, one priest's on-call shift covers multiple cemeteries at once. Setting each one separately would be six entries a week of friction. The availability model lets a single recurring event apply across the relevant cemeteries.
Booking form is a parish-built form
ChurchDesk's existing form builder is reused inside the booking flow. Funeral homes don't get a generic booking page with name/email/date fields, they answer the questions the parish actually needs (deceased details, funeral type, cemetery section, sterbeurkunde delivery). Calendly cannot do this; its booking form is fixed and the form-builder is a separate product. Reusing the form builder meant churches with idiosyncratic intake questions could ship without engineering work.
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.
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.