The hand steps, written down as rules
Every routine chain your staff walk — done in one system, then something in the next — is written as a trigger, the steps that follow, and what counts as finished, and agreed before anything is built.
Workflow automation replaces the steps a person walks between systems — close the job, raise the invoice, email the customer, set the follow-up — with rules that run themselves the moment the first step happens. It is for businesses whose day depends on someone remembering what comes next. Ozwebnet writes the rules from scratch in Adelaide, South Australia, for businesses across Australia: one fixed quote, set in writing and staged against milestones, and the source code handed over with the IP assigned to you.
DETAIL OF SHEET 07 — SYSTEMS INTEGRATION →
Workflow automation is software that carries out the routine steps between your systems without a person doing them. Each chain of steps becomes a rule: when a job is marked complete in ServiceM8, raise the invoice in Xero, email the customer, set the follow-up task in the CRM. The rule fires the moment the first step happens, every time, and writes down what it did. Where a step needs a decision, it stops and asks the right person. An integration moves one record between systems; workflow automation runs the whole chain of steps that record sets off.
Every routine chain your staff walk — done in one system, then something in the next — is written as a trigger, the steps that follow, and what counts as finished, and agreed before anything is built.
A rule starts from an event in your own software: a job closed in ServiceM8 or simPRO, an order paid in Shopify, a lead created in HubSpot, a form submitted, a stock level reached in Cin7, or a set time each morning.
Raise the invoice, send the email, create the task, book the slot, update the record: each step is carried out in the system that owns it, in the order the rule says, once the step before it has succeeded.
Where a step needs a decision — a discount, a refund, a credit hold — the rule stops, sends it to the right person with what they need to decide, and carries on once they have.
If a system is down or a record does not match, the step is tried again. If it still cannot finish, the right person is told with what to fix, and the rest of the chain waits rather than running on bad data.
Each time a rule fires, what it did, in which system and when, is written down — so whether the invoice went out is answered by looking it up, not by asking around.
Each rule comes with a short written note saying what starts it, what it does and who is told when it stops; the code for all of them is delivered with the IP assigned to you.
TYPICAL SCOPE FOR THIS KIND OF SYSTEM — YOUR EXACT SCOPE IS FIXED IN WRITING AT THE SPECIFICATION STAGE.
Not sure which? Ten minutes on 1300 699 321 tells you — Mon–Fri 9–5 ACST.
One fixed quote, set in writing at the specification stage (02 Blueprint) and staged against the five milestones below. Each milestone ends with a working system; stop at any milestone and keep what has been built.
SEE THE FIVE STAGES ANIMATED →We follow each chain of steps as it is done today, from the event that starts it to the last system it touches.
Each rule is specified in writing — its trigger, its steps, who decides the exceptions — and the fixed quote is set here, priced by the number of rules and the systems each one touches, staged against milestones.
Built one rule at a time, the chain that costs the most hand-work first; each milestone ends with a rule running on its own.
Every rule is run against real records, including the ones that should stop and ask, and tested before launch.
The rules go live beside the steps they replace, and you receive the source code with the IP assigned to you.
An integration moves a record from one system to another. Workflow automation runs the whole chain of steps that record sets off — raise the invoice, email the customer, set the task — with rules that fire on their own the moment the first step happens, and stop to ask a person where a decision is needed.
If a single step between two systems is handled by Zapier, Make or a native connector for a monthly fee, keep it — we will say so. A custom rule is worth building when the chain has outgrown the tool: it needs an approval, a retry, a log you can read, or a system the tool does not connect to. The rules are then source code you own.
Where a step needs a decision, the rule stops, sends it to the right person with what they need, and carries on once they have decided. Where a step cannot finish — a system down, a record that does not match — it is tried again, then the right person is told with what to fix, and the rest of the chain waits rather than running on bad data. Every run is logged step by step.
Yes — Australia-wide. The rules connect to your systems over the internet, and the build is specified, tested and handed over the same way wherever you are.
One fixed quote, set in writing before the build and staged against milestones, priced by the number of rules and the systems each one touches. The rules are delivered as source code with the IP assigned to you.
Call, or answer a few short questions — what you run, what breaks, when you need it working — and we reply within one business day. The quote is fixed in writing before any build starts.