AI workflow automationwith people still in charge
Once the right task is chosen, it has to be built, tested and handed over in a way your team can live with. MonoGrain builds AI into everyday workflows with review points where a mistake would matter, and explains what it costs to run afterwards, not just to build.
- For
- A chosen, repetitive workflow ready to change
- Built with
- Human review where errors matter
- Costs
- Build and running costs stated separately
- Pricing
- Scoped and quoted after a conversation
/What it is for
The work this is meant to take off your team
- Re-keying the same information between systems
- Sorting, summarising and routing incoming requests
- Drafting routine documents and updates for a person to check
- Collecting status from several places into one view
- Answering repeat questions from a defined body of information
Whether a given workflow is suitable depends on its exceptions, its data and the cost of a mistake. That is decided first, not assumed.
/How it runs
Scope, build, review, hand over
- 01
Scope
Agree the one workflow, what done looks like, how success will be measured against today’s baseline, and who reviews what.
- 02
Build
Connect the steps the workflow needs and put AI only where it helps. Everything else stays plain, predictable automation or stays manual.
- 03
Review gates
Where an output reaches a customer, moves money or changes a record, a person approves it before it happens. Those points are agreed with you, not added later.
- 04
Test
Run it against real examples, including the awkward ones, and check the results with the people who did the work by hand.
- 05
Hand over
Documentation, training for the people who will run it, and a clear account of what it costs to keep running.
/Fit
Who it fits, and when it doesn’t
A good fit when
- The workflow happens often and follows a recognisable pattern
- You can say what a correct result looks like
- Someone on your side will own the workflow once it runs
- You want running costs explained before you commit
Better handled differently when
- An off-the-shelf tool you already pay for can do it with a setting change
- The task is rare, so building would cost more than it saves
- Every case is an exception that needs human judgement
- Nobody can review outputs where errors would be costly
/Evidence
What we have built and run ourselves
These are MonoGrain’s own systems on this website, not client projects, and no outcome figures are claimed for them. They show the kind of work involved.
- A booking calendar that checks availability across two calendars before offering a slot, enforces working hours in Australian time and blocks duplicate bookings
- The Start here questionnaire, which turns a visitor’s answers into a recommendation and queues a PDF brief that is emailed to them
- Lora, an on-site assistant restricted to questions about MonoGrain, which declines out-of-scope requests rather than improvising
/Costs
Build cost and running cost are different numbers
A build is paid for once. Running costs keep arriving: software subscriptions, usage-based AI or API charges, hosting, and any support or changes you ask for later. Third-party providers set and can change their own prices. Each proposal states which costs are one-off, which recur, and who pays the third parties.
Anything beyond those sessions is scoped and quoted after a conversation, never from a price list. Under MonoGrain’s Terms, the proposal or statement of work sets the deliverables, timeline, fees, payment milestones, usage rights and any third-party expenses, and prices may exclude applicable taxes.
/Ownership
Accounts, data and handover
Under MonoGrain’s published Terms, you keep ownership of the materials and data you provide. MonoGrain keeps ownership of its own underlying software, tools and production technology, and receiving a deliverable does not by itself transfer those. What you receive and may use, and on what licence, is written into the proposal for each project.
Before any build, agree in writing whose accounts the workflow runs in, who holds the credentials, what you can export, and what support looks like after handover. The guide below lists what to ask for.
/Read next
Guides for this decision
Choosing the first workflow to automate
A scoring method for picking between candidates.
Build cost versus running cost
What you pay once, and what keeps arriving.
Ownership and handover
Accounts, credentials, exports and exit planning.
Human in the loop, done properly
Review gates that can actually change the result.
Consultant, agency, freelancer or DIY?
Who should build it, and who should maintain it.
Common questions
Do you automate the whole process?
Usually not. The aim is to remove the repetitive steps and keep people where judgement or accountability matters. Automating everything is rarely the cheapest or safest answer.
What does it cost?
Builds are scoped and quoted after a conversation. The proposal separates the one-off build from running costs such as subscriptions, usage charges and support.
Who owns the workflow afterwards?
Ownership of what is built for you, and the accounts it runs in, is agreed in the proposal. You always keep the materials and data you provide. Ask for the handover terms in writing before work starts.
Can we see results before a bigger commitment?
Start with one narrow workflow and agree in advance what result counts as success. The guide on testing value explains how to set that up with any provider.
Not sure this is the right first step?
Answer a few questions and see where MonoGrain would start, or book a free 15-minute call and ask. Prefer email? Write to hello@monograin.ai.