Paying on acceptance rather than on delivery

The uncomfortable fact about automation work is that the vendor gets paid for building the thing, and whether the thing still works afterwards is somebody else's discovery. Almost every incentive problem in this market comes from that one arrangement.

Ours is structured in three layers, and the reason for each is worth stating plainly.

A paid audit, credited forward

The discovery carries a small fixed fee, and the full amount comes off the first automation. If you go ahead, the discovery was free. If you stop after it, you keep the whole report.

It is not free at the point of asking, and that is on purpose. A free audit attracts people who want a free audit, consumes exactly as much work as a paid one, and anchors the entire relationship at zero. A fee credited forward costs a serious buyer nothing and filters out everyone else.

A fixed fee per automation, due on acceptance

Every automation gets a one-line definition of success, written before any work starts and drawn from the audit's own data. Something of this shape: the weekly report is generated automatically from the source systems, with no manual assembly, for four consecutive weeks.

The fee falls due when that definition is met. Not when the work is delivered, and not when it is demonstrated. When it has run.

This is the layer that changes behaviour. A definition of success written in advance is also a definition of scope, which means the argument that usually happens at the end happens at the beginning instead, when it is cheap and both sides still have all their options.

A monthly fee per working automation, with a clause

Live automations need maintenance. Interfaces change, edge cases arrive, somebody renames a field. The monthly fee covers that, and it carries a condition: if an automation breaks and stays broken beyond an agreed number of working days, that month is free.

The clause is the point of the layer. It puts a price on our slow response, which is the only thing that reliably produces a fast one.

Why there is no percentage-of-savings deal

Percentage-of-savings sounds like perfect alignment and behaves like the opposite.

It requires both sides to agree on a counterfactual: what the cost would have been if nothing had changed. That number is unknowable, it moves whenever the business does, and every month becomes a negotiation about a hypothetical. Meanwhile the vendor carries the delivery cost up front against revenue that arrives slowly if it arrives at all, which is a quick way to make a services business stop caring about its smaller clients.

Being on the hook for the outcome is right. Being on the hook for an argument about an outcome is not the same thing.

What it sounds like from the other side

We lose money when it does not work, which is exactly why it will. That sentence is worth putting to any other vendor you are speaking to, because it is easy to say and expensive to mean.