AI Support & Enquiry Systems
Most small businesses lose enquiries two ways: someone asks a question at a time nobody is watching, or someone asks and never leaves their details. The system handles both.
A chatbot is a commodity now, and most buyers have already been pitched one. Lost enquiries are a number an owner can feel. The capture and notification layer most competitor demos skip is the part running live on this site, the same pattern documented in the AI Support Systems case study.
A deployed assistant, running on the business's own site, answering from its own content.
A knowledge base, built from existing material: site pages, FAQs, PDFs, product or service documentation, structured for retrieval.
An enquiry capture flow, collecting name, email, phone, and the request, written to a destination already in use.
Notification routing, so each captured enquiry reaches a named inbox immediately.
An evaluation report, stating how the assistant was tested, what it answered correctly, and where it was weak, written in plain language.
Guardrail configuration: what the assistant will not answer, what it escalates, and what it says when it does not know.
A handover document: how to update the knowledge base, what to check monthly, what to do when something breaks.
Most services like this ship the assistant and never measure it. An evaluation report is the difference between a chatbot shipped without measurement and one shipped with evidence it works, the same discipline behind the assistant answering this site.
Scope and content audit · one week
Agrees what the assistant is for and what it is not for, and inventories existing content to identify what is missing, producing a written scope with the question types in and out of range.
Build · two to three weeks, depending on scope
Structures the content for retrieval, wires the capture flow and notifications, and configures guardrails.
Evaluation · inside the build window
Tests the assistant against a real question set drawn from the business's actual enquiries rather than invented ones, measuring retrieval quality and re-testing what fails.
Deploy and handover
Puts the assistant live on the business's site, confirms notifications end to end, and delivers the handover document with a walkthrough call.
Typically three to four weeks from signed scope, depending on workload. The clock starts when the content arrives, not when the contract is signed, the single most common cause of overrun. Part of what keeps that timeline tight is Claude Code, used throughout the build alongside the platforms listed below.
Scope. One named decision maker, available for two calls, since scope drift with no owner is the main cause of overrun, and a list of the questions the business actually gets asked, since the evaluation set comes from there rather than guesswork.
Build. Access to existing content, site, documents, FAQs, product data, since the assistant can only be as good as what it is given; website access or a developer contact for the embed, one line of code, but someone has to be able to add it; and the destination for captured enquiries and the inbox to notify, decided once, changed later only with effort.
Evaluation. Review of the assistant's answers against the business's own question set. Only the business knows what a correct answer sounds like in its world.
Handover. One person who owns updates afterward. An unmaintained knowledge base decays.
Writing the business's content from scratch, the system organises what exists and missing material is separate work; ongoing monitoring, retraining, or content updates after handover, unless a maintenance arrangement is agreed separately; and voice, phone systems, or WhatsApp Business API integration.
Arabic: the system can respond through the model, but answer quality is not evaluated to the same standard as English, since the evaluation set needs a fluent reviewer. Where Arabic needs to be a primary channel, the engagement scopes in a reviewer rather than claiming untested quality.
Running costs, model API usage and hosting, sit on the business's own account, or route through at cost.
Capture destination
Standard, and what is proven: enquiries written to a Google Sheet the business owns, with email notification, the pattern running live on this site. Writing into an existing CRM, HubSpot specifically, is available as an add-on, scoped and quoted separately; it has not yet been delivered to a client, so it is built to spec rather than offered as a routine option. The sheet-plus-email pattern suits businesses handling enquiries in the tens per week. Above that volume, a real CRM is the right answer.
Built with
Python, pandas, NumPy, scikit-learn, FastAPI, Docker, Fly.io, retrieval-augmented generation, Claude Code, Make, Zapier, HubSpot, Asana, Blaze.ai, Astro, Vercel.
Tool selection is part of the feasibility stage and is assessed against what a business already runs.
Background on who delivers this work is on the About page.