Water Treatment Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a dealer build get scoped as another scheduler?

Ask an owner what hurts and they describe a dispatch problem, because the visible chaos is the whiteboard at seven in the morning. So the brief comes back as scheduling and dispatch, the demos all look like calendars, and the build gets scoped around moving jobs between techs. What that build cannot do, six months and a lot of money later, is tell you that the Hendersons are four months overdue for carbon media service, because the only place that install date ever lived was a paid invoice from 2021.

The money in a water treatment dealership is not in the schedule. It is in the install base, which is an annuity you are only partly collecting. Every softener, filter bank and reverse osmosis unit you have installed carries a service clock, and the value of software here is turning that clock into a work order and an invoice without a human remembering. A scheduler with no equipment registry underneath cannot do that no matter how good the calendar looks.

The fix is a scope boundary written before design. Phase one owns the equipment registry, the service rules engine that computes the next due date per unit, automatic work order creation, and billing on completion. Dispatch, routing and the customer portal are phase two. If a feature does not either generate a chargeable event or stop one from being missed, it waits. Dealers who invert this order end up with a nicer calendar and the same Friday afternoon reconciliation.

What goes wrong migrating install history out of Wintac and QuickBooks?

Your install base is spread across a system being sunset, a stack of paper, and a decade of accounting records where the install is a line item on a paid invoice. None of those hold what the new system needs, which is model, media type, install date, the water test at time of sale, and the household served.

The specific traps are consistent. Equipment is recorded as a product sold rather than an asset installed, so there is no serial, no location within the house, and no way to tell a replacement from an addition. Addresses drift, because the customer who moved in 2019 carries the old service address on some records and the new one on others, and consolidating them wrongly attaches equipment to the wrong building. Water test results, which is the data that should drive media life, usually exist only as a paper form in a job folder if they exist at all.

The fix is to run a data audit before anybody writes a feature, and to accept that reconstruction is partial. Rebuild what you can from invoices and job notes, mark the rest as unknown rather than guessing, and give techs a one tap way to capture the missing details on their next visit so the registry fills itself over the first year. Budget three to five weeks. The pay off is immediate, because the same reconstruction produces a list of accounts overdue for service you were never billing, which is normally the single strongest argument for the whole project.

Why do ServiceTitan and QuickBooks integrations break after launch?

Layering on top of a working platform is usually the right architecture, and it is also where the maintenance burden sits. These integrations break in three predictable places.

First, customer creation. If a call is booked directly in the platform while the new system also creates customers, you get duplicates, and duplicates in this business mean one household with two equipment registries and half the service reminders going nowhere. Second, job completion. The trigger that says a filter change happened and should be billed depends on a tech marking a job complete in a particular way, and techs change habits, especially when a new office manager tells them something different. Third, the platform's own updates: field meanings shift, endpoints are versioned out, and a sync that has run untouched for eight months stops on a Tuesday.

The fix is to pick one system as the authority for each object and write it down. Customers created in one place only. Equipment and service rules owned by the new layer, always. Invoices generated by whoever owns the money. Then instrument the boundary: a daily count of jobs completed versus invoices generated, and an alert when the gap is not zero. That single check catches most of what goes wrong, because every failure mode here eventually shows up as work done and not billed, which is the exact problem you built the system to end.

What happens when after hours calls and route capacity are not covered?

These are the two gaps dealers accept as normal, and both cost more than the software would.

A softener sticking mid regeneration on a Sunday night is an emergency to the homeowner and a voicemail to you. She calls the next dealer on the map and you never learn what the call was worth. Answering services do not close the gap, because the person taking the message cannot tell an emergency bypass from a salt reorder, does not know your service area, and books nothing into your calendar. What is needed is an intake path that recognises the caller, sees their equipment, triages correctly and puts a real appointment on the board with a confirmation text before they hang up. Anything short of a booked job is a message, and messages lose jobs.

Route capacity is the quieter one. Salt delivery is logistics, not a to do list. A route has to respect how many bags fit on the truck, the delivery windows customers were promised, which techs are certified for reverse osmosis work, and drive time. A system that treats deliveries as appointments in slots will produce a route that zigzags and a truck that runs out of salt at stop nine, and the ops lead will go back to the whiteboard. Build routing with real constraints or leave routing alone and keep the whiteboard honestly, but do not pay for a version that does neither.

Should you build custom or configure what you already own?

A smaller dealer doing mostly one off installs and straightforward service, with a light book of recurring plans and no real salt delivery operation, should stay on ServiceTitan, Jobber or Housecall Pro. Those tools are genuinely good at what they were built for, which is scheduling a job, dispatching a tech and taking a payment, and spending six figures to replace that is a bad trade. If routing is your only unmet need, WorkWave Route Manager is a real product and configuring it beats building one.

The signals that change the answer are specific. You have hundreds or thousands of recurring salt and filter accounts and you know you are not billing all of them. Somebody reconstructs who got serviced from truck notes every week. Your install history is trapped in a tool that is being sunset or that nobody can automate against. You are a rollup trying to put three acquired dealers on three different systems into one view. Or per seat fees keep climbing while the tool still cannot bill a carbon service on the right date.

Even then, the first move is rarely to rip out the incumbent. Layer the equipment registry, the service rules engine and automatic billing on top through the platform interface, take the recovered billing from that phase, and use it to fund whatever comes next. Replace the platform only where it actively blocks how you make money, and phase it when you do.

How do hidden costs get into the quote?

The development estimate is usually the accurate part of the number. These are the lines that arrive later.

• The data audit. Three to five weeks reconstructing the install base from invoices, job notes and paper. It is not development and it cannot be skipped.
• Media life modelling. Encoding how each equipment model ages against water quality is domain work, not a configuration screen, and it is the difference between a service clock and a calendar reminder.
• Route optimisation. Real constraints such as truck bag capacity, delivery windows and tech certification make this genuine logistics engineering. Teams that have never built routing underestimate it badly.
• Tech adoption. Field staff have to change how they close jobs. That is training time, and a build that assumes techs will simply comply is a build whose billing trigger fires inconsistently.
• Multi location consolidation. If you are a rollup, each acquired dealer's data is its own migration, not a copy of the first one.
• Ongoing maintenance. Platform interfaces change, and the sync you depend on for billing needs somebody watching it.

Ask for each of these separately. A proposal that never mentions the data audit is a proposal that has not looked at your data.

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

Ask a prospective developer to describe out loud how they would schedule a carbon media service for a specific softener model on hard water. If the answer reaches for a recurring task every 90 days, they do not understand that your equipment drives the clock, and everything they build will inherit that misunderstanding. The right answer talks about equipment records, media life, gallons treated and water quality before it mentions a calendar.

Second, the successful builds start with the money and prove it early. Ship the equipment registry, the due date engine and automatic invoicing first, then hand the owner the overdue account list the migration produced. That list is a number, and a number in the first eight weeks is what keeps a project funded and keeps the owner engaged.

Third, they design the billing trigger around what techs already do rather than what they should do. If billing depends on a field being filled in that nobody fills in, the leak reopens quietly. Watch a real job close before designing the workflow, and add the daily jobs completed versus invoices generated check so the gap can never grow unnoticed.

Fourth, ownership is settled at kickoff and put in writing. The code lives in your repository and the system runs in your cloud account, so you can hire anyone to maintain it and you are never renting access to your own customer list. A vendor who hedges on that is describing how much control they intend to keep later, and in a business whose main asset is an install base built over fifteen years, that is not a risk worth taking.