The approach
How we work.
Every ASCENTI engagement begins with discovery: understanding your business, its processes, systems and people well enough to say something useful about them. What follows depends on what we find. Sometimes that is advice or a process change, sometimes training, sometimes a prototype, sometimes a production build. The shape of the engagement follows the need rather than a template.
Five commitments we build every engagement around
We understand the business first
AI applied to a process nobody has mapped just automates the mess. We spend the time to understand how your operation actually runs: the workflows, the exceptions, the knowledge that only lives in someone's head, before we recommend or build anything.
Process first, AI second
We fix the workflow, then automate it. AI on a broken process just fails faster and at greater volume.
Engineers, not slide decks
Fifteen-plus years shipping commercial software Australian businesses run their operations on: enterprise ERP, e-signature platforms, MSP automation. The systems consultants recommend are the kind we have built.
Built for Australia
We know the local rules, the local buyers, and how business actually gets done here. Privacy, the Essential Eight and the National AI Centre's Voluntary AI Safety Standard are design inputs, not a compliance review at the end.
Your data stays yours
The data and the business knowledge that go into a system remain yours, and how it works is written down in plain English rather than left as a black box. Most systems then run as a hosted service under an ongoing agreement covering hosting, model usage, any third-party subscriptions the workflow needs and our support, because a live AI system costs something to keep running. Commercial terms are set out per engagement rather than by a blanket policy, so ask early and we will put the answer for your build in writing.
What a typical engagement looks like
A pattern, not a mandatory four-stage framework. Plenty of engagements stop after the second step, because the recommendation was advice or a process change rather than a build.
01 · Understand
Learn the business, the workflows, the systems, the people, the constraints and the outcomes you are actually after. We watch the work happen rather than asking people to describe it, and we pay particular attention to the exceptions and hand-offs, because that is where the time usually goes.
02 · Shape
Define what a better version of the process looks like, then decide what should deliver it: AI, conventional automation, custom software, a process change, or a combination. This is done with the people who will live with the result, and it is where we say so if the answer is that no build is warranted.
03 · Build and test
Where a build is the right answer, we develop in stages against your real systems, test against real historical cases rather than tidy examples, and keep people involved in the decisions that carry consequence. You see working software at checkpoints, not at the end.
04 · Embed and improve
Deploy, document, train the people who will run it, then watch how it behaves in actual use and improve on that evidence. Autonomy gets extended where the record supports it, not on the day it goes live.
How long each step takes, and whether all four happen at all, depends entirely on what discovery finds. We would rather describe the pattern honestly than sell a four-stage programme that every problem is then made to fit.
What we need from you
The engagements that go badly almost always go badly for the same reason: we were kept away from the people doing the work. So here is what makes it work.
- Access to the people who actually run the process, not only their manager
- Permission to see the real workarounds without anyone being in trouble for having them
- One decision-maker who can approve scope without a committee
- Honest answers about what has been tried before and why it did not stick
- A few hours a week during discovery, and a named person to answer questions during the build
That is the whole list. We do not need clean data, a strategy document, or a completed digital transformation programme first.
How the work gets measured
We would rather argue about a number than about an impression, so wherever a piece of work has one we agree what good looks like before building and instrument the system to report it. What that measure is depends entirely on the work: a document workflow and an agent handling exceptions are not judged the same way, and some of what discovery surfaces is worth doing on judgement rather than on a figure.
So this is a menu rather than a contract. The useful discipline is picking the one or two that actually decide whether the work was worth doing, instead of a dashboard of thirty nobody reads.
Cycle time
- Direction
- Down
- Typically used when
- Speed of response is the commercial constraint
Cost to serve
- Direction
- Down
- Typically used when
- Margin per transaction is the pressure
Hours returned
- Direction
- Up
- Typically used when
- The team is the bottleneck and capacity is the goal
Throughput per head
- Direction
- Up
- Typically used when
- Growth without proportional hiring is the objective
Exception rate
- Direction
- Down
- Typically used when
- Quality and rework are the real cost
| Measure | Direction | Typically used when |
|---|---|---|
| Cycle time | Down | Speed of response is the commercial constraint |
| Cost to serve | Down | Margin per transaction is the pressure |
| Hours returned | Up | The team is the bottleneck and capacity is the goal |
| Throughput per head | Up | Growth without proportional hiring is the objective |
| Exception rate | Down | Quality and rework are the real cost |
If a proposed build cannot be tied to one of these credibly, that is a signal worth paying attention to before spending money on it.
Working alongside your IT provider
Most of our clients already have someone running their infrastructure, and we come from the managed services world ourselves. We work with your provider, not around them: we design and build the AI layer, they keep running the environment, and where it helps we brief them directly so nothing lands as a surprise.
Where a provider is already doing good automation work, we will say so and scope around it rather than duplicating it. There is no advantage to us in a client paying twice.
Frequently asked questions
How long does a typical engagement take?
Discovery is usually days to a couple of weeks depending on how much operation there is to understand. Where a build follows, it is commonly four to twelve weeks depending on scope and how many systems it touches. Engagements that end in advice, a process change or training are shorter than that, and a fair number do.
Do we have to start with discovery?
In practice, yes, and it is a deliberate constraint rather than an upsell. Recommending or quoting anything without understanding the process produces either a padded estimate or a scope that changes three weeks in. What discovery looks like varies with the size of the question; that it happens does not.
What if the recommendation is not to build anything?
Then that is the recommendation, and it is a reasonably common one. A surprising share of what we map is better fixed with a process change, an integration, a deleted approval step or a configuration change in software you already pay for. Saying so is the point of hiring someone who does not sell licences.
What if we want to act on the findings ourselves?
That is a legitimate outcome and everything is written to support it. You get the picture of the process, the shortlist and the recommendation regardless of who does the work. We would rather you use it than pay us to build something you had the capability to do internally.
Do you offer ongoing support?
Optionally. Some clients take full handover and run it themselves, some take a support retainer, and some keep us on to extend the system. All three are normal and the handover documentation is the same in every case.
More questions answered on the full FAQ.
Read next
Start with one process.
Not a programme, not a transformation. One process that takes longer than it should, and thirty minutes to work out whether there is anything here worth doing.