What AI discovery should actually uncover in your business

Search "AI readiness assessment" and you'll find a hundred firms ready to assess you. Most of what they're selling is a demo wearing a clipboard. You sit through two hours of tool talk, you get a slide deck with a maturity score on it, and six months later nothing in your business runs differently.

Here's the thing. The assessments aren't useless. Most of them never look at the only thing that matters: how work actually gets done inside your company.

Full disclosure before we go any further. I run Meet Caddy (Orbital Access, LLC), an AI deployment company, and discovery is the first thing I do with every customer. I built AI systems inside my own family of companies first: utility locating, military drones, manufacturing, real estate, healthcare. So yes, I have a horse in this race. Read this article as the standard you should hold anyone to. Including me.

What is AI discovery?

AI discovery is a structured examination of how work actually gets done in your business: where the hours go, where information moves between systems by hand, and where decisions wait on one person. Its job is to produce a short, ranked list of AI opportunities worth real money, backed by evidence and delivered in writing. If the output only makes sense as a step toward buying something, it was not discovery; it was a pitch.

Notice what that definition doesn't mention: models, tools, vendors. That's on purpose. The operation comes first, the tools come last, and the rest of this article walks through what the examination should actually cover.

Where do the hours actually go?

Every business runs on a story about how people spend their time, and the story is usually wrong. Job titles tell you what someone was hired to do. Calendars tell you what meetings they sat in. Neither one tells you about the Tuesday afternoon your operations coordinator spent pulling numbers out of one system, reformatting them in a spreadsheet, and emailing three people to ask whether a job closed.

Good discovery ignores the org chart and traces real weeks. It asks people to walk through yesterday instead of summarizing their job. It hunts for the work that repeats: the weekly report someone assembles by hand, the inbox one person triages every morning, the status question that takes four messages to answer.

Let me give you an example. I'm making this one up, but you'll recognize it. A property management firm takes every maintenance request by phone or email. Someone types it into the ticketing system. When the vendor invoice shows up, someone re-types the same details into accounting. Nobody designed that workflow. It built up one workaround at a time. Discovery's first job is to make work like that visible and put a number on it: hours per week, per person, at what cost to you. Rough numbers are fine. No numbers is not.

How much information moves between systems by hand?

If discovery only has time to examine one thing, this is the thing. In most operations-heavy companies, and I've watched this inside my own, the biggest pool of recoverable hours is people moving information from one system to another. CRM to spreadsheet, spreadsheet to invoice, email to project tracker, PDF to database. Copy and paste has quietly turned into a full-time job, and it shows up on nobody's org chart.

Every manual handoff costs you three ways: the labor itself, the errors that creep in along the way, and the queue that forms while the work waits for a human to get free.

Good discovery maps these flows end to end: where information enters the business, every point where a person re-keys or reformats it, and what breaks when that person takes a vacation. The finished map usually surprises the owner. It never surprises the people doing the work.

Which decisions wait on one person?

Some of the most expensive minutes in your company are the ones where nothing happens. The quote that can't go out until the owner blesses the price. The exception that waits on the one person who knows the history. The Monday pile of approvals that stalls everybody else's Tuesday.

The expensive part usually isn't the decision itself. It's the queue stacking up behind it.

And the fix usually isn't "let AI decide." The way I think about it, AI should prepare decisions instead of making them: it pulls the context together, drafts the answer, flags the exceptions, and hands a human a two-minute review instead of a forty-minute archaeology dig. Discovery should end with a list of your decision bottlenecks: who holds each one, how long the queue gets, and which ones are safe to prep automatically.

Which opportunities actually matter?

Here's the uncomfortable math. Most companies with real operations have 30 or more legitimate AI opportunities. Finding them isn't the hard part. The hard part is that a handful of them drive 90 percent of the difference, and the rest are a distraction dressed up as ambition.

The ones that matter share a shape. They touch recurring volume, weekly not quarterly. They attach to real dollars: revenue, payroll hours, working capital. And somebody inside the business owns the process well enough to say what correct looks like.

Watch out for demo bias here. The flashiest idea on the list (it's usually a chatbot) is rarely the one that moves a financial metric. The boring document flow that touches revenue every single day usually is.

A serious discovery process says no to most of its own list, in writing, with reasons. If everything made the cut, nothing was examined.

What makes an opportunity deployable instead of a science project?

Two opportunities can promise identical savings and carry wildly different odds of ever working. The difference is deployability, and honestly, testing for it is where the shallow assessments fall apart.

An opportunity is deployable when:

• The data it needs already exists, and someone can actually get to it.
• The process has a stable shape. It ran the same way last quarter and will run the same way next quarter.
• A human can verify the output quickly, so mistakes get caught while they're cheap.
• A named person will own it after it's built, and that person helped design it.
• It fails gracefully. A bad day means rework, not a crisis.

It's a science project when it needs data you don't collect, when it automates a process that changes weekly, when it needs a reorg before it matters, or when nobody on your team can check the output. Science projects are fine for labs. You're running a business.

Ask whoever assesses you to label every opportunity one or the other, and to defend the label.

What are the signs your discovery process is shallow?

If you keep one thing from this article, keep this list.

• The tool demo came before any questions about your operation.
• The recommendations would fit any company in your industry. Nothing proves anyone looked at yours.
• Only leadership got interviewed. Nobody sat with the people who do the work.
• There are no numbers. No hours, no volumes, no costs, not even rough ones.
• Every problem they found happens to match the product they sell.
• The opportunity list is long and unranked. Thirty ideas, no verdict.
• Nobody asked where your data lives, what shape it is in, or who can access it.
• Nothing was disqualified. A real assessment says "AI is the wrong fix here" at least once.
• You walked away with a slide deck instead of a document someone could execute.

One of these is survivable. Three or more means you're in a sales funnel, not a discovery process.

What should exist in writing when discovery ends?

Discovery that lives in someone's head works for them, not for you. When the process ends, you should be holding, at minimum:

• A process map. The workflows examined, with hours, manual handoffs, and decision queues marked.
• A ranked opportunity list. Each entry names the manual work it replaces, estimates the value with stated assumptions, and lists what it needs: data, system access, people.
• A deployability verdict on every item. Buildable now, buildable with preparation, or science project.
• The shortlist. The few opportunities worth building first, and the reasoning.
• The rejects. What got disqualified and why. This is the fastest way to audit someone's judgment.
• A measurement plan. Which metric each build should move (hours reclaimed, cycle time, error rate, response time) and how you'll know. Numbers a CFO would accept.
• An ownership line. Who on your team runs each system once it's live.

Then apply the only test that matters: could you hand the document to any competent builder, including one who doesn't work for the firm that wrote it, and have them execute? If yes, you got discovery. If no, you got marketing.

What should you do next?

Hold everyone to this standard. Ask for the writing. Ask what got disqualified. Ask which items are science projects and why. People doing serious work will enjoy those questions. People running a funnel will get vague.

And since I already showed you my horse: this is how I run Meet Caddy. It starts with a free discovery call, 30 to 45 minutes on which processes cost you the most and where AI can actually move the needle. If it makes sense to keep going, a free architecture call comes next, where I map your operation live, process by process, in front of you. Then you get a scoped proposal for exactly what I found. If you want it built, the engagement is a standard 90-day agreement: discover, build, adopt, optimize, with your team trained and the system deployed at the admin level of your own Anthropic plan. You own it. I leave.

The discovery call is free at meetcaddy.com. Bring your messiest process.

And if you talk to someone else instead, take this article with you.