[Firm name] AI tool scoping canvas: [tool name]
Replace everything in [square brackets].
Canvas details
| Item | Detail |
|---|---|
| Tool name | [Working name] |
| Idea from | [Name, role] |
| Owner (accountable for it working) | [Name, role] |
| Date | [Date] |
Framework credit: DRAFT and the three problem questions are from Nick Ferguson (Strategic Group), "From AI Idea to Real App: How to Move Beyond Proof of Concept", The Firm’s AI in Practice Summit, June 2026 (thefirm.media/summit/sessions/from-ai-idea-to-real-app).
1. The problem
| Question | Our answer |
|---|---|
| What outcome are we solving for? (the result, not the task) | [Outcome] |
| How we will know it worked (a measure we can check) | [Measure] |
| Who has this problem today, and how often | [People, frequency] |
Weak: "Build an AI to help with our clients." Strong: "Draft client-ready replies to tax queries, using our prior advice and our tone guidelines." The second tells the AI what to ask next: where the prior advice lives, whether it has access, and what client-ready means.
2. The data and the context
| Data needed | Where it lives now | Format | Data tier |
|---|---|---|---|
| [e.g. New client details] | [e.g. Practice management system, onboarding form] | [e.g. Form export, table] | [Public, internal, de-identified, identified, restricted] |
| [e.g. Prior advice letters] | [e.g. Document store folder] | [e.g. Word files] | [Tier] |
| [Data] | [Where] | [Format] | [Tier] |
| Knowledge and constraints | Our answer |
|---|---|
| Rules it must follow (AML, privacy, our AI policy) | [Answer] |
| Client experience limits (e.g. do not email the client more than once) | [Answer] |
| Anything it must trigger elsewhere (e.g. create a job in practice management) | [Answer] |
| Terms we must define (what counts as pass, fail or neutral) | [Answer] |
| Existing models, workpapers or spreadsheets it should use rather than invent | [Answer] |
Accountants have an advantage here: you already have spreadsheets and workpapers that set out exactly how a calculation works. Hand the AI your model instead of letting it invent one.
3. Scope it with DRAFT
| DRAFT question | The choices | Our answer |
|---|---|---|
| D: Who is it for? | Just me; my team; the whole firm. Just you means half the rest of this canvas does not apply yet. | [Answer] |
| R: What records does it touch? | Public information; firm IP; confidential client data. Each step up adds security work. | [Answer] |
| A: How much autonomy? | Drafts for a person to review and send; acts on its own (clicks, sends, updates). Autonomy drives complexity. | [Answer] |
| F: How does it fit our systems? | Standalone; reads from or writes to practice management, the ledger, the document store. Each connection needs permission to pull data out. | [Answer] |
| T: Who does it transfer to? | Stays with the builder; handed to a manager, the IT provider or a developer after a pilot. A handover needs documentation. | [Answer] |
Read the answers together. "Whole team, client data, reviews before it acts, talks to our client systems, handed to IT" is a project of a couple of months that probably needs a developer. "Just me, internal data, drafts only, standalone" is something you can build in an evening.
4. The smallest version worth building
| Item | Our answer |
|---|---|
| The stepped-down version (who, which data, drafts only) | [Answer] |
| Test data we will use (sample or de-identified) | [Answer] |
| Tool we will build it in (on the firm’s approved list) | [Answer] |
| What would prove the problem statement right | [Answer] |
| Build by | [Date] |
Build it for yourself, confirm it works, then think about scaling back up. Run it on test data unless the tool is on a firm-managed business plan your data rules allow for client data.
5. What good looks like
- It has a use case and a named owner.
- The data inputs and their structure are defined.
- It produces the same output for the same input, and we have tested that on [number] runs.
- It works where the people are, inside the workflow they already use.
- Someone governs it over time: who changes it, who checks it still works.
6. Before the team uses it
The localhost trap: a tool built on your account, with your data, your permissions and your context, works for you and nobody else. Before anyone else relies on it, answer each line.
| Needs | Our answer |
|---|---|
| Where the data is stored (somewhere central, not one browser or laptop) | [Answer] |
| How each person logs in and is identified | [Answer] |
| Version control, so a change can be rolled back | [Answer] |
| Monitoring, so we know when it breaks | [Answer] |
| An AI plan with business data terms for any client data | [Plan, and where we read its terms] |
| Governance: owner, reviewer, review date | [Names, date] |
| Cost to run for the team (seats, usage, hosting) | [Estimate] |
Check plan terms against your own AI policy and data rules; vendor terms change. This canvas is a planning tool, not security or legal advice.
7. Decision
| Item | Detail |
|---|---|
| Build the small version? | [Yes or no] |
| Pilot with | [Names] |
| Review date | [Date] |
| Approved by | [Name, date] |