If you run a utility appliance recycling program, the appliance recycling program software behind it has to do far more than schedule pickups. Scheduling is the easy part.

The hard part is that an appliance recycling program is a field logistics operation with a regulatory reporting obligation bolted onto it, running under rules that differ for every utility you serve, funded by ratepayer dollars that somebody has to account for.

We have built and run systems for this since 2003, across roughly 150 electric utility customers, including the call center application, the customer ordering site, and the dashboards program managers use. This is what we have learned the software actually has to do.

What Appliance Recycling Program Software Must Handle

A working program platform is really five things that have to agree with each other:

1. Eligibility and validation — is this customer entitled to participate, and for how many units?
2. Scheduling and dispatch — booking, routing, rescheduling, and no-show handling.
3. Field capture — what the crew records at the door, and what proves it.
4. Disposition and compliance — where the unit went and what was recovered from it.
5. Reporting — savings claims, invoicing, and whatever the utility’s regulator requires.

Good appliance recycling program software connects field records, eligibility, disposition, invoicing, and reporting so the same unit-level data supports every claim.
Most program problems trace to these being separate systems that do not reconcile. A unit collected in the field but never matched to an eligible account becomes a unit nobody can bill for and nobody can claim savings on.

Eligibility validation is where programs leak money

This is the least glamorous item on the list and the one with the largest financial consequence.

Validation means checking the participant against the utility’s own billing data — account number, service address, account status — before a truck is dispatched. Do it properly and you avoid sending a crew to a customer the program cannot pay for. Do it loosely and you discover the problem after the appliance is on the truck.

Program rules also cap participation, and the caps are specific. One utility program currently limits customers to seven large and seven small units across a five-year window running from mid-2026 through mid-2031. Rules like that have to be enforced by the software at booking time, across program years, and across program changes — because a customer who participated in 2027 under an older rule set still counts against the new limit.

Then there are the edge cases that generate most of the exceptions: multifamily properties, where the property manager rather than the resident schedules the pickup; second refrigerators versus primary units; landlord-owned appliances; and customers who moved between service addresses. Every one of these needs a defined answer in the system, because a crew standing in a driveway will make one up otherwise.

Scheduling is a routing problem with a customer attached

Two things separate programs that hit their numbers from programs that do not.

No-show management. A crew arriving at an empty house is the single largest controllable cost in the operation. Confirmation calls, reminder messaging, and clear instructions about unit accessibility all reduce it measurably. So does capturing whether the unit is in a basement before the truck is loaded.

Route density. Pickups clustered geographically move the cost per unit more than any other operational lever. That means the scheduling system has to think about geography when offering appointment slots, not just availability.

Drop-off events and multifamily bulk collections need their own handling. They are not just pickups with more units.

Field capture is what makes the claim defensible

Whatever the crew records at the door becomes the evidence behind every savings claim and every invoice. It needs to be captured on the spot, not reconstructed later from paperwork.

At minimum: unit type, make, model, serial number, size, age where determinable, and a photograph. Refrigerant type matters for downstream compliance. Condition and working status matter because programs generally require that the unit was operating — a non-working unit was not consuming energy, so retiring it saves nothing.

We built this on Android tablets for exactly this reason: the data is more accurate when it is entered in front of the appliance, and a photograph taken at the door settles disputes that paperwork cannot.

Chain of custody starts here and has to hold all the way to the processor.

Disposition and compliance is not optional paperwork

Refrigerators and freezers contain materials that are regulated on the way out — refrigerants including CFCs and HCFCs, foam blowing agents, and depending on the unit, mercury, PCBs, and used oils.

The EPA’s Responsible Appliance Disposal program sets out best practices for recovering these materials rather than venting or landfilling them, and utility programs commonly commit to that standard as part of program design. Meeting it requires the software to track each unit through to its processing outcome and to produce the documentation on demand.

That means the record cannot stop at “collected.” It has to follow the unit to the recycling center and record what was recovered.

The reporting is what the program is actually judged on

Appliance recycling programs exist because retiring an inefficient unit reduces energy demand. The program is funded on that basis and evaluated on it by the state commission overseeing it.

So the platform has to produce:

• Savings claims tied to verified units, with the underlying detail available when an evaluator asks
• Invoicing that reconciles to those same units
• Program dashboards that let a utility program manager see performance against target without calling anyone
• Audit-ready records that survive an evaluation, measurement and verification review

The last one is where generic software fails. A system that reports totals but cannot produce the unit-level evidence behind them creates an expensive problem during evaluation.

Why Appliance Recycling Program Software Must Be Configurable

Every utility runs its program differently. Different eligibility rules, different incentive amounts, different unit caps, different reporting formats, different contract terms with the implementer, different regulator.

An implementer running programs for several utilities is therefore running several rule sets simultaneously, often with overlapping service territories and shared field crews. The software either models that as configuration — program rules as data rather than as code — or it becomes a separate build per utility, which does not scale and does not survive a program year rule change.

That is the architectural decision that determines whether a platform can grow with the business. We learned it the way most people do, which is by getting it wrong first and then rebuilding it as configuration.

Where ITsoft fits

We have been building software for appliance recycling programs since late 2003, working with electric utilities, program implementers, and recycling contractors across the United States. The system covers the call center, the customer ordering site, field capture on tablets, and the dashboards utility program managers use to watch their numbers.

One client we built for grew from around $2 million in revenue to roughly $90 million, and from one electric utility to around 150, over their years working with us. We are not claiming the software did that. We are saying it did not get in the way, which in this industry is not a low bar.

If you are running a program on spreadsheets and a scheduling tool, or on a platform that cannot produce unit-level evidence during an evaluation, that is a solvable problem and we have solved it before.

Talk to Mike Treat about your recycling program platform — we will walk your program rules, reporting obligations, and current systems, and tell you honestly what would need to change. The assessment is yours regardless.