The advice most businesses need first is what not to do
There is no shortage of firms prepared to tell a company that it needs AI. The useful conversation is narrower and considerably less flattering to the technology. It starts by establishing which parts of a specific operation would actually benefit, which parts would not, and what has to be true before any of it works.
That conversation frequently concludes that the first project should not involve AI at all. A company whose item list contains the same product under four different codes, or whose customer records are duplicated across two systems that disagree, is not ready to automate anything on top of that foundation. Telling them so costs us the larger engagement in the short term. Research from MIT last year found roughly 95 percent of enterprise AI pilots produced no measurable business impact, and a substantial share of that failure traces to projects scoped before anyone asked whether the underlying conditions supported them.
What an assessment examines
Where the time actually goes
Not where people believe it goes. The processes consuming the most hours are frequently not the ones anyone complains about. Establishing this takes observation and honest conversation with the people doing the work, which is one reason discovery involves the staff rather than only the owner.
What condition the data is in
Duplicate records, inconsistent codes, fields repurposed years ago, missing values a person has always filled in from memory. All of it was survivable while humans interpreted the screens. None of it survives automation. This usually determines the sequence of everything that follows.
Whether the process is worth keeping
Some workflows exist only because a system limitation years ago required a workaround. Automating those preserves an accident. The right move is often to remove the step rather than accelerate it.
What being wrong costs
A task where an error is caught immediately and reversed cheaply can tolerate far more autonomy than one where a mistake reaches a customer or the books. This determines where human approval is mandatory.
Whether the volume justifies the build
A task performed twice a month is rarely worth automating, regardless of how tedious it is. Frequency and consistency matter more than annoyance, because a rare task never repays the build.
Sequencing determines whether adoption survives
The order of work matters as much as the selection, because the first project sets whether the organization believes any of this. Start with something high frequency, well understood and low consequence. It produces a visible result quickly, it can be evaluated honestly, and the team gains direct experience of working alongside a system that proposes rather than decides.
Starting with the most valuable opportunity is a common and expensive instinct. The most valuable processes are usually the most complex and the most consequential, so the first project becomes the one most likely to overrun and produce a mistake in front of the people whose support you need. Order matters.
The honest limits
"AI does not fix a business that does not understand its own process. It executes what you specify, so an unclear specification produces confidently unclear output."
Savings are frequently smaller than projected because the human review that makes the output trustworthy is itself work. A task that took an hour and now takes fifteen minutes of review is a real gain, and it is not the elimination that gets promised. Adoption is a people problem more than a technical one. A team that believes software is being introduced to replace them will not report its errors, and unreported errors are worse than having nothing at all. And capability is moving quickly enough that some things not worth building today will be straightforward within a year. Part of the advice is what to defer.
What the assessment owes you
The findings are yours regardless of who implements them, including a recommendation to do nothing where that is the right answer, and including work better handled internally by your own people. We use AI throughout our own products, inside systems that can reject bad output and with human judgment on every approval path. Having found the boundaries in our own work is why what we can say about them is specific rather than general.
What you should end up with
A written assessment of where AI would produce measurable value in your specific operation, and equally where it would not. A sequence with a defensible first project. An honest account of what has to be fixed before anything else is worth attempting. An estimate of what each piece involves. And enough understanding of the reasoning that you could evaluate a competing proposal on your own. That last outcome is deliberate. A client who can evaluate the advice is a client who stays for the right reasons.
How the engagement runs
Assessment work happens through screen shared working sessions, which keeps it affordable and lets us start within days rather than quarters. Onsite is available where genuinely warranted, such as observing physical operations that cannot be understood over a screen. The engineering that makes AI output safe to act on is covered in custom AI integrations, and agent design is covered in custom AI agents.