What happens in an AI discovery workshop

Most businesses that come to Frontrow asking about AI have already decided on the wrong first step. They want to know which Copilot licence to buy, or whether an agent can be built for a particular task someone saw demonstrated at a conference. Both are reasonable questions. Neither can be answered honestly until someone has mapped what the business actually does, hour by hour, in the workflows nobody has written down.

That mapping exercise is what an AI discovery workshop is for. It is a structured, half-day to full-day session where the people who do the repeatable work in a business walk through that work in detail, in the room, with someone whose job is to listen for where the hours are going and where a tool or an agent could take the load. It produces a ranked list of opportunities, not a recommendation for a product. The recommendation comes later, once the list exists.

Why the workshop exists at all

The plain reason is that you cannot automate what you haven't mapped. A business leader knows, in general terms, that the finance team spends too long on month-end reconciliation, or that the sales team re-types the same proposal sections every week, or that the compliance queue never clears. What they usually don't know is which specific step in that process is the actual time sink, what data it depends on, what the workaround looks like when the system doesn't cooperate, and whether the fix is a five-minute Power Automate flow or a six-week Copilot Studio build.

That level of detail only comes from the people doing the work. Not because leadership doesn't understand the business, but because the workarounds live below the level leadership sees. The spreadsheet someone built three years ago to patch a gap in the CRM. The email chain that exists because two systems don't talk to each other. The report that gets manually reformatted every Friday because the export doesn't match what the board wants. An AI discovery workshop exists to surface exactly that layer, because it's where most of the achievable automation and AI opportunity actually sits.

Who needs to be in the room

The most common mistake in how businesses scope this kind of session is inviting the people who run the business rather than the people who do the repeatable work inside it. A leadership team can describe strategy accurately and workflow detail badly, not through any fault of their own, they are several steps removed from the keyboard. A workshop that only includes department heads produces a list of aspirations. A workshop that includes the people who actually process the invoices, answer the tickets, chase the approvals and build the reports produces a list of opportunities that are real, sized, and fixable.

• The people who do the recurring, high-volume work in each function, not just their manager, the person who actually processes it week to week
• At least one person from each function under discussion, finance, HR, operations, customer service, sales admin, whichever functions are in scope for the day
• Someone who owns the relevant systems (the ERP, the CRM, the practice management platform), because half the opportunities are constrained by what the data actually looks like
• A leadership sponsor, present for framing at the start and the readout at the end, but not required to sit through every workflow walkthrough in between
• Whoever currently owns the workarounds, the spreadsheet builder, the person with the macro nobody else understands, they usually know more about where the gaps are than anyone else in the building

A workshop with six to ten people across two or three functions is more productive than one with twenty people across the whole organisation. Depth beats breadth on the day. If a business has six functions worth examining, that's two or three separate sessions, not one long one where everyone is half-listening for their own turn.

What actually happens in the session

The format is deliberately unglamorous. There is no slide deck about the future of AI. The session opens with ten minutes of framing, what the day is for, what won't happen (no product is being sold or recommended in the room), and how the output will be used. Then it moves straight into workflow walkthroughs.

Walking through real workflows, not descriptions of them

Each participant walks through a real, recent example of the work they do, on screen where possible, step by step. Not "we process invoices", but this invoice, from this vendor, arriving in this format, checked against this reference, approved by this person, entered into this system. The facilitator's job is to keep asking "then what happens" until the workflow is fully exposed, including the parts that are mildly embarrassing to admit to, like the spreadsheet that shadows the official system, or the step that only works because one person remembers to do it manually every time.

This is where the workarounds and spreadsheets surface. Almost every organisation Frontrow has run a discovery workshop for has at least one unofficial system, an Excel workbook, a shared mailbox rule, a personal OneNote, that is doing real operational work the official systems were supposed to do. These aren't failures to flag for criticism, they're some of the best evidence in the room. A workaround that has survived for two years because it solves a real gap is exactly the kind of thing an agent or an automated workflow can absorb properly.

Quantifying where the hours go

