Where every engagement begins
It starts with discovery.
Every engagement begins with an in-depth understanding of your business. We look at how the work moves today, the systems involved, the people and hand-offs behind it, the exceptions that create friction, and what your team actually wants to improve. Only then do we recommend the right next step, and that step is whatever the problem calls for rather than whatever we happen to sell.
Why we start here
We could recommend something from a conversation. Plenty of firms do. What usually follows is a proposal built on a version of the process that exists in a manager's head, and a change request three weeks later, because the real process turned out to have four exceptions nobody mentioned and one of them accounts for most of the work.
Discovery is how we avoid that. It is also, frequently, valuable on its own. A fair share of what discovery surfaces has nothing to do with AI at all: a duplicated approval, a report nobody reads, two systems that could simply talk to each other. Those things get named, and some of them get fixed the following week for nothing.
Understand the business first. The technology decision comes second, and it comes easily once the first part is done.
What we look at
Five lenses on the same operation. Between them they explain almost everything about why the work takes as long as it does.
- The work
- How a job actually moves from arrival to done. Not the version in the process document, the version that happens: the volumes, the timings, the waiting, and the steps that exist only because someone once got burnt.
- The systems
- What the business runs on, what those systems can and cannot reach, where data is re-keyed between them, and which of them have a usable interface for anything we might build.
- The people and hand-offs
- Who touches the work, what they decide, and what only lives in someone's head. Hand-offs are where time disappears, and they are almost never drawn on anyone's diagram.
- The exceptions
- The cases that break the happy path, how often they really occur, and what they cost. Most failed automation projects are failures of exception handling, decided long before anything was built.
- The intent
- What your team actually wants to improve, and what the business is being judged on. A technically excellent improvement to something nobody cares about is still a wasted quarter.
How discovery actually runs
The shape is scaled to the question. One process in a twenty-person business is a few days of close attention. An operation with several business units and a decade of accumulated systems is longer, and we will say so before we start rather than discover it halfway through.
What does not change is the method: we watch the work happen rather than asking people to describe it. Descriptions are tidy. The job is not, and the difference between the two is usually where the opportunity is.
- Time with the people doing the work, not only their managers
- Observation of real cases, including the awkward ones, rather than a workshop
- A look at the systems involved and what they can realistically expose
- Rough numbers on volumes, timings and rework, honest enough to sort by
- A conversation with whoever carries the consequence of getting it wrong
On the Gold Coast and in Brisbane we do this on site, because sitting beside someone while they work is straightforwardly better. Elsewhere in Australia we do it over video, which works better than people expect for screen-based processes.
What comes out of it
Discovery ends with a shared, accurate picture of the operation and a clear view of where to attack first. The exact artefacts depend on what we were looking at, but they generally include:
- A map of how the work actually moves today, exceptions included
- An honest read on where the time and cost currently go
- A shortlist of the areas worth attacking, ranked on value, feasibility and consequence of error
- A readiness view across data, systems, skills and governance
- A recommended next step, with the reasoning and a realistic sense of what it involves
All of it is yours, written to be usable by anyone competent, including a team that decides to do the work internally or with someone else.
Then we recommend the right next step
The shape of the engagement follows the need. There is no standard package waiting at the end of discovery.
Advice
Sometimes what a business needs is a clear view and the confidence to act on it: what to do, in what order, and what to leave alone. No build required.
Process redesign
Often the biggest win is the process itself. Remove a step, merge two roles, kill an approval nobody uses. Automating that mess would only have made it faster.
Training and enablement
Where the tools are already in the building and the gap is capability, we train your people on your own work rather than on generic examples.
A prototype
When the question is 'can this even be done reliably', the cheapest answer is a small working thing tested against real cases before anyone commits to a build.
A production build
Where there is a clear, repeatable, valuable process and the feasibility holds up, we design and build it properly: real software, in production, against your systems.
Nothing, for now
Sometimes the honest finding is that there is nothing here worth building yet. You get that answer with the reasoning, which is a better outcome than a build that never pays for itself.
What this is not
Discovery is not a fixed product with a fixed duration and a fixed price list. It is the part of the work where we earn the right to make a recommendation. We agree what it will cover and what it will cost before it starts, and we scope it to the size of the question rather than to a template.
Frequently asked questions
How long does discovery take?
It is scaled to the question. A single process in a small business is usually a few days of close attention; an operation spanning several teams and a decade of systems takes longer. We agree the scope and the cost before it starts, so the answer is a real number for your situation rather than a package length.
What does discovery cost?
It depends on how much operation there is to understand, and we agree the number before any work begins. It is deliberately sized to be a decision rather than a project, so a business of five to two hundred people can commit to it without a business case.
How much of our team's time does it take?
A few hours a week from the people who run the process, plus one decision-maker available for the conversation about priorities at the end. We work around your operation rather than pulling people into rooms for days.
Can you do discovery remotely?
Yes, and we do regularly for clients outside South East Queensland. Observation over video works better than people expect, particularly for screen-based processes. For Gold Coast and Brisbane clients we do it on site because being in the room is better.
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 a great deal; that it happens does not.
What if we want to act on the findings ourselves?
That is a legitimate and reasonably common 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.
More questions answered on the full FAQ.
Read next
Start with the business, not the technology.
Tell us about one process that takes longer than it should. Thirty minutes is usually enough to work out whether there is something here worth understanding properly.