A convincing demo can make the next purchase or build feel obvious. Before committing, write down what needs to change for the people using it, what the change depends on and what would make you choose another route. You can use this guide in a discussion or work through it on your own.
Start with the sections where your decision is unclear. Unknown is a useful answer when it points to the next thing to find out. The aim is a reasoned next step, which may be a process change, a smaller test or a decision to wait.
Go straight to the short decision worksheet
1. Describe the change you need
Name the person affected and the task they need to finish. Replace “we need an AI assistant” or “we need a new platform” with an observable change, such as making it easier for a customer to get a confirmed appointment.
What tells you there is a problem today? A customer account, a sample of delayed work and a measured pattern offer different kinds of evidence. Record what you have actually seen separately from what someone expects a new tool to achieve.
- Write one sentence: “For these people, we want this task to become easier or more reliable.”
- Choose a way to check the change, and something that must not get worse. Faster handling is less useful if it creates incorrect bookings or more follow-up work.
2. Understand the current workaround
Follow one real task from request to completion. Note who picks it up, which tools they use, where information is copied and what happens when the usual route fails. Ask why the workaround exists before trying to replace it.
Include the people who will have to change their routine. A new tool can remove one person’s work while creating an extra queue for someone else. Find out who can support the change and what time, budget, access and training are realistically available.
3. Check the dependencies before judging the promise
Ask the people responsible for the systems and information to confirm what is available. A supplier’s demonstration does not show that your data, permissions or connections are ready.
- Data: Where will the information come from? Is it current and complete enough for this task? Can you use it for this purpose, and who may access it? Use an authorized sample to investigate gaps.
- Connections: What must the tool read or update? Confirm access, supported interfaces, charges, rate limits and who will resolve failures. An exported spreadsheet is different from a reliable two-way connection.
- Ownership: Who checks exceptions, corrects mistakes and keeps the service running? Include training, support, subscription changes and a way to retrieve your information if you leave.
- AI behavior: Which mistakes would be tolerable, and which could harm a customer or business? Decide what a person must review and which actions the system must not take. Test ordinary and difficult examples. A successful demonstration is only one observation.
If permission, access or a consequential technical assumption is unresolved, give it a named question and an appropriate reviewer. Avoid treating it as a detail that will sort itself out after purchase.
4. Compare different ways to get there
Compare options against the same task and constraints. Include the work that remains after each option is introduced, as well as its setup and ongoing cost.
- Keep the current tools and change the process. Clear ownership, a simpler handoff or removing an unnecessary step may address the problem. Check whether the team has enough capacity to make that work.
- Extend something you already use. Configuration or an existing feature may be enough. Check its limits and whether it creates duplicate records or a fragile dependency.
- Buy an existing product. Look at fit, setup, migration, integration, ongoing fees and how you would leave. Verify the important workflow with your own permitted examples.
- Build something specific. Consider this when the difference matters enough to justify development and continued ownership. Include maintenance and specialist review in the decision.
- Defer the change. This can be sensible when the problem is small or the missing evidence could change the choice. Record the cost of waiting and a trigger for revisiting it.
AI may be part of an existing tool, a purchase or a custom build. Ask what useful capability it adds, how its output will be checked and whether a simpler approach would achieve the same outcome. Do not count adoption itself as success.
5. Choose a test that could change your decision
Pick the most important uncertain assumption. What evidence would make you proceed, narrow the idea or stop? A short observation, a manual trial or a supplier demonstration using permitted examples may answer it before a prototype is needed.
Agree the scope, maximum time or cost, who will review the evidence and when the decision will be made. Use representative conditions, including exceptions. If the test cannot distinguish between the options, change the test before spending on it.
6. Agree what the result will mean
- Proceed when the intended task improves enough to justify the effort, important dependencies have been checked and the agreed limits are met. A small trial may justify the next stage; it does not establish readiness for every customer.
- Change course when the evidence points to another cause or another option. For example, clearer routing may help, but a lack of staff capacity may still leave customers waiting.
- Stop or pause when the test cannot be run with the necessary permission, creates unacceptable errors or exceeds its agreed cost or effort. Record what happened rather than quietly changing the success criteria.
For changes that could affect safety, legal obligations or consequential business decisions, involve the relevant specialist before making commitments. A worksheet helps structure that conversation; it does not replace the review.
A hypothetical example: booking requests
This example is invented to show how to use the questions. It is not a client story, a completed trial or evidence of results. All quantities and criteria below are illustrative choices.
A repair business is considering an AI booking assistant because customers sometimes chase appointment confirmations. Staff currently pass requests from a shared mailbox into a calendar. The desired outcome is a confirmed next step for each customer, without incorrect bookings.
The cause is still uncertain. Requests might wait because responsibility is unclear, because staff lack capacity or because calendar information is difficult to check. The owner first proposes comparing a named booking owner, the calendar’s existing request feature, a purchased booking tool and a custom assistant. Automatic booking is deferred until calendar access and error handling are understood.
The proposed first test is a manual handoff rule for one week, capped at two hours of extra staff effort. With permission, the booking owner would review 20 representative requests and record the next action, waiting time, corrections and extra work. The comparison would use a similar sample from the current process. No customer messages would be sent to a new AI service.
Before the trial, the owner proposes proceeding to a wider process trial only if at least 18 of the 20 requests receive a confirmed next step by the next working day, with no incorrect bookings and no more than the agreed extra effort. If requests still wait despite clear ownership, the team would investigate capacity or calendar access. If it cannot inspect the requests with permission, or a booking error occurs, it would pause and review the cause.
The immediate decision is to authorize a bounded manual test, if the owner agrees its access, effort and review date. Buying or building an assistant remains a separate decision. No result has been observed in this example.
Copy the short decision worksheet
Select the text below and copy it into your own document or message. It works without a download, account or form. Leave confidential details out of documents you plan to share.
Decision to make:
People affected and the task they need to finish:
Current workaround and the problem we have observed:
Outcome to improve and how we will check it:
Options: keep/change process, extend, buy, build:
What each option leaves for people to do:
Data, permissions, connections and support needed:
Biggest assumption and evidence still missing:
Smallest useful test, its limits and maximum effort:
Proceed if / change course if / stop if:
Decision owner, reviewer and review date:
Next step, owner and what we are deferring:Leave with one clear next step
Summarize the choice in a few sentences: the task that should improve, the leading option and its trade-off, the uncertainty that matters most, and the next action with an owner and review date. Keep the unanswered questions visible. If there is not enough evidence to choose a solution, name the question to investigate instead.
Explore help with a software or AI commitment
Read about assessing a shared software investment
Read about responsibility when AI work crosses apps
Explore an education product model redesign
Plan the smallest software or AI pilot
Check an integration dependency before committing
Use the interactive companion
The builder follows the guide’s model. Your answers remain in this tab. The complete plain worksheet above remains available without JavaScript.