AI Readiness Assessment: Is Your Business Ready to Put AI to Work?

Imagine you run an advisory firm where a few experienced colleagues have become the unofficial answer desk. They know which template is current, where the guidance for an unusual client request lives, and why the document everyone keeps finding should no longer be used. People trust them, so people ask them. Over time, helping everyone else find information becomes a substantial part of their day.

An AI search assistant seems like a sensible way to give that time back. Your team could ask a question and receive an answer linked to the firm's own documents, without waiting for someone to point them in the right direction. While you're considering that idea, another colleague suggests using AI to handle client follow-ups: checking the client record, deciding when to get in touch, and sending the message.

Both proposals have an obvious appeal, especially if your team is already stretched. They also leave you with a familiar management problem. You can see how the technology might help, but you need to understand what you're agreeing to before you put it in charge of work that matters.

This is where an AI readiness assessment should earn its keep. It should help you work through a particular proposal, understand what it would ask of your business, and decide on a useful first version. At The Foregrounds, we think the most productive place to begin is with the work itself and the responsibility you intend to give the system.

In our hypothetical firm, the search assistant and the follow-up system may deserve different answers. One helps an employee find something they can check before using it. The other speaks on the firm's behalf, perhaps before anyone has seen what it intends to say. Your business hasn't changed between those two proposals, but what you're asking it to support has.

The useful details emerge when someone shows you the work

Before choosing a product, we'd want to spend time with the people who would use it. The written process is helpful, but watching someone complete a recent piece of work can explain things a process document leaves out. You begin to see which information they trust, where they pause, and when they turn to someone else.

Consider how a consultant at our advisory firm might prepare for a client meeting. The procedure says to review the client record. In practice, they also check a recent email and ask the account lead whether a sensitive issue has been resolved. The client record contains useful information, but the consultant knows it doesn't contain everything they need.

An AI-generated meeting brief could still be helpful here. It might assemble the background material so the consultant can spend more time considering the conversation ahead. The missing context becomes a design decision: the consultant needs to see what the draft drew from and have an opportunity to add what they know. If the same brief were circulated automatically, the system would need a dependable way to account for that information before it reached anyone else.

For a leader, this is a useful way to make an abstract assessment concrete. You are learning where assistance could remove effort, where judgment contributes value, and which information needs to be made available. Those findings give you something much more specific to discuss with a technology partner than a general ambition to become more efficient.

They also help avoid an unnecessarily large preparation project. Professional work involves interpretation, and you may be able to use AI productively while leaving that interpretation with an experienced colleague. You don't have to standardize every part of the job before exploring a useful assistant. You do need to understand enough of the job to decide where that person's involvement belongs.

The US National Institute of Standards and Technology takes a similarly contextual approach to risk in its voluntary AI Risk Management Framework. The intended use and potential consequences matter. Our practical recommendation follows from that: assess the proposed work directly, even if you have already completed a broader review of your firm's AI capabilities.

How much of the job are you ready to hand over?

Once you can describe how the work happens, the conversation about technology becomes easier. A workflow is the sequence between a starting event and a useful result, such as receiving a request and preparing a response. The next decision is how much of that sequence AI should carry out, and who decides what happens along the way.

You might begin with an assistant that prepares something for an employee to use. You could also build a fixed workflow that collects the relevant records, prepares a draft, and sends it for approval in a sequence you've defined. An agent has more discretion over the intermediate steps and tools it uses. Anthropic's practitioner guidance explains this distinction between predefined workflows and agents that can choose their process.

These choices give you different ways to solve the problem. An agent could search an approved library without changing a single record, while a simpler automation could send a mistaken message to an entire client list. We would pay close attention to the actions each design permits and the consequences if something goes wrong. The product label alone won't settle that decision.

For the internal search proposal, the firm could begin with a small collection of approved policies, methods, and templates. The operations director would identify the versions people should rely on, and the IT provider would check that each employee could access only the information they were entitled to see. Answers would link back to the relevant passages, allowing colleagues to inspect the basis for a recommendation.

There is preparation involved, but it has a manageable scope. The firm can test whether the assistant helps with recurring questions without reorganizing every folder it owns. When the system cannot find an answer, that becomes useful information about what the library needs next.

Client follow-up requires a different conversation. In our example, the account lead sometimes knows that a client has already been contacted or that a discussion is on hold, even though the record hasn't caught up. A message could be accurate in its wording and still arrive at the wrong moment. Once the client has read it, correcting the record won't undo that experience.

We would start by having AI prepare suggested follow-ups for the account lead, with the relevant records alongside each draft. That creates a useful opportunity to reduce preparation work while giving the person who understands the relationship the send decision. Permitted data use and system access still need to be resolved, but the first version no longer depends on the AI independently exercising all of the account lead's judgment.

The quality of that review step matters. A reviewer needs the evidence and time to make a decision; an approval button attached to an unverifiable answer adds little. Equally, once a person has approved a message, you may be comfortable letting the system save it to the designated record automatically. Thoughtful implementation includes deciding where an extra interruption would get in the team's way.

A promising first version still has to earn its place

By this point, you may have a proposal that feels much more achievable. The search assistant has a defined library, and the follow-up system has a reviewer. It is tempting to treat a good demonstration as confirmation that the hard decisions are behind you. There is still something important to learn, though: whether the system makes the team's work better once people use it on ordinary requests.

Alongside ordinary requests, we'd include incomplete questions and the awkward cases colleagues usually pass to someone more experienced. For the search assistant, a fluent answer is only part of the experience. The document it cites has to support the answer, be appropriate for that employee, and be current enough for the task. When the source material doesn't answer the question, the assistant should make that clear. Otherwise, colleagues may spend time checking a confident response that they would have been better off never receiving.

