Working with us starts with a free introductory conversation: enough detail to write a scope and quote a fixed fee, no more. The engagement itself opens with the detailed design the build depends on, then takes one workflow into production on your systems and hands it to the people who own it. One fee covers the design and the build.
An Airclerk engagement starts with a free introductory conversation, which gives Airclerk enough detail to write a scope and quote a fixed fee for one workflow. Once the scope is agreed, the engagement opens with a detailed design phase covering how the workflow really runs and the controls it needs, before the build takes it into production and hands it over. There is no separate paid assessment before the engagement. Support after go-live is written into the scope; ongoing operations are a separate agreement.
Our clients arrive looking the same way: you've used Claude, or Copilot, or ChatGPT on your own work. You know there's something in it for your firm, and you can probably name the workflow. What you don't have is the time, or the appetite, to be the one who builds it out properly.
Not there yet? We wrote up how to run the experiment on yourself first: find out for yourself.
The same four stages for every implementation, whichever industry and whichever platform. Nothing is built before the scope is agreed, and nothing after handover is assumed.
Where AI could make the biggest difference, how that work runs today, the systems it touches and who owns it. We also work out together whether Airclerk is the right partner for it. If we are, the conversation gives us enough to quote.
One document: the outcome we are aiming for, what we deliver, what your team contributes, the fixed fee and timeline, and what acceptance looks like. Nothing starts until it is agreed on both sides.
The engagement opens with the detailed design, agreed with you before anything is built. Then we configure and connect the workflow to your documents and systems, build in the agreed review controls and audit trail, test it on real work, and prepare the people who will run it.
Handover, and the support that follows go-live, are written into the scope so you know what is covered before you sign. Ongoing operations and further workflows are a separate agreement, made when you want them rather than switched on by default.
The conversation qualifies the work in both directions: you're deciding whether we're the right people, and we're deciding whether the workflow is ready to be built.
By "workflow" we mean one repeatable piece of work with a named owner and a clear finish: preparing the year-end workpaper file, or turning a policy schedule into the renewal note. Most people arrive with theirs already named; their own tinkering found it. If yours isn't obvious, we'll find it together.
The conversation has one job: enough detail to write a scope with a fixed fee and a timeline. It is not the plan. The detailed design happens at the start of the engagement, where it can be done properly against your systems. If we're not the right people for the work, we say so.
The shape of the workflow sets the timeline; we quote it with the fee. A document-only workflow and one that crosses several systems are different builds, which is why the timeline is quoted, not listed. The accounting implementation, our most defined build, runs six weeks.
We build on Claude, Microsoft Copilot or ChatGPT. Which one is decided with you in the first conversation, usually by what your firm already licenses and where the documents live.
The first conversation gives us enough to fix the price. It doesn't give us enough to build, and we don't pretend it does. The engagement opens with the detailed design: time inside your environment, the workflow mapped as it's really done rather than how the process document says it's done, and the controls and sign-off it needs. You see the design before anything runs. The build follows it.
The technology is the easy part. An implementation sticks when the owner can run the workflow and the reviewer knows what to check. That's why the build ends with your people running it, not with a demo of it.
Still deciding whether there's anything in AI for your firm? You can run the experiment on yourself first; we wrote up how: find out for yourself. Or write to us, say you are not sure where to start, and we will suggest a sensible first step.
Facing a platform decision rather than a workflow? If the question is "what does AI mean for our business" at board or owner level, that's AI Platform Advisory, not an implementation.
Running an accounting practice? Your version of this path is already defined: a conversation, then a six-week implementation anchored on year-end workpapers.
With a free introductory conversation. We cover the workflow you have in mind, the systems it touches, who owns it inside the firm and what done looks like. That's enough to write a scope with a fixed fee; the detailed design happens inside the engagement itself.
A fixed fee in NZD plus GST, quoted in writing after the first conversation. The fee is set by the shape of the workflow: the systems it touches and the controls it needs. No hourly billing. Platform licences and usage are yours, paid to the provider, and sit outside our fee.
The shape of the workflow sets the timeline, and we quote it alongside the fee after the first conversation. A document-only workflow and one that crosses several systems are different builds. As a reference point, the accounting implementation, the most defined of our builds, runs six weeks.
We offered one for a while: a two-week paid assessment that produced an implementation plan. We retired it: every engagement we actually ran started with a conversation and moved into one fixed-fee project. The thinking the sprint packaged didn't go away. The high-level part happens in the first conversation, and the detailed design happens at the start of the engagement, inside the fixed fee.
Alongside a sponsor, we need the person who owns the workflow day to day, for time in design and at testing, and someone from risk or security to approve access and the controls. The owner matters most: the workflow gets built around how the work is really done, not how the process document says it's done.
Whatever the scope says. Handover and the support that follows go-live are written into it, so you know what is covered before you sign. Ongoing monitoring, improvement and further workflows are a separate agreement, agreed when you want it rather than switched on by default.
Yes. We have standard NDA and DPA templates and are comfortable working under customer paper.
A free introductory conversation: the systems it touches and what done looks like. Then a written scope with a fixed fee to build it and take it into production.