A first project should solve one measurable business problem, not promise a complete AI transformation. Here is a worked, fictional example of a tightly scoped engagement you can adapt.
Start with a narrow outcome
Your first AI consulting project should be small enough to finish, easy enough to test, and valuable enough for the client to care. A good candidate is a recurring workflow with digital inputs, a clear owner and a human who can review the result. A poor candidate is an autonomous system that makes sensitive decisions without oversight. You do not need to build a custom model to deliver useful consulting work. You do need to diagnose a problem, agree on scope, manage expectations and produce evidence.
The distinction matters because a new consultant can spend weeks experimenting with tools and still have nothing a business can use. Begin with the decision the client needs to make: should we keep doing this task manually, improve the process without AI, or test a supervised AI-assisted version? If the answer is not yet known, the engagement may be an assessment rather than an implementation. For more on getting the opportunity in the first place, see our first-project experience guide. This article focuses on delivery after the client agrees to explore a project.
Fictional example: a five-person service business
Illustrative scenario—not a real client or documented result. Imagine Cedar Lane Property Services, a fictional five-person maintenance company. Its office coordinator receives 45 incoming service requests each week. Requests arrive through email and a website form, and the coordinator manually extracts the address, problem category, urgency and preferred contact method into a spreadsheet. Missing details lead to follow-up messages.
The owner wants faster intake, not an autonomous dispatcher. The proposed project is a supervised workflow that drafts a structured intake record and flags missing information for staff review. The system must never promise an appointment, quote a repair price, or classify a safety emergency without a human. The baseline is measured before any tool is introduced: average handling minutes per request, percentage requiring correction, and number of incomplete records. Those figures are measured, not guessed, during discovery.
Define the scope in writing
A usable scope statement is specific: “Evaluate and pilot AI-assisted extraction of incoming maintenance-request details into a review queue for one office coordinator over two weeks.” The output is a draft record for human approval, not a completed customer transaction. State what is excluded: scheduling, emergency triage, pricing, customer-facing messages, database changes and any processing of sensitive records not approved by the owner.
Name the decision maker, day-to-day owner and reviewer. Record the systems involved and whether the client owns the accounts. Decide where test data will come from and whether it contains personal information. The discovery call guide helps gather this information, while the proposal template shows how to document the boundaries. A signed agreement should identify deliverables, acceptance criteria, payment, intellectual property, confidentiality and change requests.
Two-week project plan
Days 1–2: discovery and baseline. Interview the coordinator, observe real intake, record common exceptions and document the existing steps. Identify what a correct record looks like. Collect a small sample of approved, appropriately handled requests. If real customer data cannot safely be used, create representative synthetic cases.
Days 3–4: design and risk review. Map the proposed process from incoming message to human-approved record. Decide where the AI is allowed to draft and where it must stop. Establish access controls, retention requirements, logging and a manual fallback. Check whether ordinary forms, rules or templates could solve the problem more cheaply.
Days 5–7: build and test. Configure the prototype in client-approved tools. Test straightforward requests, ambiguous messages, missing addresses, duplicate submissions, unusual attachments and instructions embedded in incoming text. Track each error and revise the workflow rather than celebrating a single successful demonstration.
Days 8–9: supervised pilot. Let the coordinator review outputs while retaining the old process as a fallback. Time the actual work, including corrections. Keep the sample and evaluation method consistent enough to compare with the baseline.
Day 10: handover and decision. Deliver documentation, a test summary, known limitations, access inventory, training and a recommendation: expand, revise or stop. This is an illustrative schedule, not a universal delivery promise.
Sample deliverables the client can inspect
Provide a one-page problem statement with baseline measures; a current-state workflow map; a proposed workflow with human checkpoints; a data-and-access inventory; a small test-case register; a working supervised demonstration; a results scorecard; and a handover guide. The deliverables should be understandable without the consultant present.
For each artifact, identify its owner and an acceptance test. A workflow diagram is accepted when the coordinator confirms it matches reality. A test register is accepted when it includes both successful and failed cases. A pilot is accepted only if the owner can reproduce the approved workflow and safely revert to the original process. Our consulting deliverables guide contains a more detailed register. Do not substitute a polished slide deck for tested operational evidence.
Build a budget without pretending it is a market quote
Illustrative budget only: suppose the consultant estimates 18 hours of work at an internal planning rate of $85 per hour, giving $1,530 in labor value. Add an estimated $120 in approved tool and testing costs, for a planning total of $1,650. That is a cost model, not a recommended client fee, market benchmark or earnings claim. A fixed project price might differ because it includes business overhead, contingency, scope risk and profit.
The proposal should make clear who pays for ongoing subscriptions and what happens if the pilot requires extra integration work. Never hide the cost of future maintenance. If the client requests an entirely new customer-facing automation halfway through, use a written change request. Our hourly-versus-project pricing guide explains when fixed fees are appropriate. The business model guide explains why revenue is not take-home income.
Measure the result honestly
Suppose the fictional baseline is eight minutes per request and the supervised pilot averages five minutes including human review. Across 45 requests per week, that suggests 135 minutes of capacity recovered weekly if the pattern holds. It does not mean the business has automatically saved wages or gained profit. Check whether error rates increased, whether staff actually use the tool and whether exceptions create hidden work.
Define a minimum acceptable threshold before the test. For example, the owner might require no unauthorized customer messages, no lost records, accurate extraction on an agreed proportion of test cases, and an observable reduction in review time. If safety-critical requests are misclassified, stop the pilot and redesign. See how to measure project success and AI ROI for small business for complementary approaches.
A practical first-project checklist
Before accepting: confirm the business problem, process owner, budget authority, data permission, written scope, success criteria and fallback. Before building: document current steps, collect a baseline, classify risky decisions, agree on tools and test edge cases. Before handover: demonstrate the workflow, record failures, train the owner, transfer documentation, revoke unnecessary access and state ongoing costs.
A useful consultant also knows when to say no. If the client wants an autonomous system making legal, financial, employment or safety decisions without review, the right first project may be a governance assessment or referral to a specialist. If the data cannot be used safely, pause. If the task is too infrequent to justify the effort, recommend a simpler fix. Protecting the client from an unsuitable project is part of the service.
Turn delivery into credible proof
With written client permission, document the original problem, scope, your contribution, the test method, limitations and the final decision. Remove identifying data and do not disclose confidential information. If permission is unavailable, write a private learning retrospective or recreate the method using synthetic information, clearly labelled as a demonstration. Never invent a testimonial or present hypothetical numbers as client results.
A concise case study explains why this particular problem was chosen, what alternatives were considered, where humans remained responsible and what evidence supported the recommendation. That is more convincing than claiming to be an expert in every AI platform. Our portfolio guide shows how to present proof without exaggeration.
Five questions that keep the engagement manageable
Before work begins, ask the owner what happens when the proposed system is wrong. If the answer is “we will figure it out,” the scope is not ready. Decide whether a human catches the error before it affects a customer, whether the previous workflow can be restored and whether staff know whom to call. These are not technical afterthoughts; they are part of the project design.
Ask what would make the client reject the project even if the demo looks impressive. Maybe staff cannot afford the review time, customers dislike the new process, or the owner cannot maintain the tool. Capture those deal breakers in the acceptance criteria. An honest consultant should be willing to recommend stopping a project when the evidence does not justify proceeding.
Ask who will maintain the system after delivery. A client-owned account, documented permissions, a short operator guide and a named business owner matter more than a sophisticated prototype controlled entirely by the consultant. If the client cannot explain how to pause the workflow, handover is incomplete.
Ask what information is needed to prove the result. Time estimates made in a meeting are weaker than a short observation of real work. Compare the same types of cases before and during the pilot, and include the time spent checking AI output. Do not extrapolate one unusually successful test to an annual savings claim.
Finally, ask what is explicitly outside the agreement. A limited intake prototype should not quietly turn into a scheduling system, customer database migration or autonomous sales agent. If the client wants more, describe a new phase with separate cost, scope, risk review and approval. This protects both sides and gives the project a realistic chance of being completed.
References and next steps
The NIST AI Risk Management Framework offers a useful structure for identifying and managing AI risks. The U.S. Small Business Administration business-management guidance is useful background for tying technology decisions to ordinary operating needs. The OWASP LLM Top 10 explains security concerns such as prompt injection that deserve attention when processing untrusted messages.
The takeaway is straightforward: your first project should be a manageable decision and a documented result. Start small, test carefully and leave the business better able to operate without you. The next useful read is who owns the automation after handover.