If you can't say how many hours a build will save, you can't say what it is worth. And if you can't say what it is worth, every price feels either suspiciously cheap or unreasonably expensive. We price every automation against the time it gives back, and we agree that price before any work starts.

Count the hours

Start with three numbers: how long the task takes each time, how often it happens and how many people do it. Multiply them together and you have the hours per week. Multiply by the number of working weeks in a year and you have the hours per year. Then add the time spent fixing mistakes, chasing and checking, which people tend to forget.

Be honest here. It is tempting to round up to make a project look good. Inflated savings make for a disappointing review six months later.

A worked example

Here is an illustrative example, not a real client. Say a team of three spends about twenty minutes each on every incoming supplier invoice, and they handle around sixty a week between them. That is twenty hours a week, or roughly nine hundred hours a year once holidays are taken out.

If an automation handles most of the reading and filing, and a person only reviews the exceptions, the time might drop to a few minutes per invoice. Even with a conservative estimate, that frees up hundreds of hours a year for work that actually needs the team.

Turn hours into money

Hours only mean something when you attach a cost. Use the fully loaded cost of the people doing the work, not just their salary, so include taxes, benefits and overheads. Then decide what else the time is worth. Sometimes the real value is not the cost saved but what the team can now do instead: faster replies, fewer late payments, a manager who is no longer the bottleneck.

Price against a year

We aim for a fixed price that pays back well inside the first year. If a build would take longer than that to pay for itself, we say so, and usually suggest something smaller. A good automation should feel obviously worth it on paper before anyone writes a line of code.

Don't forget running costs

Automations are not free once they are built. Include:

• Subscription costs for the tools involved.

• Usage costs for any AI model, which grow with volume.

• Time for someone to review exceptions and approve the risky steps.

• A little maintenance when the tools on either side change.

Subtract these from the savings before you decide. They are usually small, but they are real.

If a task takes an hour a month, the honest answer is usually a checklist, not software.

Know when to walk away

Some tasks are not worth automating. They happen rarely, change constantly or depend on judgement that is hard to describe. For those, a clear checklist, a better template or simply deciding to stop doing the task is often the right answer. Saying no to a build is part of pricing it properly.

Fixed price, agreed first

Once the hours, costs and scope are clear, the price is fixed. You know exactly what you are paying and what you will get, and we carry the risk of the build taking longer than planned. It keeps both sides focused on the outcome, not the hours spent getting there.

Sample article for the Relay template. Replace it with your own writing.