Choose your first business automation: a practical pilot scorecard

Choose a first automation that repeats often enough to measure, has clear inputs, and can fail without leaving a customer stranded. Before comparing software, identify who will own the workflow, what a successful handoff looks like, and how a person will take over. A small, observable improvement is a better first test than an impressive system nobody can safely stop.

This guide provides a practical scorecard for making that choice. It is a proposed decision aid, not a validated assessment or a promise of savings. You can complete it with an operations colleague and a few recent examples of real work; you do not need an AI subscription.

Start with a recurring problem, not a product

Write down three tasks people repeatedly chase: assigning incoming inquiries, transferring approved information between systems, or preparing a routine internal summary. Describe each as an event and a finished result. “Use AI for sales” is too broad. “Give each eligible website inquiry a named owner and visible next action” is something a pilot can test.

There is a reason to keep the first question practical. In the Federal Reserve Banks' March 2026 report, 54% of firms planning to adopt AI cited finding suitable tools as a challenge, and 37% cited implementation or training time.[1] The underlying survey ran in September–November 2025 and drew 6,525 responses from a nationwide convenience sample of employer firms with 1–499 employees; it was not a random sample of every US small business.[1] These findings provide context, not evidence that your business needs AI.

For each candidate, first ask whether a clearer procedure or an existing software rule would solve the problem. If the difficulty is that nobody has agreed who handles an inquiry, automating the handoff before deciding ownership is premature.

Apply the no-go checks before scoring

Some risks should not disappear inside a favorable total. Put a candidate on hold if nobody can authorize its data access, nobody can monitor exceptions, or the team cannot restore a usable manual process. Also hold work whose consequences need specialist review you have not arranged, such as regulated decisions or binding customer commitments.

Record the reason in plain language: “No approved source for prices” is useful; “not ready” is not. Specify what would clear the hold and who can confirm it. This turns a rejection into a concrete preparation task.

A pilot may become suitable if you narrow it. Drafting a suggested reply for staff review is different from sending a quote automatically. Creating an internal reminder is different from changing a customer's account. Score the smaller action on its own merits.

Use this six-part pilot scorecard

For each dimension, assign 0 for unresolved, 1 for partly established, or 2 for demonstrated with examples. Write one sentence of evidence beside every score. Unknowns receive zero until checked; optimism is not evidence.

Repeatability. Can the team describe the trigger and finishing condition consistently? A score of two requires recent examples following the same basic path. A task that changes meaning with every request needs process clarification before automation.

Input readiness. Are the necessary fields available, permitted for this use, and understandable? Two means you have inspected representative records, including incomplete ones, and know what to do when information is missing. Do not award it merely because the CRM has many fields.

Rule clarity. Can you explain the decision without relying on one person's unwritten judgment? Two means a colleague can apply the documented rule and reach the same result. Ambiguity may justify a review step, not necessarily an AI model.

Recoverability. Can you stop the workflow, identify affected items, and complete or correct them manually? Two requires a practical recovery walkthrough. An irreversible external action deserves more caution than a reversible internal draft, even if both take little time.

Ownership. Does a named person have time, access, and authority to handle failures, with backup coverage? Two means both people understand the assignment. “The team will watch it” should not earn that score.

Measurability. Can you observe the current workload and compare the pilot on handling time, completeness, and errors? Two requires a usable baseline and a defined observation window. A workflow that feels irritating but leaves no trace may need better records first.

Use the scores to compare candidates, not to calculate an automatic purchasing verdict. Prefer candidates with fewer unresolved dimensions. If two look similar, favor the one with less customer exposure and an easier manual fallback. A high total never overrides a failed no-go check.

Hypothetical example: choosing an inquiry-assignment pilot

Imagine a small commercial-cleaning office considering two projects: routing website inquiries to a coordinator, or generating and sending custom service quotes. This is an invented example, not a LogicWoven client or reported result.

For inquiry routing, the office can show recent submissions, a service-area list, and a primary coordinator. It cannot yet show backup coverage or a reliable record of assignment times. Its scorecard therefore records strong input and rule clarity but unresolved ownership and measurement. Before building, the manager names a backup and starts recording receipt and assignment events.

The quote project fails a no-go check: pricing exceptions live in the owner's memory, and an incorrect offer could create a customer dispute. A promising score elsewhere would not make it ready. The office postpones automatic sending and considers a smaller future task: preparing a draft from an approved price sheet.

The chosen pilot becomes specific: create or match the inquiry record, suggest the coordinator, and place ambiguous requests in a review queue. It does not decide price, promise availability, or send marketing messages. The choice follows the failure the team can manage, not the technology it wants to try.

Turn the choice into a one-page pilot agreement

Finish the worksheet with a short agreement. Name the trigger, eligible records, excluded records, allowed actions, reviewer, backup, and manual fallback. Identify the source of truth for each rule. State where the team will see successful items and exceptions.

Write acceptance conditions before the build. For example: every synthetic test inquiry must end with either a correctly assigned owner or a visible exception; repeated delivery must not create repeated work; pausing the automation must leave a recoverable queue. These are proposed tests, not claims that a particular tool already passes them.

Set a review date and a stop condition. An unauthorized message, unexplained missing record, or unresolved access issue can justify pausing even when the workflow otherwise looks faster. Specify who may restart it after the problem is understood.

Measure the full workload, then decide

Record baseline handling time and pilot handling time, including review, corrections, exceptions, and maintenance. Keep setup, subscriptions, integration work, training, and ongoing support in the cost discussion. Recovered staff time is capacity; it becomes cash savings only when an actual expense is reduced or avoided.

That distinction matters: 71% of AI users in the Federal Reserve survey reported increased productivity, while the vast majority reported no change in labor costs.[1] Those are self-reported experiences, not a forecast for your pilot.

At review, choose among continuing, repairing, simplifying, or stopping. A low-volume pilot may not provide enough evidence for an economic conclusion. It can still reveal missing rules or an unsafe handoff. Keep that learning separate from a claim of return on investment.

If inquiry routing is your candidate, the next practical step is testing the contact-form-to-CRM journey. Agree automation handover responsibilities while defining the pilot, so the person choosing it is not also silently accepting every future support task.

LogicWoven's workflow discovery and project planning services can help turn this worksheet into a bounded scope. Discuss one candidate workflow in a discovery call, bringing a sample record, the current steps, and the failure you need to avoid.