Is Your Firm Actually Ready for AI?¶

The questions to ask before you spend a dollar on AI, with a 2-minute readiness scorecard.

Most AI projects fail before a single line of code is written. Not because the technology doesn't work. Because nobody asked the right questions first. A firm buys a tool because a competitor mentioned it, wires it to nothing, and six months later it's shelfware with a renewal bill.

AI adoption isn't a purchase. It's a diagnosis. You interrogate the business until the bottleneck, the data, the people, and the money all point at the same one thing. Then you build.

These are the questions I ask to run that diagnosis. They work whether you're an accounting practice, a chain of gyms, a logistics broker, or a law firm, because they probe how a business actually makes and loses money, not the buzzwords.

The journey, in one picture¶

You cannot skip stages. A firm that jumps from "we want AI" straight to "implement" is the firm that ends up with shelfware.

flowchart LR
    A[0. Diagnose<br/>maturity] --> B[1. Audit<br/>current state]
    B --> C[2. Map<br/>opportunities]
    C --> D[3. Prioritize<br/>impact vs risk]
    D --> E[4. Assess<br/>readiness]
    E --> GATE[4.5 Governance<br/>gate]
    GATE --> F[5. Shape<br/>the solution]
    F --> G[6. Pilot &<br/>measure]
    G --> H[7. Adopt,<br/>ROI & scale]
    H -.next process.-> C

