Funeral Home Software Problems: The 7 That Cost You Calls and Hours, and How to Avoid Them

Why does a funeral home project get scoped as replacing the case system?

The commonest and most expensive scoping error in this trade is deciding to replace SRS Computing, Passare or FDMS Plus outright. It feels like the clean answer, because the frustration is real and the case system is the thing everyone touches. It is almost always the wrong shape of project.

The reason is where the pain actually sits. Directors are not losing hours because a case record is badly designed. They are losing hours in the gaps between systems: the same name typed into a certificate worksheet, the state electronic death registration system, a permit, an obituary and an insurance assignment. They are losing cases because nothing answers the phone at two in the morning. They are losing preneed opportunities because nothing reads the archive. None of that is fixed by moving the case record somewhere newer, and a replacement project spends most of its budget rebuilding the part that already works.

It happens so often because replacement is easier to describe than integration. "Get us off the old system" is a sentence a whole leadership team can agree on in one meeting. "Automate the six things that happen between the arrangement conference and the filing" takes an afternoon with a director and a legal pad.

The fix is to scope from the day, not from the system. Sit with an arranger for one full case, from first call to filed certificate, and write down every place data is entered twice, every wait for a signature, and every point where the family is asked something you already know. Build against that list. In most homes the right answer is to keep the case system you trust and layer automation around it, and replacement only earns its cost when a multi location group has to unify genuinely incompatible legacy installs anyway.

What goes wrong when you migrate case history and preneed contracts?

Legacy funeral systems vary enormously in how cleanly they let go of data, and the parts that migrate worst are the parts that matter most later.

At need case records usually come across acceptably, because they are structured. Preneed contracts frequently do not. They carry trust or insurance funding details, beneficiary information, growth or interest terms, and a payment history that may sit in a different module or a different product entirely. A migration that moves the contract header and drops the payment schedule looks successful on the day and produces a serious problem the first time a preneed matures.

The second casualty is anything held as free text. Arrangement notes, family instructions, veteran details, cemetery deed references and the small annotations directors leave for each other tend to live in memo fields with no consistent structure. They migrate as a wall of text if they migrate at all, and the family relationship knowledge inside them is what a good director actually uses at the second conference.

The third is documents. Scanned certificates, signed contracts and authorisations are often stored outside the database with filenames that only make sense in the old interface.

The fix is a migration test on a copy of your real data before you commit a penny. Not a sample, not a demo dataset, your actual archive. You should be able to open ten specific old cases and five preneed contracts and confirm what survived, including the payment schedules and the notes. Any developer who will not run that test before contract has not migrated one of these systems before, and you will discover what was lost after the old install has been switched off.

Why do the EDRS, insurance and obituary integrations break after launch?

The three integrations that carry a funeral home's paperwork are the three most likely to drift within a year, and each fails differently.

State electronic death registration systems change on their own schedule, are different in every state, and rarely offer a documented interface for a business of your size. Many builds automate the filing by driving the portal, which works well and then breaks the morning the state redesigns a screen. It usually breaks silently, so the first sign is a rejected filing two days later and a family asking why the certified copies have not arrived.

Insurance assignment processors such as C&J Financial, Homesteaders and Global Atlantic Forethought each have their own document expectations, and they update forms without consulting vendors. An assignment submitted in a stale format is not rejected loudly, it just sits, and your cash flow finds out before your software does.

Obituary outlets are the third: newspaper submission methods change, deadlines move, and a local paper's portal is nobody's priority to maintain.

The fix is monitored integrations with an owner and a budget. Every automated filing needs a confirmation check that raises an alert when the expected acknowledgement does not arrive within a set window, plus a clear manual fallback a director can use the same morning without waiting for a developer. Agree in the contract who fixes a broken state portal connector in year two and how fast, because a system that files by itself until it quietly stops is worse than one that never claimed to.

What happens when the Funeral Rule and tone are treated as an afterthought?

Two things in this trade will damage a home badly if the software gets them wrong, and neither shows up on a feature list.

