What a Useful AI Consultation Should Deliver in the First 30 Days

Many organisations are now under pressure to "do something with AI". Senior teams can see competitors talking about copilots, chatbots, knowledge assistants and automated analysis. Staff can already reach for general-purpose tools on their own. Vendors are adding AI labels to almost every platform. The risk is not lack of enthusiasm. It is starting the conversation at the wrong level.

A useful AI consultation is not a brainstorm about every possible use case, and it is not a slide deck that promises transformation without exposing the delivery effort. It should leave an organisation with something much more valuable: a realistic view of where AI can help, what needs fixing first, what should be ruled out, and what a sensible first phase looks like.

In practice, the first 30 days should reduce ambiguity, not increase it. By the end of that period, leadership should be able to decide what to fund, what to defer and what conditions need to be met before AI is introduced into a live process.

Why so many AI conversations drift

Most AI discussions lose direction because they begin with the technology instead of the operational pressure. The questions become: which model should we use, do we need a chatbot, can we build a copilot, should we buy a platform, what about agents? Those are not useless questions, but asked too early they create noise.

The more important questions usually come first:

• Which workflow is currently too slow, too manual or too inconsistent?
• Where do staff spend time summarising, classifying, drafting or searching?
• What source data or documents would the AI need to rely on?
• How would a user know whether the output is trustworthy?
• Who would own the process once the tool is live?

If a consultation does not answer those points, the organisation often ends up with an impressive demo and no delivery path. The pilot stalls. The data is not ready. Security or compliance teams step in late. Users do not trust the output. The backlog of "next fixes" grows larger than the original business case.

Start with workflow, data and risk, not model choice

The right starting point is usually a small number of repeatable business problems. AI is most useful where teams deal with high volumes of text, repeated judgement, fragmented information or slow manual triage. It is much less useful where the underlying process is still undefined or where the data is so inconsistent that no one agrees what "correct" looks like.

A consultation should therefore map the process before recommending the tool. That means understanding the handoffs, systems, documents, controls and decision points that shape the work today. Without that, it is difficult to tell whether AI will remove effort or simply sit on top of a broken process.

This matters because most valuable AI use cases are not standalone. A drafting assistant depends on approved source content. A service chatbot depends on a maintained knowledge base. An internal copilot depends on access rights, structured data and clear escalation rules. A document classification workflow depends on well-defined categories and an operational owner who will deal with exceptions.

What the first 30 days should actually produce

A credible consultation does not need to solve everything in one month. It does need to produce a set of concrete outputs. In most organisations, the first phase should deliver at least five things.

1. A prioritised shortlist of use cases

Not every good idea belongs in phase one. The shortlist should rank use cases by business value, feasibility, implementation effort and operational risk. Usually that leaves a few strong candidates and a longer list of items that are interesting, but not yet ready.

A good shortlist is specific. It does not say "use AI in customer service". It says something like "draft first responses for common inbound enquiries using approved source articles, with human review before send" or "classify inbound documents into known categories and route them to the right team with confidence thresholds".

2. A readiness view of the underlying data and systems

AI readiness is often really data readiness in disguise. The consultation should identify where the source material lives, whether it is current, how it is structured, how access should work and what dependencies exist between platforms. If the intended use case needs documents from SharePoint, records from a CRM, finance data from an ERP and status updates from a bespoke tool, that complexity must be surfaced early.

This is also where some ideas should be stopped or reshaped. If the source content is duplicated, stale or contradictory, the right recommendation may be to fix the knowledge base first. If operational data moves inconsistently between systems, the right first phase may be an integration or reporting layer before any AI assistant is added on top.

3. Clear risk and governance boundaries

The consultation should make it obvious where human approval is required, what content can be used, what cannot be exposed to public models, how outputs are checked and what evidence trail is needed. These are not edge concerns. They are part of the delivery scope.

That is particularly important for regulated sectors, public-facing services and any process that touches contracts, finance, HR records, safeguarding, health data or policy guidance. The question is not whether AI can produce an answer. It is whether the organisation can govern the answer responsibly.

4. A practical first-phase delivery candidate

By the end of the consultation, there should be one recommended first implementation target with a clear owner, a measurable success condition and a bounded delivery scope. This is the difference between a consultation that informs action and one that only generates interest.

The best first candidates are usually narrow enough to control, but valuable enough to matter. They remove repeated effort, improve speed or consistency, and fit into an existing operational workflow without forcing the whole organisation to redesign itself around the pilot.

