There is no useful single price for “AI automation”. A small connection between two existing tools and a new customer-facing product are different jobs. To set a budget, define one workflow, estimate its current cost and ask for a quote that separates the build from ongoing operation.
This guide is for Australian business owners comparing an agent, an automation or a small software project. The calculation below is a hypothetical planning example in Australian dollars, not a market-rate claim, a melis.ai quote or a forecast of your return.
Describe the job before asking for a number
“Automate our reporting” leaves almost everything open. A better brief says who prepares the report, which sources it uses, how often it runs, who checks it and what happens when a number is missing.
Collect a few recent examples, including one awkward case. Decide what the first version should leave alone. Keeping a person’s final review can make the job clearer and limit the consequences of a mistake.
Ask the builder to describe a complete useful version, not just a demo. A report draft is not the same deliverable as a scheduled report with source checks, an approval step, documentation and a fallback.
Separate four kinds of cost
| Cost | Questions to ask before accepting a quote |
|---|---|
| Design and build | Which workflow, interfaces, integrations and tests are included? |
| Operation | Who pays for hosting, automation runs, model usage and existing tool subscriptions? |
| Human review | How long will somebody still spend checking or handling exceptions? |
| Support and change | What is covered after launch, and what needs a separate agreement? |
The price should also make exclusions visible. Historical data cleanup, a second workflow or a new integration can be substantial work. Record assumptions about volume and data quality rather than discovering them after the build starts.
For Australian quotes, confirm the currency and whether the amount includes or excludes GST. A comparison is only useful when the scope and tax treatment are clear.
A worked example you can replace with your own numbers
Imagine a reporting task takes 40 hours each month. The business estimates the relevant loaded cost of that time at A$60 an hour. A proposed workflow is expected to leave 12 hours of review and exception handling, with A$180 a month in additional running costs.
| Planning input | Hypothetical amount |
|---|---|
| Current time | 40 hours/month |
| Time remaining after the change | 12 hours/month |
| Capacity released | 28 hours/month |
| Value assigned to that capacity | 28 × A$60 = A$1,680/month |
| Additional running cost | A$180/month |
| Net capacity value before support costs | A$1,500/month |
| Hypothetical one-off build | A$6,000 |
| Simple capacity-value payback | A$6,000 ÷ A$1,500 = 4 months |
This is capacity value, not automatically cash savings or profit. If salaries stay the same and the released time is unused, cash has not increased. The business needs a plan to use the time: take on paid work, remove an external cost, reduce overtime or improve service in a way it can measure.
The example also excludes ongoing support, financing, tax effects and changes in demand. Add those where they apply. If additional support costs A$300 a month in this example, the net capacity value becomes A$1,200 and the simple payback becomes five months.
Test a less favourable case
Before approving the project, ask what happens if the time reduction is half as large or review takes longer than expected. In the same example, releasing only 14 hours gives A$840 in capacity value; after A$180 running cost, that leaves A$660 before support. The simple payback then becomes about 9.1 months.
A project that only works under optimistic assumptions needs a smaller scope or a different first job. Some builds are still worthwhile for quality, visibility or customer experience, but say that plainly instead of dressing every benefit as profit.
What makes the quote larger?
Common scope questions include the number of tools involved, the quality of the source information, the number of user roles and the consequences of a wrong action. A tool that drafts a report for one reviewer is different from a system that changes records for many customers.
Ask to see the assumptions. How will it handle duplicate events? Who checks an AI-generated answer? What happens when an external tool changes? Who owns the code, accounts and documentation?
These questions are a scoping checklist, not a claim that every project needs an enterprise-sized architecture.
Choose a pilot with a clear finish
A useful pilot has one workflow, a named user, agreed test examples and a decision at the end. The outcome may be to launch, revise, stop or leave the process manual.
Compare the delivered result with the baseline. Measure review time and failures as well as speed. Then decide whether to fund the next piece of work.
See examples of the kinds of software and automation we build. Project scope and price are agreed before work starts; an ongoing arrangement should be a separate, clear decision.
Should we pay a fixed fee or a retainer?
A defined job is often easier to compare as a scoped quote. Ongoing work needs an agreed queue, capacity and review rhythm. Choose the arrangement that makes responsibilities and limits easiest to understand.
Should a quote promise a percentage return?
Ask what the promise is based on, which costs it includes and how the result will be measured. A worked example is useful for planning; it is not proof of an outcome.
Bring a real example.
Bring a recent example of the job and a rough measure of its current cost. We can scope a useful first version and quote it before work starts.
Let’s talk