There are two completely different products being sold under the same words right now, and the price is often similar, which makes the confusion expensive.
The first answers questions. A visitor asks what a sewer scope costs, it produces a paragraph from your website, and then it says something like "would you like to get in touch?" and shows a contact form. That is a search box with better manners.
The second checks your actual availability, quotes from your actual pricing rules, holds a slot, takes the booking, writes it into your system, and emails a confirmation. That is an agent, and the difference is not prompt engineering. It is architecture.
I build both, and I want to be honest about which one most businesses need, because it is frequently the cheaper one.
A chatbot reads. An agent acts.
Everything else follows from that. A bot that only reads needs one capability: get relevant text and summarise it. A bot that acts needs permission to change things in the real world, which means it needs tools, guardrails, error handling and a way to know when it is wrong. That is an order of magnitude more engineering, and it is where the cost and the value both sit.
Simple scripted bots on decision trees are largely finished as a category. The current split is between retrieval bots, which answer from your content, and tool-using agents, which can do things. Understanding which one you are being sold is the entire buying decision.
A general model with no grounding will invent a plausible number. For a service business that is not a minor bug: quoting $250 for a job you charge $600 for creates a conversation with a customer who now believes they were quoted $250.
The fix is retrieval augmented generation, which means the model is only permitted to answer from documents you control, and is instructed to refuse rather than guess when the answer is not there. RAG is not an upgrade for a service business bot. It is the minimum bar.
This is the most common and most costly failure. The visitor has been convinced. They say "great, can you come Thursday?" and the bot replies "please fill in our contact form and a member of our team will be in touch."
You just took someone at peak intent and added friction. The bot did the hard part, persuasion, and then handed off at the exact moment it should have closed. A form was always going to get that lead. The bot added nothing except a delay.
A bot without memory of the conversation, or without access to whether this person is an existing customer, asks the same qualifying questions repeatedly and treats a repeat client like a stranger. Visitors read this as incompetence, and it reflects on you rather than on the vendor.
A lot of chat widgets load several hundred kilobytes of JavaScript on every page, including pages nobody will chat on. If your Largest Contentful Paint moves from 2.1s to 3.4s across the whole site to support a widget that converts a small number of visitors, the arithmetic can easily come out negative. I have removed chat widgets that were costing more in abandoned page loads than they produced in leads.
Four capabilities, and the useful thing about this list is that you can ask any vendor about each one directly.
Your services, prices, service area, exclusions, guarantees and FAQs, indexed and searchable, with the model constrained to answer from them. When it does not know, it must say so and offer a handoff. A bot that never says "I am not sure" is a bot that is guessing.
This is the actual dividing line. The agent needs functions it can invoke: check availability, calculate a quote, create a booking, look up a customer. The Model Context Protocol has become the common way to expose these, because it gives you one consistent interface between the model and your systems instead of bespoke glue for every integration.
Critically, each tool carries its own permissions. Reading availability is safe. Writing a booking needs confirmation. Taking payment needs a great deal more than that. An agent without per-tool guardrails is not simpler, it is just riskier.
Pricing should not be generated. It should be calculated. Square footage, property age, distance, add-ons and surcharges belong in code that returns the same answer every time, with the model calling that code and reporting the result.
The same applies to eligibility. Whether you serve a postcode is a lookup, not an inference. Put every rule that has a right answer into a tool, and leave the model to handle only the conversation.
Once a booking exists, several things must happen: a confirmation email, a calendar entry, a CRM record, a notification to you, a reminder later. This is orchestration, and it is what I use n8n for. It is also the part that is easiest to underestimate, because it is unglamorous and it is where the reliability problems actually live.
| Capability | Answering chatbot | Booking agent |
|---|---|---|
| Answers service questions | Yes | Yes |
| Grounded in your real content | Sometimes | Required |
| Quotes a real price | No, or invents one | Calculated from rules |
| Checks live availability | No | Yes |
| Creates the booking | No, shows a form | Yes |
| Writes to your CRM | No | Yes |
| Knows a returning customer | Rarely | Yes |
| Typical build | Days | Weeks |
| Typical cost | Plugin subscription | Real project |
| Ongoing maintenance | Minimal | Genuine, ongoing |
I am going to argue against my own more expensive service here, because getting this wrong wastes real money.
For a large share of local service businesses, the right answer is a well grounded answering bot on a fast widget plus a short form. That is a fraction of the cost and captures most of the available value. The booking agent earns its keep when volume is high, pricing is rule-based, and after-hours enquiries are being lost.
The honest case for a booking agent is not "AI increases conversions." It is much narrower and easier to verify: it covers the hours you do not.
Look at when your enquiries arrive. For most home services a substantial share land in the evening and at weekends, when nobody answers. Those people contact the next company on the list. An agent that can book at 9pm on a Sunday does not need to outperform you. It only needs to outperform your voicemail, which is a low bar.
That is the number to build your case on. Take your after-hours enquiry count, apply your normal close rate, multiply by average job value, and compare against the build and running cost. If it does not clear comfortably, build the cheap version instead.
Start with retrieval only, and let it run for a month against real visitors. The transcripts will tell you exactly which tools are worth building, and that ordering saves a great deal of money compared with speculating up front.
Demos are built to look good. These questions are difficult to answer impressively unless the underlying system genuinely does the work, which is what makes them useful.
Build cost gets quoted. Running cost frequently does not, and it is the part that determines whether this is sustainable.
There are three ongoing components. Model usage is charged per token, so cost scales with conversation volume and length, and a verbose agent that restates everything costs meaningfully more than a concise one over a year. Hosting for the agent service is modest but real. Maintenance is the one people forget: when you change your pricing, add a service, or your scheduler updates its API, someone has to update the agent. Content drift is the most common cause of a system that was accurate at launch and is quietly wrong six months later.
Budget for a review every quarter at minimum. Read a sample of transcripts, check the answers against current reality, and fix what has drifted. An agent nobody audits becomes a liability slowly and invisibly, which is the worst way for a customer-facing system to fail.
One more thing worth pricing in honestly: you will want to change it once you see real conversations. Almost nobody gets the qualifying questions right the first time, because you discover that visitors ask things you never anticipated. Treat the first month as calibration rather than as the finished product, and plan for a round of changes after it.
For the answering version, yes, and for many businesses that is the correct decision. Check three things: that it can be grounded in your own content, that it defers instead of guessing, and what it does to your page weight. Plugins do not generally do the booking version, because that requires integration with your specific systems.
It will if you let it. Any third party widget adds weight. Deferred loading, restricting it to relevant pages, and measuring before and after keeps it manageable. Measure. Do not assume.
This is the right question to be worried about. Constrain it to retrieved content, calculate anything with a correct answer in code rather than generating it, require confirmation before any action, and log everything. You cannot reduce the risk to zero, which is exactly why pricing and availability must never be improvised.
Typically four to eight weeks, and the modelling is rarely the slow part. Documenting your pricing rules and integrating with your existing scheduler is where the time goes.
No. It should write into it. Your existing scheduler stays the source of truth and the agent becomes another way to create a booking in it, alongside the phone and your form.
Usually not the booking version. A grounded answering bot plus a fast form is the right call for most small operations, and the difference in cost is large. Be sceptical of anyone who tells you otherwise without first asking how many enquiries you get.
Ask a vendor one question: can it check real availability and create a real booking? Everything else in the demo is presentation. That answer tells you which product you are being sold.
Muhammad FurqanIf you are being quoted for an AI chatbot right now, ask what happens at the exact moment a visitor says yes. If the answer is a contact form, you are buying the cheaper product at the more expensive price. Tell me what you are being offered and I will tell you honestly which version your business actually needs, including when the answer is the simple one.
Send it over and I will give you a straight answer, including when the answer is that you do not need to change anything.
I'm Muhammad Furqan, a Full Stack Developer and AI Engineer based in Lahore, Pakistan. 250+ high-performance websites delivered across the USA, UAE, UK and Pakistan.
I'm Muhammad Furqan, a Full Stack Developer and AI Engineer. 250+ high-performance websites delivered across the USA, UAE, UK and Pakistan.