5. A roadmap that sequences prerequisites, pilot and scale-up

The roadmap should not assume that every idea moves straight to build. It should separate prerequisites from delivery. For example, the first phase might require source-content clean-up, access-control design, prompt and policy rules, integration work, or a reporting layer that gives the AI dependable operational context.

A roadmap you can actually deliver is usually phased. It shows what can be done now, what needs preparation, what should wait until the organisation has stronger data or governance, and what success needs to be proven before a wider rollout is justified.

What good first-phase use cases tend to look like

When organisations ask where AI can add value quickly, the strongest candidates are often more modest than expected. They are not usually "replace a whole team" ideas. They are structured opportunities where speed, consistency and retrieval matter.

• Knowledge retrieval for internal teams. Staff need fast answers from approved policies, manuals, service guidance or delivery documentation.
• Assisted drafting for repeatable content. Teams produce similar summaries, updates, responses or first drafts that still need human review.
• Classification and routing. Incoming emails, forms or documents need to be sorted, tagged or passed to the right queue faster.
• Summarisation of high-volume material. Meetings, tickets, notes or case updates need concise operational summaries.
• Decision support over trusted operational data. Teams need faster visibility into project, service or reporting status using a controlled data source.

These patterns work because the problem is clear, the users are identifiable and the organisation can judge whether the output is useful. They also make it easier to define guardrails. A narrowly scoped internal assistant with curated source material is usually a better first step than a broad public-facing tool expected to answer anything.

What a consultation should rule out early

One of the most valuable outputs in the first 30 days is a list of ideas that should not move forward yet. That is not a failure. It is a sign that the consultation is doing its job properly.

Early AI work should usually be deferred if:

• the source data is incomplete, contradictory or poorly owned
• the process changes every week and has no stable operating model
• there is no clear business owner for the output
• the organisation has not decided how sensitive data can be handled
• users would have no practical way to review or correct errors
• the proposed scope crosses too many systems for a first phase

These conditions do not mean AI has no place. They mean some groundwork needs to happen first. A good consultation should say that directly rather than forcing a pilot into an environment that will not support it.

How to turn the consultation into a delivery plan

The first month works best when it follows a disciplined sequence rather than a generic workshop cycle.

1. Weeks 1 and 2: identify the workflows that matter, the friction points inside them and the documents or systems the AI would need to rely on.
2. Week 2: score candidate use cases against value, feasibility, data readiness, governance complexity and user trust.
3. Week 3: define the first target architecture, including source systems, access rules, review points, exception handling and measurement.
4. Week 4: turn the findings into a phased roadmap with one recommended first implementation, clear prerequisites and success metrics.

That final step is where the consultation either becomes actionable or dissolves into general interest. The roadmap should show what will be built, who needs to be involved, what dependencies need to be cleared, how long the first phase is likely to take and how the organisation will know whether it worked.

What leadership should be able to say afterwards

At the end of a useful consultation, the leadership team should be able to answer a short set of practical questions with confidence:

• Which two or three AI use cases are worth pursuing first?
• Which one is the best first delivery candidate, and why?
• What data, content or integration dependencies need to be addressed first?
• Where do we need human review, governance or policy controls?
• How will success be measured in operational terms, not just technical ones?
• What should we deliberately not attempt yet?

If those answers are still vague, the consultation has not gone far enough. The point is not only to understand AI better. It is to make a better delivery decision.

Why this approach reduces cost as well as risk

There is a commercial reason to work this way. AI projects become expensive when the organisation discovers core dependencies too late. Teams then spend time reworking prompts, changing source content, fixing permissions, redesigning workflows or adding review steps that should have been scoped from the start.

A stronger consultation phase avoids some of that waste. It helps the organisation invest in one bounded use case with the right conditions around it, rather than spreading effort across several half-ready ideas. It also creates a clearer route from pilot to wider rollout because the delivery model, governance and technical dependencies have already been surfaced.

That is especially important for organisations balancing AI ambition with legacy systems, complex document estates, operational reporting or multi-team approval processes. In those environments, a realistic roadmap is far more valuable than a broad set of promises.

Conclusion

A useful AI consultation should do more than explain what the technology can do. It should identify where AI genuinely fits, where it does not fit yet, and what the organisation needs in place before the first implementation starts.

If the first 30 days produce a prioritised shortlist, a clear readiness view, practical guardrails and one delivery candidate that can actually be built, the consultation has done its job. That is the point where AI stops being a talking point and starts becoming a deliverable programme.