An AI readiness assessment should decide what problem deserves investment, what must change before implementation, and who will own the result.
It should not end with a maturity score, a list of tools, or a sales proposal disguised as analysis. A useful assessment produces a portable blueprint: a map of the current workflow, an inventory of the required data and access, a ranked set of use cases, a knowledge-base schema, and a staged build sequence with owners and guardrails.
The buyer should be able to use that blueprint whether the next step is do it yourself, hire another provider, or decide not to build.
If your team is still sorting attractive ideas from implementation-ready problems, begin with the AI project readiness scorecard.
1. Decide what should happen next
The assessment exists to support a business decision. Before discovery begins, name that decision in plain language:
- Which recurring workflow should be addressed first?
- Does the workflow need process redesign, deterministic automation, an AI-assisted step, or no new system?
- Which prerequisites must be resolved before implementation?
- What evidence would justify moving forward?
- Who owns the business rules, the implementation, and the ongoing operation?
- What is the smallest safe first release?
The answer may be “not yet.” That is a valid result when the source information is unreliable, the process changes every week, access cannot be controlled, or nobody owns the outcome.
Microsoft’s AI Readiness Assessment examines strategy, governance and security, data, organizational capability, infrastructure, and model management. Those organizational dimensions matter, but a service-business assessment should also connect them to one concrete operating decision. Readiness is not an abstract level. It is readiness for a specific workflow, under specific conditions, with a specific owner.
2. Map the workflow and the revenue leak
Start with observed work, not a preferred product. Interview the people who perform and receive the work. Review a representative sample of records. Follow the process from trigger to completion, including the side channels and exceptions that a clean process diagram often misses.
For each step, capture:
- the trigger, input, decision, output, and handoff;
- the person and system currently responsible;
- wait time, rework, duplication, and common failure modes;
- customer or revenue consequences when the step fails;
- exceptions that require judgment;
- controls or approvals already in place.
A “revenue leak” should be documented as an observable break in the operating system: qualified inquiries waiting without an owner, proposals built from inconsistent pricing, renewal signals not reaching the account lead, or completed work failing to trigger billing. Do not invent dollars recovered. Record the volume, frequency, affected records, and business consequence that the company can verify.
The assessment should also challenge the current process. In the source Build With AI episode, an 18-step workflow is simplified before automation is considered. That is the right sequence. Automating avoidable steps preserves waste and makes future maintenance harder.
3. Inventory data sources, access, and owners
Every proposed use case depends on information and permissions. The assessment should identify both before recommending a build.
For each source, record:
| Field | What to document |
|---|---|
| Source | System, folder, database, inbox, or person |
| Purpose | The decision or output this source supports |
| Authority | Whether it is canonical, supporting, or only an example |
| Owner | Person responsible for accuracy and access |
| Freshness | How often it changes and when it becomes stale |
| Quality | Missing fields, duplicates, conflicts, and known gaps |
| Sensitivity | Customer, employee, financial, contractual, or regulated information |
| Access | Required account, role, scope, and approval |
| Retention | How long inputs, outputs, and logs may be kept |
Then test the proposed path. Can the system use a limited account? Can it start read-only or in draft mode? Does the integration expose only the records required for this function? What happens when credentials expire, fields change, or a source is unavailable?
“The information is in Google Drive” is not an inventory. A build needs named sources, authority rules, permissions, and responsible owners. If the source-of-truth problem is larger than the initial workflow, the assessment should define the first knowledge cleanup rather than hide the gap inside a prompt.
4. Rank use cases by evidence, feasibility, and risk
An effort-versus-impact matrix is useful, but it is only a first pass. Rank each candidate across a fuller decision set:
| Factor | Question |
|---|---|
| Business consequence | Which revenue, reliability, knowledge, or capacity problem changes? |
| Evidence quality | Which observed records, volumes, failures, or stakeholder reports support the problem? |
| Frequency | How often does the workflow occur? |
| Process readiness | Is the current process understood and stable enough to improve? |
| Data readiness | Are the required sources authoritative, current, and permitted? |
| Technical feasibility | Can the required systems support the inputs, actions, and monitoring? |
| Risk | What can go wrong, and how costly or reversible is the result? |
| Ownership | Who approves, operates, maintains, and measures the workflow? |
| Learning value | Will a small release resolve an important uncertainty? |
Record the evidence beside every score. A polished recommendation generated from one interview is still a hypothesis. Tool-directory listings are not proof of security, reliability, integration depth, or fit.
OpenAI’s guide to identifying and scaling AI use cases recommends connecting use cases to business priorities and validating them through practical experimentation. For the buyer, that means the ranked list should show why one workflow comes first, what uncertainty remains, and what the first release is intended to learn.
5. Define the knowledge-base schema
The assessment should specify what the proposed system needs to know and how that knowledge will be governed. This is a schema, not a request to upload every company file.
For the selected workflow, define:
- knowledge types, such as policies, services, pricing rules, procedures, customer context, exceptions, and approved examples;
- required metadata, including source, owner, effective date, sensitivity, and review date;
- authority rules for conflicting sources;
- retrieval boundaries for different roles, customers, or workspaces;
- correction and approval workflow;
- freshness and retirement rules;
- citations or traceability required in the output.
The schema should serve people as well as software. A new employee should be able to understand which source governs a decision. A reviewer should be able to trace an output back to approved material. An owner should know when a policy change requires an update.
If the organization needs to choose a small, low-risk tool before designing a wider system, the minimal AI tool decision guide offers a narrower starting point. The assessment should not inflate a contained problem into an unnecessary platform.
6. Sequence the build, ownership, and guardrails
The blueprint should translate the selected use case into stages with an acceptance decision at each boundary.
- Prepare: simplify the workflow, clean the initial sources, confirm owners, and write acceptance criteria.
- Prototype: use representative but controlled inputs to test the core decision or output.
- Pilot: run with limited users, permissions, records, and consequences; keep human review in the loop.
- Operate: add monitoring, incident response, reconciliation, fallback, change control, and an ongoing review cadence.
- Expand or stop: use observed evidence to decide whether to broaden scope, revise the design, or retire it.
Each stage should name:
- the client business owner;
- the implementation owner;
- required human approvals;
- allowed and prohibited actions;
- success and stop criteria;
- logs and measurements;
- manual fallback;
- incident, rollback, and reconciliation responsibility;
- maintenance triggers when policies, data, integrations, or models change.
NIST’s AI Risk Management Framework Core frames lifecycle work as Govern, Map, Measure, and Manage. The NIST AI RMF Playbook provides suggested actions for applying those functions. An assessment does not need to turn a small workflow into an enterprise compliance exercise, but it should make governance, context, measurement, and ongoing risk response visible before launch.
For a practical staged rollout after the decision is made, use the workflow-first implementation sequence.
7. Keep a portable blueprint
The assessment deliverable should belong to the buyer. At minimum, keep:
- the current-state workflow and failure map;
- source-data, access, sensitivity, and owner inventory;
- ranked use cases with scoring criteria and supporting evidence;
- the proposed knowledge-base schema;
- the target workflow and implementation stages;
- acceptance, stop, and measurement criteria;
- approval, escalation, incident, fallback, and maintenance responsibilities;
- open questions, dependencies, and declined alternatives;
- estimated software and implementation inputs with assumptions clearly labeled.
The blueprint should separate facts, decisions, assumptions, and recommendations. It should also explain which parts will expire. Integration capabilities, product pricing, policy requirements, and source freshness may all change.
This prevents the assessment from becoming a presentation that only makes sense when its author is in the room. Another qualified team should be able to understand the proposed system, challenge its assumptions, and continue the work.
8. Ask an implementation partner these questions
Before approving a build, ask:
- Which business decision will this assessment help us make?
- How will you observe the real workflow instead of relying only on stakeholder memory?
- What evidence supports the problem ranking and any expected impact?
- Which process steps should be removed or redesigned before automation?
- How will you identify authoritative data and resolve conflicting sources?
- Which accounts, permissions, and sensitive information would the system require?
- What can begin read-only, in draft mode, or behind human approval?
- Who owns policy, implementation, monitoring, incidents, maintenance, and change approval?
- What acceptance and stop criteria will be written before the pilot?
- What will we receive if we choose another provider or decide not to implement?
- Which assumptions need validation during a prototype or pilot?
- How will outcome claims be measured against a documented baseline?
Return My Time does not currently have a measured client case study proving outcomes from its AI readiness assessment. The framework above describes the intended assessment blueprint and a buyer standard; it is not proof of revenue gained, time saved, conversion improved, or margin increased. Seller income, pricing, conversion, and financial-impact claims discussed in the source episode are not buyer outcomes and are not used here.
You can browse the Build With AI podcast archive for more implementation conversations. If you want a decision-ready blueprint for your own workflow, book an AI Readiness Assessment. That CTA begins a discovery and qualification conversation. Qualified buyers then discuss the scope of a paid assessment; submitting the form is not an immediate purchase or a guarantee that implementation is the right next step.
