What Does an AI and Automation Discovery involve?

If you run a business and suspect the way work flows through it needs to change, the hard part is often not the fix. It's knowing where to start. Do you pick a tool? Ask someone about AI? Fix whatever has annoyed you most this week?

An AI and automation discovery is one way to answer that question before you spend money on any of those. I run these for businesses, and the people who ask about them often have the same three questions. I'll take them in turn.

Piwakawaka sculpture on Geraldine sculpture trail

Piwakawaka sculpure - part of Geraldine Sculpture Trail

"I think we need to change something, but where would we start?"

Often with the work itself, rather than with a technology.

A discovery follows a piece of work, such as an enquiry, an order or a job, from the moment it arrives to the moment it's finished, and pays attention to what happens along the way. Who touches it? What decisions get made? What documents get created? Where does someone retype something that already exists somewhere else? Where do things stall, or go wrong?

That sounds simple, and it is. But it's rarely written down anywhere. In many of the businesses I work with, the process lives in a handful of people's heads and is spread across an inbox, a few systems and a spreadsheet or two. Getting it onto a page is often useful before AI or automation enters the picture at all.

"I wonder what an AI and automation discovery actually involves?"

It runs in four steps, and it can all be done online with screen sharing, so nobody needs to travel.

1. Kickoff and access planning. We confirm who needs to be involved, what we'll look at and when, and how I'll be able to see the systems you use.

2. Working sessions. We walk through real enquiries from each way work arrives, from first contact through to a confirmed order and the handover to whoever delivers it. We look at each system and what it's actually used for (which is sometimes different from what it was bought for), and we note where information gets re-keyed. Along the way we sort what you need into must-haves, should-haves and nice-to-haves.

3. Analysis. On my own, I turn what I've seen into two things. The first is a plain-language picture of the information your business works with: customers, enquiries, quotes, orders, and how they relate to each other. The second is a list of where AI or automation could help, and where it wouldn't.

4. Readback and prioritisation. I present the findings back to your team and check I've understood things correctly. This step matters more than it sounds. It's where the people who do the work point out what I've missed or got wrong, and it's where priorities get agreed rather than assumed.

Not everything gets looked at. If part of the business is already working well, such as a factory floor that runs smoothly, I'll understand how it hands over to and from the rest of the process, but I won't try to redesign it.

What do you get at the end?

A findings document written for your business, not a generic report. It often includes:

  • how your current systems are used and how work arrives

  • the process as it runs today, from enquiry to confirmed order

  • a plain-language data model, so everyone shares the same picture of the information involved

  • an assessment of where AI and automation could realistically help

  • recommendations and a phased path, so change can happen in manageable steps rather than all at once

You also get transcripts and summaries of the sessions, where they were recorded.

Where automation isn't the answer

Part of the job is being honest about where AI and automation are not a good fit, or not worth it yet.

One example is a pricing spreadsheet that has been refined over years. It's well understood, it's trusted, and it often does more than pricing. Whether it should be replaced depends on the business. For some, the spreadsheet is simply how they have always worked, and the standard pricing tools in an off-the-shelf package could do the job. For others, it holds logic that would be costly to rebuild. Often the first question is whether it needs replacing at all, or whether connecting the processes around it is enough.

The same goes for AI. An assistant that helps someone find the right detail in a huge set of documents may deliver value sooner than one that tries to read everything and fill in records automatically. Which is right depends on the business, which is the reason for doing the discovery first.

“Does it commit me to using Teal for the next step?”

No.

A discovery is scoped and priced as its own piece of work. It doesn't assume any particular platform or product, and it stops before system design. The findings document describes your business (your concepts, your process, your pain points) rather than my tools, so it's written to be useful to whoever picks it up next.

That might be me. It might be another provider, your own team, or nobody for now. I do build on the Microsoft Power Platform, so I'll often have a view on where it could fit, and I'll say so openly. But I'd rather you made the next decision with clear information than felt steered towards it.

What does it ask of you?

Not much technical knowledge. You don't need to have chosen a tool or have a wish list of features. What it does need:

  • a small amount of time from the people who actually do the work

  • screen-share access (or screenshots) of the systems involved

  • a willingness to show the messy parts, because that's where the useful findings often are

Is it the right starting point?

It often suits you if:

  • you know something isn't working but can't say which piece to fix first

  • work moves across several systems that don't talk to each other, and people retype the same information

  • someone has asked "can AI help with this?" and you're not sure whether it's the right question

It may be less useful if you've already decided exactly what to build. In that case, the next step is probably scoping the build.

If you'd like to talk through whether a discovery makes sense for your business, get in touch.

We use the AI Contribution Scale defined by Blair Enns to disclose the use of AI in our written content.  This article is rated as: AI-4: AI Drafted. The content was drafted by Claude from our own content and ideas, we then refined the output.

Next
Next

AI Governance for Small Businesses: Where to Start