The framing pitched to small businesses for the last two years has been wrong. The framing was: deploy AI across your whole operation, become an “AI-native” company, transform the way your team works. The pitch came in a deck with eleven workstreams and a four-quarter rollout plan. The cost ran low six figures. Almost nobody did it.
The data on actual enterprise AI rollouts confirms the framing failure. McKinsey’s State of AI 2025 reports that nearly two-thirds of surveyed organizations have not yet begun scaling AI across the enterprise, and most that started are still in the experimentation phase. The big-bang rollout pitched to small businesses by the same consultancies failed in the same way it failed at the Fortune 500. The discipline that worked is smaller and narrower.
The framing should be: pick the one task your team hates the most, the one that eats the most calendar, and build a single tool that compresses it to under a minute. Then move on.
We have built versions of this for clients in eleven industries. The pattern is the same every time.
What the tool looks like.
It is one prompt box, one results panel, one button. It lives at a URL only the team can reach. It runs on top of a retrieval layer pointed at the data the team already has, plus a thin agent layer that knows how to take the few actions the team would otherwise do by hand.
For a small law firm that spends three hours a day pulling case files for client calls, the copilot answers “what’s the status of the Henderson matter” in eight seconds with the last three pleadings, the next deadline, the outstanding discovery requests, and a one-paragraph plain-language summary. The data lives in their existing case-management software. The retrieval is RAG. The summary is the model. The “click to email this to the client” button at the bottom is one API call.
For a regional plumbing company that loses two hours a day to manual quote generation, the copilot accepts a brief job description in plain English, returns a labor-and-materials estimate against their actual pricing book, and drops a fillable PDF into the dispatcher’s queue. The pricing book is their existing data. The retrieval is RAG. The PDF is generated server-side. The dispatcher reviews before sending.
For a small accounting firm that re-types client-supplied receipts into bookkeeping software every January through April, the copilot accepts a folder of receipt photos and a client name, parses them, categorizes them against the client’s prior-year filings, and writes them into the accounting software as draft entries. The bookkeeper reviews and approves.
None of these is exotic. All of them are inside an evening’s reach for a competent engineer who understands the team’s actual workflow. The reason they don’t get built is that the team doesn’t have a competent engineer, and the off-the-shelf SaaS pitched as a substitute doesn’t understand the team’s actual workflow.
The workplace context for this matters. Pew Research reports that the share of employed US adults using ChatGPT at work climbed from 8% to 28% between 2023 and 2025. The team has already adopted the underlying model on personal devices for personal questions. The bar the focused copilot has to clear is no longer “will the team use AI at all,” it is “is the firm’s internal tool sharper than the consumer one they’re already using.”
A fourth example: the dental-practice copilot.
A two-location dental practice we worked with had a recurring problem with insurance-coverage explainers. New patients would call, ask whether their insurance covered a specific procedure, and the front-desk team would have to look up the insurance carrier’s plan rules, cross-reference the practice’s billing codes, and explain the breakdown over the phone. Each call took twelve to fifteen minutes. The front desk handled forty of these per week. That is ten hours of front-desk time consumed by one repetitive task.
We built a copilot that the front-desk team uses while the patient is on the phone. They enter the insurance carrier, the plan name, and the procedure. The copilot returns the practice’s typical coverage breakdown for that plan, the standard out-of-pocket range, the carrier’s policy notes if any, and a short script the front desk can read directly to the patient.
The call still takes twelve minutes. But two minutes of that is on the copilot. Ten minutes is on the patient relationship, which is where the front desk should be spending time. The practice eliminated nothing from the workflow. They moved the friction from the wrong end of the call to the right end. New-patient bookings climbed 22% in the first quarter because the front desk had more bandwidth for the actual conversation.
The same pattern fits other medical and dental practices where the repetitive part of the workflow is well-defined but the patient-facing part is not.
How we decide which workflow to compress first.
Discovery for a copilot engagement is one week. We sit with the team and we ask three questions.
What is the task you and your team dread most? Not the task that is most strategically important. Not the task that the consultant report flagged as inefficient. The task the team actively avoids until it piles up. Dread tells us where the real time leak is.
How many times a week does that task happen? Anything under five times a week is usually not worth a custom copilot. The math works at fifteen or more. Below fifteen, the discipline of using a new tool is harder than the savings.
How much of the task is judgment versus retrieval? Pure retrieval (pulling files, looking up records, summarizing existing documents) compresses cleanly. Pure judgment (deciding whether to take a case, choosing between two settlement offers) does not. The sweet spot is high-retrieval workflows with a thin judgment layer at the end. That is where compression goes from forty minutes to fifteen seconds and still leaves the human in charge of the decision.
The mistake we see most often is picking the second-worst workflow because the worst one feels too core to automate. The worst one is the one to pick. The second-worst will not actually pay back.
What “good” looks like.
We grade these the same way every time. Three numbers.
Time-to-task on the workflow it replaces. Before the tool, the firm spent forty minutes pulling a case file. After the tool, eight seconds. The compression has to be at least 10x or the team will forget the tool exists and go back to the old method by the second week.
Adoption rate inside the team. If the tool is built right, 80% of the team will use it within ten business days. If it is built wrong, 30% will try it once and then never again. We watch the analytics weekly for the first month.
Failure mode on edge cases. When the tool doesn’t know the answer, it has to say so. The worst version of these is the copilot that confidently hallucinates a deadline date for a case the firm doesn’t even have, and the partner walks into court with bad information. The tool has to know what it doesn’t know and surface that gracefully. We build evaluation harnesses around the failure modes during engagement, not after.
How we build them.
Three layers, no more.
Layer one: the retrieval base. We index the data the team already has. Case management, accounting software, scheduling system, pricing book, client records. The index is RAG with a re-ranker tuned to the team’s vocabulary. Nothing exotic. The index is hosted in your infrastructure, on your security perimeter. No third-party data warehouse.
Layer two: the model and the prompts. Off-the-shelf frontier models with a thin orchestration layer. The prompts are versioned and tested against an evaluation set of fifty to one hundred real queries the team would actually run. We tune the prompts during engagement. The eval set lives in the codebase so any future change to the prompts has to pass the same tests.
Layer three: the interface. A single page on a URL only the team can reach. One prompt box, one results panel, one button. No chat history sidebar, no clever multi-turn UI, no shared workspaces. The interface is intentionally minimal because the team uses it dozens of times a day and every extra click compounds.
The three-layer pattern is intentional and matches how the model providers themselves recommend building agentic systems. Anthropic’s engineering team writes that the most successful production deployments are not built on complex frameworks but on simple, composable patterns, and that the rule of thumb is to “start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.” The retrieval-model-interface stack above is that pattern, scoped to a single workflow.
All three layers ship as part of our AI consultancy engagement. The handoff at the end of the build includes the source code, the prompts, the evaluation set, the deployment infrastructure, and a runbook your team can maintain. You own the IP. We do not host anything on our side.
For buyer-facing automation (inbound calls, scheduling, follow-up), the work moves over to our AI automation practice. The internal-copilot pattern described here is for staff-facing tools that compress repetitive internal work. The two practices overlap on infrastructure but ship different deliverables.
What we charge.
Pricing is set per workflow during scoping. The qualifying math is the payback: a focused copilot pays back in month two if the workflow it compresses is the one the team genuinely hates most. The mistake is picking the second-worst workflow because the worst one feels too core to automate. Pick the worst one. The first call covers your week, identifies the right workflow, and we quote against the actual scope.
For agency partners who want to white-label this engagement for their own client base, the work runs through the partnership program. Your brand, our build, your client relationship.
Common Questions.
Can a team without an engineer build one of these themselves?
No. Off-the-shelf SaaS tools (no-code RAG, generic AI assistants) get you 60% of the way and then break on the failure modes that matter. The remaining 40% is where the team actually loses trust in the tool. A focused engagement with a competent engineer is shorter and cheaper than a year of fighting a no-code tool that almost works.
What about data security?
The index runs inside your infrastructure. The model calls go out to the frontier model providers (OpenAI, Anthropic, Google) over standard API endpoints with enterprise data-use terms. We do not store your data on our side. The runbook handed off at engagement end documents the full data flow for your IT review.
How long does the build take?
Four to six weeks for a focused workflow with a clear retrieval base. Eight to twelve weeks for a workflow that requires meaningful integration work with proprietary systems.
What happens when the team wants a second copilot?
Most do, after six to nine months. The second build is faster because the retrieval layer is reusable. We have built three-copilot deployments in the same operation, each one a separate URL focused on a separate workflow. That is the right pattern, not one giant general-purpose assistant.
Do you also build the underlying website around it?
When it makes sense. For clients who need a buyer-facing surface to go with the internal tools, the site rebuild ships through our AI-optimized websites practice and the copilot is layered on as a separate internal product.
To scope yours.
If you want to scope yours, book a strategy call. We will walk through your week and tell you which task to compress first.
