Septic Service Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the CRM (Customer Relationship Management) rebuild get scoped when the money is somewhere else?

Because the software is what the owner looks at, so the software is what gets blamed. Dispatch is a whiteboard, the office is retyping between two systems, and the natural conclusion is that the whole platform needs replacing. That is a twelve month project with a big number on it, and at the end the trucks run exactly the same routes they ran before.

The money in this business is in three places and none of them is the invoice screen. It is in truck hours lost to disposal detours and dead miles. It is in the four and five figure repair estimates, the drainfield replacements and tank installs, that sit open for a week because the technician who wrote them is on a truck rather than on a phone. And it is in the job history already sitting in your system, where tanks pumped three to five years ago are due again now and grease traps on a required service interval have quietly slipped past it.

The build that works layers over the system you already run rather than replacing it. Keep ServiceCore or Jobber or ServiceTitan doing the scheduling and invoicing they do competently, and add the parts they were never built for: manifests generated at the tank, disposal aware routing, an estimate follow up sequence that persists, and a reminder engine that mines your own job history. That sequencing matters because it produces a paid outcome in weeks rather than a platform in a year, and because it lets you judge the developer before you commit the rest.

What goes wrong when you migrate customers, tanks and job history?

The customer list moves easily. Everything that makes the data valuable does not.

The first problem is that the tank is not in your system as a thing. It is described inside job notes: a fifteen hundred gallon concrete tank with the lid two feet down on the north side, riser fitted in 2019, baffle needs replacing. That is the asset your entire reminder programme depends on, and it exists as prose. Extracting tanks from job notes into structured records with size, type, location, last pumped date and known defects is the single highest value piece of migration work, and it needs a human reviewing the output because a wrong tank size sends the wrong truck.

The second is duplicates. The same property appears three times because a homeowner sold, because somebody typed the road name differently, and because a realtor booked an inspection under their own name. Merge on address rather than on customer name, keep the service history against the property, and use a review queue rather than a rule, since merging two properties that were not the same one puts a pumping reminder through the wrong letterbox.

The third is open estimates. These are the most valuable records you own and usually the dirtiest, with amounts in note fields, no expiry, and a status of open going back four years. Sort them by value and age, confirm which are genuinely live, and treat the rest as a marketing list rather than a pipeline.

Why do the CRM, telematics and payment integrations break after launch?

If you are layering rather than replacing, the integration is the product, so it deserves scrutiny.

The CRM interface is the first thing to check, and check the commercial terms rather than the technology. Access is often restricted to a higher subscription tier, rate limited, or missing the specific record you need, and none of that appears until somebody tries. Get the required endpoints and the tier confirmed in writing. The quiet failure to design against is a sync that stops while both screens keep showing yesterday's data, so stamp every synchronised record with the time it arrived.

Telematics is the second. Location feeds are easy to read and hard to use well, because a stationary truck at a treatment plant and a stationary truck at a diner look identical to a coordinate. Geofence the disposal sites and the yard and treat everything else as unknown. The value is knowing when a truck is near capacity and near a disposal site, not surveillance.

Payment is the third, and the failure is unglamorous. Card fees, deposits taken at the door on a repair job, refunds and partial payments all have to reconcile daily against whatever your accounting system holds. Build that reconciliation report before you take the first payment through the new path.

What happens when manifest and disposal compliance is not covered?

Every pump out generates paper: gallons in, tank condition, disposal site, gallons offloaded, the trip ticket the plant keeps. On a heavy day a driver writes manifests on the dash between stops, and the compliance record ends up living outside the software entirely, in a binder.

Two costs follow. The first is the audit afternoon, or several of them, when the health department asks for last quarter's septage disposal records and somebody goes to the filing cabinet. The second is subtler and larger: because the manifest is paper, nobody can query gallons pumped against gallons offloaded, which means an imbalance that should prompt a question about a truck, a meter or a driver goes unnoticed for months.

The fix is to make the manifest a by product of the work. The driver logs gallons and tank condition on a tablet at the tank, the document generates in the exact format your county or state requires, and the disposal event is recorded when the truck offloads, with location and time. Then the whole disposal history is one query when an inspector calls, and the gallons balance is a report rather than a hope. Two details decide whether this survives contact with a real driver: it has to work with no signal in a rural yard and sync later, and it has to be usable with gloves on in under a minute, because anything slower gets filled in later from memory and you are back to a binder with extra steps.

Should you build custom or configure what you already own?

If you run one or two trucks with simple routes and manageable manifests, and what you mainly need is scheduling and invoicing, stay on Jobber or Housecall Pro and spend the money on equipment. ServiceCore is genuinely good at septic specific scheduling and the disposal basics, and if you are not using those parts because nobody set them up, a week with their implementation team costs almost nothing and may end the conversation. ServiceTitan is a reasonable answer if you are a large multi trade shop that needs the full enterprise stack and has someone to administer it.

Check the configuration question honestly before you price anything. A great many operators describe a system as unable to do something it can do, because the person who set it up left and nothing has been revisited in three years.

Build, or more accurately build around, when two or more of these are true. You run three or more trucks and dispatch is a person plus a whiteboard. Your manifests are on paper and each audit costs an afternoon. You are losing after hours emergency calls to voicemail while a competitor answers. You have years of job history nobody markets against, with tanks overdue and grease traps past their required interval. Or your per seat subscription keeps rising while the software still will not do the one thing that would give each truck back an hour a day.

How do hidden costs get into the quote?

Manifest formats first. They vary by disposal jurisdiction, and an operator working across three counties needs three formats with three sets of rules, each of which can change. Ask whether format maintenance is in the quote or becomes your problem after handover, because that answer decides whether you bought a project or an obligation.

Second, the CRM interface tier. If pulling your own data requires a subscription upgrade, that is a recurring cost attached to the build and it belongs in the business case rather than in a surprise invoice.

Third, hardware and connectivity. Tablets, mounts, chargers and rugged cases across a fleet, plus data plans, plus the reality that rural service areas have holes and everything must work offline. Fourth, the after hours voice agent, which needs a real script covering emergency triage, your pricing boundaries and escalation to a human, and which needs revisiting after the first month of real calls.

Fifth, grease trap regulatory schedules if you serve food premises, since required service intervals and reporting differ from residential septage. Sixth, multi yard operations, where routing, disposal site assignment and inventory all gain a dimension.

What separates a build that works from one that fails here?

The projects that pay for themselves start with the revenue that already exists. Mine the job history for tanks due on their pumping cycle and grease traps past their interval, and chase the open estimates over your value threshold with a persistent sequence rather than a single text. Both use data you already own, both produce booked jobs within weeks, and both give you a number to point at when you decide whether to fund the rest. The projects that fail start with a platform rebuild and ask the owner to wait a year for a result.

Second, design the driver experience for a person with gloves on and one hand free, standing next to an open tank. Watch a real driver use it on a real route in week four rather than at acceptance, and count the taps. Anything that takes longer than the paper form it replaced will be filled in later from memory, and then the data you are building everything else on is fiction.

Third, keep the boundary with your existing system explicit and one directional wherever you can. Two systems that both believe they own the schedule is a worse outcome than the whiteboard, because the day they disagree nobody trusts either.

Finally, settle ownership before kickoff: the repository, the cloud accounts, the customer and tank records, and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. Ask specifically what a full export looks like and how long it takes, because that number is your switching cost for as long as you own the business.