Each stage below has a purpose (what you're trying to learn), the core questions (ask these of any firm), and, where it matters, a "listen for" note telling you what a good or worrying answer sounds like.

Stage 0: Diagnose the maturity rung¶

Purpose: know which rung they're standing on before you plan the climb. The right next move for a "rung 1" firm is wrong for a "rung 4" firm.

Ask:

1. Who in your firm uses AI tools today, and for what, officially or unofficially?
2. Is there anything AI or automation touches that would actually break the business if it stopped tomorrow?
3. Do you have a written AI policy, a budget line for it, or a named owner?

Why we ask: These three low-threat questions place the firm on the ladder without making them self-diagnose. Q1 surfaces shadow AI: who's already reaching for it unprompted, which doubles as a heat-map of where the pain is. Q2 tests whether anything real depends on automation yet (toy vs. integrated). Q3 checks whether there's an owner and a budget, meaning whether there's actually a buyer in the room, or just an enthusiast.

Listen for: "A few people use ChatGPT but we don't really talk about it" = rung 1. That's the most common answer, and it's a gift: there's demand with zero structure.

Stage 1: Audit the current state¶

Purpose: understand the business before you say the word "AI." If you can't name where time and money leak, you can't justify a build, and everything downstream is built on a guess.

Ask:

1. Walk me through what your firm actually does day to day: the three or four workflows that make you money.
2. Where do your best-paid people spend time on work below their pay grade?
3. What's the task everyone dreads, the one that piles up and creates the backlog?
4. Where do errors, rework, or "we missed that" happen most often?
5. What takes your firm days that a client wishes took minutes?
6. If you could hire three more people tomorrow, what would you put them on?
7. What documents or data do you touch constantly, and where do they live?
8. What decision does your team make over and over, using the same kind of information each time?

Why we ask: You're building a leak-map in the firm's own words, before AI enters the conversation. The "below their pay grade" and "hire three people" questions expose the real bottleneck, the work you'd automate toward, while the dreaded-backlog and rework questions find where cost and risk actually pile up. The last two quietly identify the digital, pattern-based raw material AI can act on. If they can't answer these concretely, they're not ready to buy. They're ready to be audited.

Listen for: Question 6 is the bottleneck detector. Whatever they'd hire for is usually the thing to automate toward. Question 8 finds the repeatable, pattern-based work AI is genuinely good at.

Cut it by function. One probe each, to make sure nothing's hiding:

• Operations / delivery: Where's the manual handoff between steps or systems?
• Finance / back office: What's re-keyed from one place into another?
• Sales / client-facing: How much of a first response is copy-paste?
• Marketing: What content or reporting eats hours every week?
• Hiring / HR: How much time goes to screening, scheduling, onboarding paperwork?
• Compliance / quality: What gets checked by hand that follows a checklist?

Stage 2: Map the opportunities¶

Purpose: turn the pains you just heard into candidate use cases. Not all pain is AI-shaped.

Ask:

1. Of everything we just listed, which is highest-volume and most repetitive?
2. Which tasks follow rules or patterns, versus needing real human judgment?
3. Where is the input already digital text, documents, or numbers (not locked in someone's head)?
4. Which of these pains, if solved, would your clients actually notice?
5. Which one, if solved, would free up your time the most?

Why we ask: This is the filter that turns a pile of pains into a shortlist of things AI can actually do. You're separating rule-and-pattern work (AI-shaped) from judgment work (not), and checking the input is already digital. Those two things decide feasibility. The client-notice and free-up-your-time questions add the second axis: which fixable pain is also worth fixing. Anything scoring on both axes is a candidate; everything else is a distraction.

Listen for: The sweet spot is a task that is high-volume + pattern-based + already-digital + low-stakes-if-wrong. Circle anything that hits all four.

Stage 3: Prioritize: impact vs. effort vs. risk¶

Purpose: pick the one thing that pays back fastest and safest. Momentum beats ambition on the first project.

Ask:

1. If we fixed exactly one thing in the next 90 days, which pays back fastest?
2. What is this problem costing you today: hours × rate, lost deals, penalties, churn?
3. What happens if the AI gets it wrong here: mildly annoying, or dangerous / regulated?
4. Is there a high-volume, low-risk corner where we can prove value before touching anything sensitive?

Why we ask: You're forcing a single first bet and pricing the problem out loud. The "one thing in 90 days" question kills the temptation to boil the ocean; the cost question converts a vague annoyance into a dollar figure that later justifies your fee. The "what if it's wrong" question sorts safe, high-volume proving grounds from regulated blast-radius work, so the first project builds momentum instead of risk. You're choosing where to be right first, not where to be most ambitious.

Listen for: Put a dollar figure on the problem out loud with them. "So this is costing roughly $X a month" reframes the whole conversation from expense to return, and it sets up value-based pricing later.

Sort each candidate into one of four boxes: payback against effort-and-risk. Your first project should come from the top-left. The bottom-right is where AI budgets go to die.

Stage 4: Assess readiness¶

Purpose: the idea can be perfect and still fail if the data, people, systems, money, or rules aren't ready. Check all five.

Data¶

1. Where does the relevant data live, and who can actually get to it?
2. Is it clean and structured, or scattered across PDFs, emails, and spreadsheets?
3. How much of the real knowledge is in someone's head rather than a system?
4. Is there data you can't put into a third-party AI service, whether by law, client contract, or your own policy?

People¶

1. Who would own this internally once it's live?
2. Who's the champion who wants it, and who's the skeptic who'll resist it?
3. How does the team feel about AI: excited, threatened, or indifferent?

Systems¶

1. What core software runs the business: CRM, ERP, accounting suite, booking/PMS?
2. Do those systems have APIs, or is everything through the screen?
3. Who manages IT: in-house, an outside provider, or nobody in particular?

Budget & authority¶

1. Who signs off on this, and what size of "yes" is easy versus a board conversation?
2. Do you see this as a cost to cut, or capacity to add? (This one frames pricing.)

Risk & compliance¶

1. What rules actually govern this data: privacy law (e.g. GDPR), sector regulation (e.g. HIPAA for health), a security standard you're contractually bound to (e.g. PCI DSS for card data), financial-reporting controls (e.g. SOX), client confidentiality, contracts with your own clients? (These are different kinds of obligation, a law vs. a regulation vs. a contractual standard, so don't lump them.)
2. What would a client, auditor, or regulator need to see about how a decision was made?

Why we ask: A perfect use case dies on any one of five missing foundations, so you're stress-testing all of them before committing. Data questions reveal whether the raw material is reachable and legal to use; people questions find your champion, your blocker, and who'll actually own it; systems questions tell you whether integration is an API call or a screen-scrape. The budget/authority pair confirms there's a real buyer and frames pricing, and the rules questions size the compliance load before it becomes a surprise. Any weak leg here is the thing to fix first, not the AI.

Listen for: If the answer to Q3 is "mostly in Sandra's head," that's not a blocker. It's the project. Capturing tribal knowledge is one of the highest-ROI things AI does.

Stage 4.5: The governance gate¶

Purpose: before anything touches production, decide how you'll run it safely. This is the section most firms skip and most regret. A perfect use case with no governance isn't ready to go live. It's a liability waiting for its first bad output. "Human in the loop" is a slogan; these questions are the actual controls.

Ask:

1. Who approves a use case before it goes live, and who is accountable once it's running?
2. How do you classify the data involved (public, internal, confidential, regulated), and who made that call?
3. What do the vendor's data terms actually say: is your data used to train their models, where is it stored, who can see it?
4. How will you check the output is right (spot-checks, a review threshold, a set of known-answer test cases), and who owns that check?
5. What's the escalation path when it gets something wrong, and who gets told?
6. Is there a log of what the system did and why, if a client or regulator ever asks?
7. Who watches it for drift or quality drop after launch, and how do you shut it off in a hurry?

Why we ask: These questions convert "human in the loop" from a comforting phrase into named, testable controls. You're uncovering whether anyone actually approves and owns the thing, whether the data was classified before it left the building, and what the vendor really does with it. Those are the three places liability hides. The output-check, escalation, log, and kill-switch questions establish that the firm can catch and stop a bad output, not just hope it won't happen. If these answers are vague, the use case isn't production-ready no matter how good it is.

Listen for: "We'll figure that out later" is the answer that sinks projects. Governance isn't paperwork. It's the difference between a tool you can defend to a client and one you have to quietly switch off.

Stage 5: Shape the solution¶

Purpose: decide the form before the function: build vs. buy, integrated vs. standalone, how much human stays in the loop.

Ask:

1. Is there an off-the-shelf tool your peers already use, or is your process unique enough to justify something custom?
2. Should this live inside a tool you already pay for, or stand on its own?
3. Human-in-the-loop or fully automated: where do you want the line for this task?
4. How will people actually touch it: in their existing screen, a chat, an email, a report?

Why we ask: Now that the what is settled, you're deciding the shape, and mostly protecting the client from overbuilding. The off-the-shelf-vs-custom and inside-an-existing-tool questions test whether a cheap existing product already solves 80%, which earns trust even when it costs you the bigger build. The human-in-the-loop line sets the automation boundary they're actually comfortable with, and "how will people touch it" makes sure the solution lands in a screen they already use, the single biggest predictor of whether it gets adopted.

Listen for: Most firms overestimate how custom they are. If a $50/month tool solves 80% of it, say so; credibility now buys the bigger project later.

Stage 6: Design the pilot & define success¶

Purpose: a pilot with no metric is a demo. Nail the number before you build.

Ask:

1. What does "this worked" look like as one number in 60–90 days?
2. What's the baseline today, so we can prove the lift?
3. Who are the two or three people we pilot with first?
4. What's your kill criteria: at what point would you say "stop, this isn't working"?

Why we ask: You're turning a hopeful project into a measurable experiment before a line of code is written. The "one number" and "baseline" questions force a before-and-after you can actually prove. Without them, "it worked" is just a feeling. Choosing the two or three pilot users picks your friendliest, highest-signal testers, and agreeing kill criteria up front gives everyone permission to stop cheaply if it's not working. A pilot without these is a demo you'll struggle to bill against.

Listen for: If they can't state a baseline, that's step one of the pilot: measure the current state for a week. You can't prove ROI against a number nobody wrote down.

Stage 7: Adopt, prove ROI, and scale¶

Purpose: shipping the tool is the easy part. Getting humans to actually use it, and proving it paid, is where most projects quietly die.

Ask:

1. How will you get the team to actually use this instead of reverting to the old way?
2. Who owns it after launch: updates, monitoring, the weird edge cases?
3. How will you measure ROI in a way you can put in front of the partners or the board?
4. Once this works, what's the next process it unlocks?

Why we ask: This is where you find out if the win survives contact with real humans and turns into a second project. The adoption question surfaces the revert-to-old-ways risk that kills most tools; the ownership question makes sure someone maintains it after you leave. The ROI-for-the-board question arms your champion to defend the spend, and the "next process" question deliberately opens the door from a one-off build to an ongoing relationship. You're engineering the case study and the follow-on at the same time.

Listen for: Question 4 is where a one-off project becomes a relationship. The first win should always point at the second.

Vertical add-ons¶

The core questions above work in any firm. These go a layer deeper into each industry's mechanics, the specific places that sector tends to lose time, money, and margin.

Accounting & professional-services firms¶

1. What share of staff time goes to data entry, categorization, reconciliation, and document-chasing versus actual advisory work?
2. In busy season, where's the true bottleneck: bookkeeping, close, tax prep, audit sampling, or client Q&A?
3. How do you collect documents from clients today, and how much chasing does it take?
4. What's your stance on AI touching numbers that end up in a filing? Where does a human have to review?
5. Which ledger and practice-management systems do you run: QuickBooks, Xero, CCH, Karbon, something older?

Common win: client-document intake + auto-categorization + a review gate. High volume, painful, and the human stays on the numbers that matter.

Multi-location chains (gyms, clinics, retail, hospitality)¶

1. Across locations, what's inconsistent that head office wishes were standard?
2. Where do you lose customers: signup, retention, rebooking, no-shows?
3. Which hurts most: scheduling, staffing to demand, inventory, or member support?
4. How much member communication is still done manually, per location?
5. Is your POS / booking / membership data centralized, or siloed site-by-site?
6. Do you forecast demand and seasonality with data, or by gut?

Common win: centralize the per-location data first, then automate member comms and demand-based staffing. The data unification often is the project.

Adapting to any other vertical¶

Swap the nouns, keep the skeleton: What's high-volume and repetitive? What's regulated? Where's the data? Who's the skeptic? What's the one number? Every industry answers those differently. The questions don't change.

The 2-minute readiness scorecard¶

This isn't a points tally where a high score wins. It's a gate: the value boxes tell you whether it's worth building, and the safety boxes tell you whether you can put it in production. You don't get to trade one for the other.

How to read it:

• Value boxes mostly empty → you're at audit stage. Slow down; map the business first.
• Value boxes checked, any safety box empty → pilot in a sandbox if you like, but you are not ready for production. The empty safety box is the work.
• Every safety box checked and value is clear → you're ready to implement in production, and to run it, not just launch it and hope.

The gate in one picture. Note that value alone never reaches production:

flowchart TD
    S([Candidate use case]) --> V{Is it worth<br/>building?}
    V -- No --> A[Back to audit:<br/>map the business]
    V -- Yes --> G{Every safety<br/>box checked?}
    G -- No --> P[Pilot in a sandbox only<br/>the empty box is the work]
    G -- Yes --> PROD[Implement in production]
    P -. close the gap .-> G

What to do with your answers¶

If you filled this out and most boxes are blank, that's not bad news. It means you've been spared an expensive false start. The order matters: audit → pilot → scale. Firms that respect that order get compounding wins. Firms that skip it buy tools.

If you'd like a second set of eyes on your answers, or you want someone to run this interview with you and turn it into a 90-day plan, that's exactly the work I do. Get in touch and send me your scorecard.