For each workflow surfaced, the session puts a rough number on it: how often it happens, how long it takes, how many people touch it, and what happens when it goes wrong. This doesn't need to be precise to the minute, a workshop is not a time-and-motion study, but it needs to be honest. "A few times a week" and "most days, twice a day" are different answers with very different implications for whether an automation is worth building.

The number that matters most isn't the time per instance, it's the time per instance multiplied by frequency multiplied by the number of people doing it. A five-minute task done twice a day by one person is a minor irritation. The same five-minute task done by fifteen people, twice a day, each, is several hours of the organisation's time disappearing daily into something that could very plausibly be handled by a Power Automate flow or a scoped Copilot Studio agent.

Separating annoying from expensive

Every workshop surfaces a mix of the two, and they are not the same thing. Annoying work is the task everyone complains about because it's tedious, formatting a report, chasing a signature, re-keying a field between two systems. It's unpleasant but often low stakes, and fixing it earns goodwill without necessarily moving the needle on cost or risk. Expensive work is the task where a delay or an error has a real consequence, a compliance deadline missed, a customer response that takes three days when it should take three hours, a vendor risk assessment that never quite gets done properly because there isn't time.

The workshop's job is to keep these separate on the list, not to rank everything by how loudly people complained about it. The loudest complaint in the room is not always the highest-value fix. A quiet compliance gap that nobody mentions until directly asked is often worth more to resolve than the noisy irritation everyone has been grumbling about for a year.

What comes out of it

The output of a well-run AI discovery workshop is a ranked opportunity list, not a proposal. Each item on the list has a short description of the workflow, an estimate of the time and risk currently attached to it, a rough view of the fix (a configuration change, a Power Automate flow, a Copilot Studio agent, a data cleanup that has to happen first), and a rough sense of effort. Opportunities are typically grouped into quick wins that can be actioned inside existing licensing within weeks, and larger builds that need scoping, budget approval, or a data readiness step before anything gets built.

This list is what feeds a roadmap. It is deliberately not a set of purchase recommendations delivered on the day. A business that walks out of a discovery workshop with a Copilot licence order already signed hasn't had a discovery workshop, it's had a sales pitch wearing a workshop's clothes. The point of separating discovery from recommendation is that the ranked list can be checked against budget, against IT capacity, against what the data actually supports, before anyone commits spend.

How this differs from a strategy offsite, and from a self-serve quiz

A strategy offsite is a leadership conversation about direction. It answers questions like which markets to pursue, what the operating model should look like in three years, and where investment priorities sit. It is valuable, and it is a different exercise entirely. An AI discovery workshop is not a debate about strategic direction, it is a factual mapping exercise conducted with the people closest to the work. The two can inform each other, but running one instead of the other produces the wrong kind of output. A leadership team debating AI strategy in the abstract, without the workshop underneath it, tends to land on either "we need a Copilot rollout" or "we need to wait and see", neither of which is grounded in what the organisation's actual workflows can support.

A self-serve readiness assessment, the kind completed online in five or ten minutes, is a different tool for a different job. It scores a business against dimensions like data hygiene, governance, workflow maturity and adoption capacity, and gives a fast, honest read on where the organisation stands before any conversation happens. It is a useful first step and it costs nothing but time. What it cannot do is sit in a room and ask "then what happens" fifteen times until a real workflow is fully exposed. The workshop and the assessment are complementary, not competing, most businesses are better served doing the quick assessment first and using it to decide whether, and when, a full workshop is worth the day.

How to prepare so the day is actually productive

A discovery workshop is only as good as the access and honesty brought into the room. A short amount of preparation makes a material difference to what comes out of it.

1. 1Confirm the right people are invited, the doers, not just their managers, for each function in scope
2. 2Ask each participant to bring one real, recent example of the work they do most often, not a description from memory
3. 3Set the expectation in advance that workarounds and shadow spreadsheets are welcome information, not something to hide or apologise for
4. 4Have someone available, even briefly, who can speak to what the core systems (ERP, CRM, practice management, finance platform) can and can't currently do
5. 5Block the full session length without other meetings competing for the same people, a workshop interrupted every twenty minutes produces a shallow list
6. 6Agree in advance what happens with the output, who reviews the ranked list, and on what timeline it turns into a roadmap decision

Frequently asked questions