A useful AI automation consultant should be able to explain what will change in your operation, what evidence will show that it works, and who will own the result. A convincing demonstration is helpful, but it leaves those purchasing questions unanswered.
If you are comparing consultants, start with one real workflow. Describe the work your team repeats, the systems it touches and the point where delays or mistakes occur. Then evaluate how each person turns that description into a concrete delivery plan.
Look at the questions they ask first
A good discovery conversation should reach beyond preferred models and automation tools. Who currently performs the task? What makes a result acceptable? Which cases require a person? What information is missing when the work goes wrong?
Consider a distributor that receives order requests by email. The relevant questions include how customers identify products, who resolves an unclear quantity and when a draft becomes an accepted order. Asking only which email system is installed would miss the business process.
You do not need every answer before contacting a consultant. The quality signal is whether the discovery process identifies those gaps and turns them into decisions, dependencies or explicitly excluded work.
Ask to see how they define a deliverable
“An AI assistant connected to your systems” is difficult to evaluate. A more reviewable deliverable describes an input, a result and the cases the system must handle. For example, an assistant might prepare a proposed order with source references, while a staff member confirms ambiguous lines before entry.
Ask what you will receive besides the interface: configuration, source code where applicable, operating instructions, test examples and a record of known limitations. The precise package depends on the engagement, but it should be explicit in the proposal.
I use the same emphasis on ownership in the engineering work I undertake through Wizutech. The software needs an understandable place in the business after the initial build is finished.
Compare proposals on the same boundaries
| Area | Question to ask | Useful evidence |
|---|---|---|
| Process understanding | Which cases are in scope? | A workflow description with exceptions and an owner. |
| Integration | What must change in existing systems? | Named data sources, access needs and expected outputs. |
| Acceptance | How will we decide that the work is ready? | Agreed examples and review criteria. |
| Handover | Who can maintain or replace the implementation? | Ownership, documentation and operating responsibilities. |
This comparison makes price more meaningful. A lower quote may cover a prototype while another includes the integration, review process and release work. Ask about the difference before treating the figures as equivalent.
Understand who will do the work
Clarify who conducts discovery, who implements the system and who handles problems after release. You may prefer an independent engineer or a larger delivery team. Either arrangement can work if responsibilities and availability are clear.
For prior work, look for evidence relevant to your problem: an integration boundary, an operational screen or an explanation of a difficult failure. A long list of technologies does not establish that the person can work within your existing processes.
Ask how unexpected findings affect scope. Discovering that a source system lacks a usable interface should lead to a documented decision, not a silent change in what you will receive.
Start with a decision you can review
If the requirements are uncertain, a scoped discovery or audit can be a sensible first engagement. Its output should identify feasible work, unresolved dependencies and a recommendation for the next step. An assessment that only recommends buying a larger assessment is not enough.
I work directly on system architecture and implementation. For an initial enquiry, the most useful information is the task you want to improve, the systems involved and one example of a difficult case. That is enough to begin a practical conversation about fit and scope.
Discuss your automation project
Tell me which task you want to improve, which systems it touches and what currently makes it difficult. I can review the situation with you and define a suitable next step.
Updated 30 September 2026.