Right-sizing compliance software: what small utilities should pay for

Many vendor demos are built around the biggest program in the room. If you run a backflow, stormwater, pretreatment or FOG program at a small utility, a compliance software feature list that impresses a county with its own IT department can leave you paying for a lot you will never open.

What a small program needs on day one

A small program needs one record for every asset, site or permitted user with its history attached, a way to enter results once, notices that go out on schedule, and reports that come from the record instead of being rebuilt by hand. Add an export of your own data and you have the core of the job.

• A single record per backflow assembly, stormwater site, industrial user or grease generator, with inspections, results, notices and notes in one place.
• Results entered once. A test report or inspection that gets keyed into a database, scanned into a folder and copied into a sheet is the same work done over and over, and any one of the copies can be wrong.
• Reminders and notices tied to due dates, so a deadline doesn’t depend on someone remembering it.
• The reports your regulator or permit asks for, produced from the record. If the annual report still means reconstructing the year from emails, the software hasn’t fixed the problem you bought it for.
• An audit trail: who changed what, and when.
• An export of your data in a usable format, whenever you ask for it.

Check each item against your worst week: an audit request, a staff departure, a renewal cycle. A feature that makes that week easier is a day-one feature. One that only makes a good week look nicer can go in the second pile.

What you can grow into

Most other features are worth paying for when your program has the staff, the data and the habit to use them. Buying them before then means paying for capacity you can’t yet absorb.

The usual candidates:

• Live dashboards beyond a basic status view. They matter once the data underneath is clean, and they matter a great deal when someone above you asks for a number.
• Map and GIS integration, if your program already keeps its assets in a GIS and someone maintains it.
• Online portals for testers, contractors or property owners. These save the most time when you have enough outside parties that email and mail no longer keep up.
• Custom reports, once the standard ones stop covering what the permit or your manager wants.
• Connections to other systems, such as billing or work orders, when you can name the system and the person who owns it.

The question for each is whether your team would use it in the first year with the staff you have. If the answer is no, ask a different question: can the vendor add it later without re-implementing, and what does that involve? Having to migrate again to add a feature creates a cost that doesn’t appear on the quote.

What you may be paying for without using

These look essential in a demo and go quiet after go-live.

• Modules for programs you don’t run. A package that bundles all four program types suits a utility running all four. If you run one, ask what you’d be paying for the other three.
• Seats for people who will only ever read a report. Ask whether read-only access counts as a user.
• Configuration nobody on your team has time to handle. A system that can be tailored endlessly needs a person who tailors it. If that person is you, on top of the rest of your job, a simpler setup that works on day one beats a flexible one that is half-built in month six.
• Integrations for systems you don’t have, or have and don’t maintain.
• Custom report builders, when five standard reports cover your permit.

Two things are not on this list because small programs shouldn’t skimp on them: the audit trail, and the ability to take your data with you.

Questions to ask any vendor

Ask every vendor on your shortlist the same questions so you can compare their answers side by side.

• Can you show the demo with a realistic copy of my data, or at least my program’s real asset types, instead of sample records?
• What’s included in the base package, and what’s a separate line item or module? Can I have that in writing?
• If I add a program or module later, do I switch it on, or do I re-implement?
• If I leave, what format is my data in, how long does the export take, who does it, and is there a fee?
• How do my existing spreadsheets get in? What do you need from me, and which fields won’t come across? (We’ve written about what to ask on migration.)
• When our permit or the regulation changes, who updates the system, and is that included?
• How do testers, contractors or inspectors send results in, and what do they have to learn first?
• When something breaks in deadline week, who do I reach and how fast?
• Is there a program my size I can talk to about its first year?

Pay attention to vague answers on the exit, the add-ons and the migration. Those are the three places where the cost of a purchase tends to arrive late.

What to put in front of the council

A council or city manager tends to respond to a specific problem, a plain list of what’s being bought, and a clear picture of what happens if nothing changes.

One page is enough:

• The problem, in your numbers. Hours a month spent entering the same result more than once. Items that went overdue. A request from a customer, a regulator or a manager that took days to answer. Use your own figures, from your own records, and say where they came from.
• What the regulator expects. The records and reports your permit or program requires you to keep, and how the current setup holds up when someone asks for them.
• What you’re buying now and what you’ve deferred. The day-one list from this guide, with the grow-into list marked as later. It shows you’ve sized the purchase to the program.
• Cost over several years, with what’s included. Year one and year three can look very different once you account for added modules, extra users and support.
• The risk of staying put. Which parts of the program live only in one person’s files, and what happens when that person moves on.
• The exit. Who owns the data, and how you get it back.

Leave the vendor’s feature list in the appendix.

Write your day-one list first

Write your day-one list before you take a demo, and hold every demo to it. When a vendor shows you something impressive that isn’t on the list, write it in the second pile and ask what it would cost to add later.

SwiftComply makes compliance software for backflow, stormwater (MS4), pretreatment and FOG programs. Book a demo and bring your day-one list and questions. We work from whatever you have today, whether that’s spreadsheets, shared drives or paper.