What Happens in the First 30 Days of an AI Implementation?

A useful first month establishes the problem, defines a narrow responsibility, builds and tests a pilot, and decides whether the team is ready to operate it. The pace depends on access, decisions, data and complexity. Thirty days is an illustrative planning window, not a guaranteed delivery promise.

I would rather finish the month with one well-understood process than several impressive demonstrations with nobody responsible for what happens next.

The calendar should follow the work's readiness. It should not pressure the team into calling an untested system complete.

Days 1 to 7: understand the job

Choose the process and its owner. Observe how the work happens today, including the shortcuts people use when the documented procedure does not fit.

Collect representative examples with the appropriate permission and protections. Record the starting effort, common errors and unresolved work. This creates a baseline for later judgement.

Then write an acceptance statement. In a fictional service business, it might be: “Every eligible website enquiry produces an assigned record with the information our coordinator needs to take the next step.”

The word “eligible” needs a definition. So do “assigned” and “information.” Working through those details is part of discovery, even when it looks less exciting than building.

Days 8 to 14: design and build a bounded pilot

Separate the work into information, rules, AI-supported interpretation and human decisions. Identify the approved sources and the permissions each action requires.

Build the smallest version that can demonstrate the agreed responsibility. Keep unrelated requests on a separate backlog so they do not quietly change the project.

Write the test cases before declaring the build ready. Include ordinary inputs, missing information, conflicting information, a failed connection and a request for human help.

The deliverable at this stage is a testable pilot. It should not be described as a completed operational system simply because the first example worked.

Days 15 to 21: test the behaviour and the evidence

Run the agreed cases and record what actually happens. Inspect the resulting records, messages and assignments, not just the system's explanation of its own actions.

When a test fails, classify the cause. Was the source wrong? Was a rule missing? Did access fail? Was the expected result unclear? Different causes need different corrections.

Retest the changed path and any nearby behaviour it could affect. Keep a compact issue log with an owner and resolution evidence.

If the remaining issues affect customer promises, permissions or lost handoffs, continue testing. A date on the plan is not a reason to accept an unresolved material defect.

Days 22 to 30: supervise, hand over or hold

If the readiness checks pass, introduce the pilot within an agreed operating boundary. Give the team a way to pause it and a clear place to report unexpected behaviour.

Review a sample of actual use. Watch the effort required to supervise and correct the work. An apparent time saving can disappear if somebody quietly spends every afternoon repairing the outputs.

Finish with a decision and a handover, or a documented reason to hold.

What can change the timeline?

Delayed access, unclear policy, unreliable data and unavailable decision-makers can all change the schedule. So can an integration that behaves differently from the initial assumption.

Make those dependencies visible early. Agree who resolves each one and how scope or dates change if it remains open.

The first month should leave the business with more clarity, not a new collection of mysterious automations. Even when the right result is a smaller scope, you should understand why.

If you are considering an implementation, book a conversation with me and bring the process and the person who owns it. That is enough to start planning a useful first phase.