The comparison with today's work can be fairly modest at first. A small group could record how long they spend finding an accepted answer and which questions they abandon or pass to a colleague. During the trial, they would track comparable work, including the time spent checking sources and correcting the assistant. That gives you a fairer view of the benefit than measuring how quickly text appears on screen.

There is research to support taking that benefit seriously. In a field study published in the Quarterly Journal of Economics, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond examined AI assistance for 5,172 customer-support agents. Access increased issues resolved per hour by 15% on average, with larger gains among less experienced and lower-skilled workers. The most experienced and skilled workers saw smaller speed gains and small declines in quality. These were results from one company's customer-support operation, so they give us reason to investigate assistance while leaving the outcome for our advisory firm an open question.

That variation is also useful when thinking about your own team. You will want to understand who benefits, which requests become easier, and whether the improvement holds when the work becomes less familiar. An average can help describe the result, but the examples underneath it will help you decide what to change.

Before the trial, we'd agree on what would make the investment worthwhile. For a meeting brief, that could mean reducing total preparation time, including review, while maintaining the firm's existing quality standard. For a client deliverable, fewer revisions might matter more than faster drafting. The expected benefit needs to justify the costs of implementation, software, maintenance, and training, including the time your own people contribute. If the benefit is released staff time, consider how you'll use that capacity; cash savings or additional revenue will depend on what happens next.

This makes the decision after the trial easier to explain. A version that meets the agreed standard can earn a wider rollout. One that falls short can lead to a specific change or a decision to stop. With the reviewed follow-ups, for example, rejected suggestions and substantial edits would help show where the system still needs context. If the results eventually support automatic sending for a narrow class of routine messages, the firm can assess that next step with evidence from its own work.

The firm needs to be able to live with what it builds

Working through one proposal at a time is useful, although it creates a responsibility for leadership as more teams get involved. If each team chooses different tools, establishes its own information rules, and assumes someone else will provide support, even promising trials can leave the business with systems it struggles to maintain.

Some decisions are worth making once for the whole firm. Agreeing on approved tools, permitted information use, and support responsibilities gives each new project a clearer starting point. For a small business, that may begin with a short set of working rules and named people who can answer questions. As use expands, you can revisit whether those people have enough time and technical support to do the job well.

The employees using the system also need to understand what has changed. With the search assistant, they need to know how to inspect a source and report an answer that appears wrong. With the follow-up drafts, the account lead needs to understand what information the system considered and what remains theirs to judge. Training becomes more useful when it deals with those moments in the working day.

This is why we bring strategy, implementation, and training together at The Foregrounds. A decision made in an assessment eventually becomes a source collection, a permission, a review step, or a responsibility someone has to fulfill. Staying close to the build helps us work through those details, while involving the team helps establish whether the result is something they can use confidently.

Bring the conversation into a working session

You can begin this assessment with the person who owns the work, someone who does it regularly, and whoever understands the relevant systems and information access. Ask them to bring recent examples, including one that required extra judgment. Existing records and a walkthrough will give you more to discuss than carefully prepared statements about how ready the business feels.

The worksheet below brings those observations together. For each question, note the evidence you have and what still needs to be resolved, using ready, needs work, or blocked at the proposed scope. We use it as a discussion aid rather than assigning a numerical score that suggests it can predict success.

1. What starts this workflow, and what counts as finished? A short scope statement and representative requests. State what the first version will handle and what remains outside it.
2. Who can decide how the work should be handled? A named business owner who can settle exceptions and accept the result.
3. Where does the usual process need judgment? A walkthrough, existing checklist, and examples of cases that required a colleague's intervention.
4. Which information should the AI use? Actual source documents or records, their owners, and examples of conflicting or outdated material.
5. May that information be used in the proposed system? Applicable client restrictions, approved-use policies, and confirmation from the people responsible for information access.
6. What access does the system need? A list of applications and the exact permissions needed in each: reading, creating, editing, sending, or deleting.
7. What improvement would justify the investment? Recent volume and current staff time, turnaround, or rework. Agree on a minimum worthwhile gain and compare it with setup, software, maintenance, and team costs.
8. What would make an output acceptable? Examples of good and unacceptable results, with reasons a knowledgeable colleague can apply consistently.
9. Who will review work that needs judgment? The review point, the evidence a reviewer will see, and the time that person can make available.
10. What happens when the system cannot complete the job? Examples of missing information or failed steps, an exception owner, and a way for staff to finish the work manually.
11. How will you stop or correct a mistaken action? A practical stopping method, records of what happened, and a correction procedure. Identify actions that cannot reliably be undone.
12. Who will keep the system useful after the trial? A business owner, technical support contact, source-maintenance responsibility, and time for training and checking results.

As you work through the answers, the differences between the missing pieces should become clearer. An outdated template may be a small preparation task with an obvious owner. Unconfirmed permission to use client information needs to be resolved before that information enters the system, regardless of how encouraging the other answers are. Where independent action is the obstacle, you can return to the proposal and consider whether preparing work for a person would still deliver enough value.

The useful outcome is an agreed first version, with a person responsible for each preparation task and a clear way to judge the trial. You should be able to explain what the system will do, how it fits into the team's work, and what would justify taking it further.

If you'd like a partner in that conversation, our AI strategy work helps define the scope and responsibilities, and our knowledge systems work addresses the information a useful implementation depends on. Bring a piece of work your team would like to make easier, along with a few examples of how it happens today. We can work through the decisions from there.