AI strategy consulting and opportunity assessment
AI strategy consulting as a fixed-scope assessment: where AI pays off in your operations, in what order, and with what integration and risk.
What an AI opportunity assessment is
An assessment is a fixed-scope review of three things: the operations work your people actually do, the data that work runs on, and the systems that hold the data. The output is a decision document: which work is worth automating, which is not, and in what order. It is written for the person who has to approve the build and live with the result, not for a conference audience.
"AI strategy" usually arrives attached to a slide deck. We mean something narrower. The strategic question for an operations-heavy business is not which model to adopt. It is which repeated, system-spanning tasks in purchasing, fulfillment, order intake, reporting and support should be handed to software, under what approvals, into which system of record.
What it produces
A ranked list, with every candidate written up the same way so entries can be compared rather than argued about one at a time.
The work it replaces
Who does it today, how often, from which screens, and what they decide along the way. If nobody can describe the current process, that is the first finding.
The value, with a baseline
In your own units: hours, late orders, stockouts, reply time. Measured before anything is built, so the result can be checked afterward.
The integration
Which systems the automation reads, the one it writes, and whether that system's API and data can carry the write. This is where the cost lives.
The risk and the approval
What happens when the software is wrong, who notices, and who signs off before anything with money or stock attached is committed.
The document also lists what we recommend you do not build, and why. Some work is too irregular to automate well. Some is cheaper to fix in the ERP configuration. Some is already served by an off-the-shelf tool; the trade-offs are in our post on custom AI versus off-the-shelf tools.
How candidates are ranked
Three factors, scored separately and never collapsed into one number. Value is how much repeated work disappears and how much of it sits on the path to an order shipping or a bill being paid. Integration cost counts systems touched, with a heavy penalty for every one that must be written rather than read. Risk is the cost of a wrong action, discounted by how easily a human can catch it first.
The ranking is rarely the one people expect. The work that scores highest is usually dull: a scheduled job that drafts purchase orders for someone to approve, an end-of-day report assembled from four systems, order intake that creates an ERP record instead of a spreadsheet row. The glamorous candidate, a customer-facing agent acting on its own, tends to rank low because its risk is high and its approval design is hard. That is a finding, not a disappointment.
Every value figure in the document carries its method: what it measures, over what period, at which site, and how it was counted. A figure that cannot answer all four is labeled an estimate. We hold our own numbers to the same rule; our post on audit findings patterns explains why a number without a method is a finding in its own right.
The automations running in Butler, the operations tool we built for PPC International, are purchase planning, end-of-day reports, wholesale shipping and order intake. None of them would make a keynote. Each was daily work that read from the ERP and the storefronts, wrote into the ERP only, and had a named person to approve it. Alongside them sits a support desk where the model drafts and a person approves the send.
PPC International is a Brdy Holdings portfolio company. Internal work on a business we own, not an external client reference, and the only deployment we can describe. The Butler write-up has the detail.
Who should be in the room
Fewer people than a steering committee, and different ones. The person who does the work today, because they know the exceptions that never made it into the process document. Whoever administers the system of record, in-house ERP admin or outside Odoo partner, because they know what the API will and will not carry. Whoever controls credentials and environments, because integration without them is a drawing. And the person who approves exceptions now, because that approval is what the software will have to reproduce.
The budget holder should read the output and attend the final session, not the workflow walkthroughs; people describe their own work more honestly when they are not performing for them.
How it feeds a build
The top-ranked entry becomes the scope of the first build, with nothing added. Its integration section is the first design document: the systems to read, the one to write, the fields involved. Its risk section becomes the approval design, and later the checklist for the security review before production. Its baseline becomes the measurement that tells you, once it has run for a while, whether it worked.
For most operations businesses the first build is a scheduled automation into the ERP, the shape described on our AI automation for ERP and ecommerce operations page. Where the item needs software with its own interface, approvals and connectors, it runs as a custom AI software engagement. Either way, the document is yours to take to another builder or your own team.
What it is not
It is not a slide deck of trends. You will not get a maturity model, use cases copied from another industry, or a recommendation to "explore" something. It is not a model selection exercise; which model to call is a late and reversible decision. It will tell you where you are not ready, and if you want to check that yourself first, our AI readiness checklist is the list we use. And it is not a commitment to build with us. If nothing on the list is worth building this year, the document says so and the engagement ends there.
For a step-by-step account of the assessment, from first inventory to final ranking, read what an AI opportunity assessment covers.
Common questions about AI strategy consulting
How is an AI opportunity assessment different from AI strategy consulting?
The assessment is how we do strategy. Instead of a general direction, you get a ranked list of specific operations work, each item with its value, integration and risk written down, in the order we would build them. The strategy is the order and the reasons for it.
Do we need clean data before the assessment?
No. Finding out which fields are reliable is part of the work. A candidate that depends on a field nobody maintains is ranked down or marked blocked, and the data fix is written up as its own item.
Will the assessment recommend building with Brdy AI?
Only where building is the right answer, and the document is written so you can take it to another builder or your own team. Where an off-the-shelf tool or an ERP configuration change does the job, it says that instead.
What if nothing is worth building?
Then the document says so and explains why: usually the work is too irregular, the systems cannot carry the writes, or the volume does not justify the integration. That is a legitimate outcome, and cheaper than finding it out after a build.
Tell us which operations work you suspect is automatable, and we will scope an assessment around it.