The first is price disclosure. The FTC Funeral Rule and your General Price List govern anything that quotes a price to a family, which includes a web page, a digital arrangement portal and an automated phone agent that answers what a cremation costs. A build that lets a quote reach a family without the disclosures the rule requires has created a compliance exposure and given a director something new to police, which is the opposite of what you bought it for.

The second is tone, and it is not a soft concern. A phone agent that sounds like a sales bot to a woman whose husband died an hour ago does more damage in ninety seconds than any efficiency gain repays. The same applies to automated follow up: a cheerful reminder sent to a family who has not yet held the service reads as a debt chase.

The fix is to make a director the approver of every family facing word. Every phone script, message template, portal screen and drafted obituary should be reviewed and signed off by someone who has sat across the table at an arrangement conference, and the system should route to a human the instant a caller asks for one. On the Funeral Rule, put the disclosure logic in the code path that produces any price rather than in a template someone can edit later. Ask a prospective developer to explain the rule and the General Price List back to you. If they treat your home like a plumbing dispatch board, walk.

Should you build custom or configure what you already own?

If you run a single location at modest volume, your arrangement, obituary and accounting flow through Passare, SRS Computing or Frazer without pain, and your directors are not re keying the same case into four places, do not build. Configure what you have, tighten the parts that annoy you, and spend the money on a preneed counsellor or a better answering arrangement. Buying beats building when the tool already fits, and we have told homes exactly that.

Where the packaged tools genuinely stop is not storage. Passare, SRS and FDMS hold a case competently. They do not answer a two in the morning first call and open the case with the address already recorded. They do not chase an attending physician for an EDRS signature. They do not watch a stalled arrangement or a preneed lead from last month's seminar. And they do not read ten years of archive to find the surviving spouse who is now seventy eight.

Build, or more accurately layer, when two or more of these are true. You run multiple locations, or you are a group consolidating legacy systems that do not talk. Your directors are typing the same case into four places. Your data is trapped in an old install nobody can export cleanly. Or you want a capability the case tool will never offer, such as real after hours intake, a family facing arrangement portal, or automation working against your history.

How do hidden costs get into the quote?

Four things reliably arrive late in funeral home projects. State integrations counted once when you operate across three states, because each state's electronic death registration system is a separate piece of work. Insurance assignment processors, priced as a category when each processor has its own format. Telephony, because a voice agent that answers, qualifies and books cleanly is a different discipline and a different cost base from a web form. And migration, where the preneed contracts and the memo fields turn out to be the real job.

The fifth is tone review time. Every family facing script and template needs director hours to write and approve, and those hours are rarely in anyone's estimate. They are also not optional.

The fix is to make the proposal specific. Which states, named. Which assignment processors, named. Whether telephony is included and what happens to a call the agent cannot handle. Whether the migration test on your real data happens before contract or after. And how many director review hours are budgeted for family facing content. A developer who answers those five has understood the trade.

What separates a funeral home build that works from one that fails?

The builds that work start where the loss is largest and most invisible, which is intake. Answer every call at any hour, capture the essentials gently, open the case with the data already in it, and page the correct on call director and removal team with the address and access notes. Everything else in the programme is easier to justify once that is running, because it produces cases rather than saving minutes.

They then attack re keying rather than replacing records. Intake once at the arrangement conference and let the system populate the certificate worksheet, the EDRS submission, the permit, a first draft obituary and the insurance assignment from that single entry, with validation catching the missing field before the state rejects it. That is where the two to three hours a day actually goes, and it is recoverable without touching your case system.

They phase visibly. A working piece in production every few weeks, starting with the piece a director notices, rather than a single launch day months out. Homes that accept a big bang delivery in this trade almost always go live in a busy month and lose confidence in the first week.

And they settle ownership before kickoff. The source code, the documentation, the cloud accounts and an unrestricted export of your data, in writing. A system holding a decade of family history and preneed obligations should never live in an account you cannot open, and a developer who resists that is selling you a subscription with extra steps.