A useful first AI project starts with a task your team already understands: sorting incoming enquiries, preparing a weekly update or turning meeting notes into a reviewable task list. Give that task a clear finish line, then measure whether AI makes it easier to complete.

There is a timely reason to take this seriously. In its September 2026 small-business report, OpenAI describes a growing share of activity involving AI agents within its own products. That is evidence from one provider’s users, not a measure of every business or a promise of productivity. It does, however, make a practical question worth asking: which part of your team’s work could benefit from a controlled pilot? Read OpenAI’s September 30 announcement.

This guide proposes a two-week pilot for a small team. The schedule is a starting point; extend it if your task is infrequent or difficult to evaluate.

1. Choose one task with a visible outcome

Look for a repeated task with reasonably consistent inputs, an output somebody can check and a named owner. A good candidate might be preparing a draft summary of new sales enquiries, including the requested service and any missing information.

Write the finish line in one sentence: “Every new website enquiry becomes a reviewable summary with an assigned category, the original message and a suggested next step.”

Then record how the task works today. Time several normal examples, note where staff have to make judgments and collect the mistakes they already encounter. This gives you a baseline for deciding whether the pilot helps.

A weak candidate has an unclear owner, conflicting business rules or information scattered across systems nobody maintains. Resolve those issues first. An AI workflow still needs a process it can follow.

2. Decide how much freedom the task needs

An AI workflow can follow a fixed sequence: read a form submission, extract details, check required fields and prepare a draft. A more autonomous agent decides which steps or tools to use as it works. Anthropic’s foundational engineering guide draws this distinction and recommends adding complexity only when it improves results. Its original publication is from 2024; the architectural distinction remains useful even as specific tools change. See Anthropic’s workflow and agent definitions.

For the enquiry example, use ordinary rules to check whether an email field is empty. Use AI to interpret a paragraph describing the customer’s needs. Keep the routing sequence fixed while the team learns where interpretation is reliable.

Write down three things before building: what the system may read, what it may produce and what it must hand to a person. That one-page brief will make supplier discussions and implementation choices much clearer.

3. Build a draft that makes review easy

Consider this illustrative enquiry for a fictional design agency:

“We need a new website before our November event. We already have product photos, but the copy needs work. Can you send a cost?”

A useful draft could contain:

• Service: Website design, with copywriting support.

• Requested timing: Before a November event; exact date missing.

• Available material: Product photography.

• Missing details: Page count, event date, required features and budget.

• Suggested next step: Ask those questions before preparing an estimate.

The draft should link to the original enquiry so the reviewer can check it quickly. It should not invent a delivery date, infer a budget or promise a fixed price.

This example also reveals a valuable design choice: separate information supplied by the customer from suggestions produced by AI. A staff member should be able to tell which is which without rereading the whole message.

During the pilot, have a person approve any customer-facing reply. Make the approval specific: show the actual recipient, proposed text and any attachments together.

4. Set permissions that match the pilot

For a workflow that produces enquiry summaries, the connected account needs access to the relevant submissions and a place to save drafts. It does not need administrator access or permission to delete customer records. Ask your implementer to confirm the actual connector permissions, including whether reading and sending messages can be separated.

Also decide what happens when a submission contains instructions aimed at the AI. Customer text should be treated as information to process, never as permission to expand its access or change the workflow.

This is why access settings matter alongside prompts. Anthropic’s May 2026 engineering article explains how enforced boundaries limit what an agent can reach, and why model-level instructions cannot provide complete protection on their own. Read its containment guidance.

Keep the initial data set small and suitable for the tools your business has approved. Name the person who can pause the workflow and explain how normal enquiry handling resumes.

5. Test the awkward enquiries

A polished demonstration is only one example. Before using live submissions, assemble a small set of past enquiries with an agreed expected result. Remove personal information that the test does not need.

Include a straightforward request, several services in one message, a vague deadline, a complaint mistaken for a sales lead, missing contact details and a repeated submission. Add a message that asks the system to ignore its normal rules.

Check concrete outcomes: did it preserve the customer’s request, identify missing facts and choose a sensible category? Did it send an uncertain case to a person? Anthropic recommends starting evaluation with realistic cases and clear success criteria, then examining failures rather than relying on a headline score. Read its January 2026 evaluation guide.

Keep a short error log. “Incorrect service category” points to a routing problem; “invented price” points to a more serious boundary problem. Fixing them may require different changes.

6. Measure the work that remains

For each pilot enquiry, record the reviewer’s time, whether substantial editing was needed and whether the final result was usable. Count exceptions too: a workflow that saves time on simple messages but creates a large investigation queue may disappoint the people running it.

Use this simple calculation:

Net time saved = previous handling time − review time − correction time − a share of ongoing maintenance time.

For example, if a task previously took eight minutes and now takes three minutes to review plus two to correct, the provisional saving is three minutes before maintenance. Those numbers are illustrative; use your own observations before making a business case.

Keep software and usage costs alongside the time figures. Also record any useful work that became possible, such as consistently capturing missing requirements, without presenting it as a proven revenue gain.

Decide what earns a wider rollout

At the end of the pilot, review the errors and time records with the person doing the work. Expand the workflow only where the results justify it. A successful draft stage can remain a useful permanent tool; automatic sending is a separate decision with its own tests.

Before the next phase, leave the team with a named owner, a short operating guide, a way to pause processing and the examples used to test it. Recheck those examples when you change the model, instructions or connected tools.

If you are planning your first automation, bring three things to the initial discussion: one repeated task, a handful of representative examples and a clear definition of a good result. That is enough to begin designing a pilot your team can judge on its merits.