Chatbots
Last updated · A-Widget
| Decision | Tidio | ChatBot | HubSpot | Crisp |
|---|---|---|---|---|
| Best for | A small business that wants to assess human chat, rules and AI separately | A business with a defined conversation and a maintained answer source | A business already using HubSpot to manage inquiries and follow-up | A team evaluating automation alongside shared customer messages |
| Documented scope | Live chat and help desk; Lyro AI and Flows have distinct usage units; Published free tier has finite allowances | Hosted chatbot product; Website integration documentation; Subscription is separate from LiveChat | Website live chat and CRM route; Chatflows and account-based management; Advanced capabilities depend on entitlement | Shared customer inbox; Website chat and plan-based automation; Seats and automation vary by package |
| Trade-off | Each automation product and usage unit needs its own check | The bot service is separate from LiveChat and human staffing | Basic chat and advanced AI or automation are different entitlements | Current package and AI-credit rules need separate inspection |
| Next step | Read Tidio analysis | Read ChatBot analysis | Read HubSpot analysis | Read Crisp analysis |
These four are research-based candidates from current vendor sources. We have not tested answer accuracy in paid accounts. A documented feature is not evidence that a bot can answer every user, complete a private action or reduce the business's workload by a fixed amount.
Tidio
Our verdict:
Mixed support path
Best for A small business that wants to assess human chat, rules and AI separately
Keep in mind: Each automation product and usage unit needs its own check
Tidio is a candidate when the business needs both a human entrance and a route into automation. Its listed offer distinguishes human support, Lyro AI and Flows. Those are separate tasks even when the user meets them behind one launcher.
Begin with the question the bot should answer. A public delivery policy is a distinct source from a live order record. A general service description is distinct from a confirmed booking. The product choice should follow the source you can safely use.
A fictional service business could use a short rule path to ask which service interests the user. The result could show an approved answer or send the question to staff. Keep an uncertain option for someone who does not know the service name.
For an AI task, prepare a current public knowledge source. Exclude outdated offers and private material. The bot should be able to decline a question outside that source rather than fill the gap with a plausible promise.
Use Tidio's current help to inspect supported source and handoff behavior. The existence of Lyro in the product family does not prove the exact plan, knowledge route or allowance for your account.
The current pricing page has distinct units for human-handled conversations, Lyro and Flows. Read the refresh rule for a first AI allowance. Do not treat a one-off allocation as ongoing monthly free automation.
The Tidio pricing guide records those boundaries. A larger usage allowance does not fix a wrong source, an unanswered queue or a poorly defined task. Configure the work before buying more capacity for it.
The strength is a path that can include people and automation in one product setting. The drawback is scope and quota management. A small business needs to know which part answers, what it can use and who handles the unresolved case.
Choose this route when the documented combination fits a real mixed workload. Consider a simpler route when a clear contact form or a human-only queue meets the need. A bot is not required just because the account exposes one.
ChatBot
Our verdict:
Dedicated bot task
Best for A business with a defined conversation and a maintained answer source
Keep in mind: The bot service is separate from LiveChat and human staffing
ChatBot is a candidate when the business wants a dedicated bot product. Its official site and help describe website connection and bot construction. Inspect the current source, response and handoff controls for the task rather than assuming every bot product has the same model.
Keep the product name distinct from the generic word chatbot. ChatBot and LiveChat are separate products. A plan to one does not by its name establish the full plan scope to the other.
Write the opening question, the supported answer and the point where the bot stops. A short workflow is easier to assess when the possible outcomes are explicit. If the task needs a live account action, find the supported connection that can establish its result.
For a fictional booking inquiry, the bot could explain a service and direct the user to a scheduler. It should not announce that a time is reserved merely because the user typed a preference. The scheduler needs to confirm the booking.
Read ChatBot's current help centre for the exact connection and human-contact route. If a feature is not established for the chosen package, keep it not checked rather than treating a demo as proof.
A user may use unexpected wording or ask about an exception. Give the bot a useful response for that case. It can acknowledge the limit and provide a person or contact route without pretending it completed the task.
Keep a way out of repeated prompts. A user who chooses “other” should not return to the same menu indefinitely. A direct request for a person should be considered in the handoff design where the business offers that route.
The strength is a dedicated focus on the bot workflow. The drawback is that the wider human-support and data process remains separate. The business still needs staff ownership, source upkeep and a current plan for any connected services.
Choose this route when a defined bot task and its failure path are ready to build. Pass when the business is hoping the software will invent missing policies or remove the need to decide who handles exceptions.
HubSpot
Our verdict:
CRM-based routing
Best for A business already using HubSpot to manage inquiries and follow-up
Keep in mind: Basic chat and advanced AI or automation are different entitlements
HubSpot is useful when the bot or chatflow should support an existing contact process. The official knowledge base describes the current chat and automation routes. Match the planned behavior to the real account and product scope.
Do not label every HubSpot feature free because a live chat page offers a free entry. Basic chat, rule-based routing and more advanced AI can have distinct rules. The chosen account is part of the evidence needed for the comparison.
A fictional agency might ask which service the user needs, provide a useful answer and offer a later reply. A contact record can help if staff actually use it to follow up. Creating more records without an owner does not solve the support task.
Collect only the details needed for that next step. A user asking a general question may not need to share a full profile. Keep a support interaction separate from consent to unrelated marketing.
Use the HubSpot knowledge base to inspect the current chatflow, account access and supported handoff. Record which actions are established and which still need a package check.
A CRM-linked widget can connect the conversation with other details. Decide which data the task needs and who can read it. More context is not by itself suitable context for every staff member.
Set a rule for an unknown user or an uncertain request. Do not infer identity from a name typed in a chat. Private account changes need the business's supported checks process, even when the CRM contains a matching record.
The strength is alignment with a CRM process already used by the business. The drawback is the scope and upkeep of that surrounding system. A small site that only needs an occasional question may be better served by a narrower route.
Choose HubSpot when the current plan scope and real follow-up process fit. Pass when adopting the wider system would create more work than the task warrants or when a required bot action remains not checked.
Crisp
Our verdict:
Inbox-based workflow
Best for A team evaluating automation alongside shared customer messages
Keep in mind: Current package and AI-credit rules need separate inspection
Crisp is a candidate for a business that wants automation to sit near a shared message workflow. Its current plan page distinguishes packages, included seats and automation scope. Inspect the exact package rather than assuming the free inbox contains the paid AI features.
The Crisp pricing page lists no included AI credits in the Free package. That is a key boundary for a business comparing ongoing free human chat with a bot. Trial access should be treated separately from the continuing package.
A fictional small team might use automation to answer a public FAQ and leave exceptions in a shared inbox. The useful design question is how the team names and owns that unresolved work. A transfer is not complete because a message appears somewhere.
Check the current workflow and assignment controls for the chosen package. Decide what the user sees when no staff member is available. Do not promise a live handoff to an unattended queue.
Keep source updates and team operations linked. If the business changes a policy, review the bot's source and any saved human reply. A shared inbox does not by itself keep those two answers consistent.
Crisp's current paid offer includes AI-credit and automation descriptions. Read the definition before comparing them with another vendor's conversation unit. A credit and a conversation are not by itself equivalent.
Use a labelled workload assumption if you estimate cost. Keep any unknown conversion between units unresolved. This guide does not invent a precise bill or claim a fixed saving from the package structure.
The strength is the potential fit with a shared-inbox process. The drawback is package matching and the need to understand the supported automation route. A wider package helps only when the team uses the workflow it supplies.
Choose it for a documented inbox and bot need. Pass when the need is a simple fixed link or a form for later review. The smallest clear route can be easier for both users and staff.
Pick one task that can be described plainly. Identify the source that supports the answer and the cases the bot must decline. A broad goal such as “answer everything” is not a useful acceptance condition.
Keep private actions separate from public explanations. A bot can describe a returns policy without being able to approve an exact return. A service description can explain booking choices without reserving a time.
Use current public facts useful to the task. Remove conflicting or retired material from the allowed source. Do not connect every internal document just to give the model more text.
Assign responsibility for updates. A new price, service or policy may need a source refresh and a check of saved replies. The business should know how to change the answer rather than hoping the bot discovers the update.
List human access, AI use, flow use and connected sources separately. A vendor can use a distinct unit for each. Read the ongoing offer after any trial and note the chosen billing period.
Keep custom or not checked charges open. A small-looking entry amount may describe a narrow unit. Do not present a precise monthly total when the real quota, extra product or current quote is unknown.
Define the trigger and the receiving route. A live queue, a ticket and a later email reply are distinct promises. Confirm that the chosen package supports the one you intend and that someone watches it.
Pass the useful context without unnecessary private data. Staff should see the question and useful approved details. A handoff should not force the user to repeat everything or expose unrelated records to more people.
Write the no-answer message as carefully as the normal reply. It should find the limit and provide a next step. Avoid a loop that asks the same question in distinct words without offering a way out.
Keep normal website contact and policy content readable without the widget. A blocked or unavailable external script should not make the business unreachable. The page needs a useful baseline before automation loads.
Check a normal question supported by the source. Then ask a related question the source does not answer. The second should not produce a made-up policy. Record the expected fallback before looking at the result.
Ask directly for a person and inspect the receiving record. Check the same path when staff are offline. The user should receive an honest state, not an unsupported claim that someone has accepted the task.
Use fictional details for setup checks. Do not paste user secrets, private account records or payment data into prompts. The test process should respect the same data boundary you expect in production.
Open the live page while signed out. Check the correct business account, greeting and source scope. On a phone, inspect the whole panel and close control. Use the keyboard to enter and leave the screen.
Inspect the staff inbox or contact record separately. A nice user response does not prove a task reached the right person. The workflow is complete only when the receiving system and business ownership are clear.
Record where the script, plugin or app embed lives. Disable that known route if the bot gives unsafe or misleading responses. Keep the normal contact entrance available while you correct the source or setup.
Removing a widget is separate from deleting a vendor account, cancelling a plan or handling stored messages. Use the service's supported controls for those tasks. Preserve needed open work before closing the old route.
After a controlled launch, inspect the kinds of unresolved work that actually arrive. Use those observations to improve source coverage or simplify the bot. Do not claim a success rate or saving without a defined measure and evidence.
A conversation, an answered question and a resolved user issue are distinct events. A completed bot path does not prove a sale. Keep unavailable downstream outcomes as unknown rather than filling the report with estimated gains.
For each candidate, keep the task, source, plan and fallback together. Note the installation route and the person responsible for updates. That record is more useful than a list of attractive features with no owner.
Return to the small-business readiness guide if the underlying answer source is still unclear. Use the workflow examples to make the planned interaction concrete before building it.
Take a fictional shop that wants help with delivery questions. Its public policy states the regions it serves and how users can check an order. That source can support a narrow FAQ task. It cannot prove the state of a parcel unless a supported live route provides that data.
The first case is a user asking where to find the delivery policy. A useful bot gives the right source and a short answer within it. The next case is a user asking for a guaranteed arrival date. If the source does not contain that fact, the bot should say so and give the real support route.
Write those expected outcomes before choosing a plan. This keeps the choice tied to a task the business can inspect. A large list of AI features cannot replace a missing answer source.
Now take a fictional local service firm. It receives questions about which service to book. A short menu can help a user reach the right description. The menu needs a route for someone who does not know the service name.
If the user asks whether a time is free, the bot should use the supported calendar route or direct them to it. A chat message is not a booking. If staff must approve the work first, the bot should call it a request rather than a confirmed job.
This case may not need AI at all. A clear choice and a useful link can be easier to manage. Choose the method because it solves the task, not because a trial lets you turn on a new feature.
A third case is a small team with no live cover at night. The bot can explain that staff are away and use a supported later-message path. It should not say a person is joining when no one watches the queue.
Check what staff see the next morning. The useful record should contain the question and the detail needed to reply. It should not force staff to search an unrelated system to find the task. Set an owner for that queue before the first public prompt.
A final case is a private account request. The user wants to change a billing detail. A general website bot should point to the business's secure account route. It should not ask for a password or accept card data in free text.
This is a success boundary, not a gap to hide. A bot that declines an unsupported action can protect the user from a false result. The next step should still be useful and clear.
For each case, inspect both sides. Read the reply on the public page. Then inspect the record or destination that should receive the work. A fluent sentence does not prove the handoff completed.
Use fictional details during setup. Keep the question realistic enough to exercise the route, but leave private data out. The test should show the task and its failure state without creating a real support obligation or charge.
After launch, review the kinds of work the bot could not handle. Some may justify a clearer public source. Others should stay with a person. Do not expand the bot's scope just to reduce the number of times it says it cannot answer.
A short menu can be a better starting point than generated answers when the possible outcomes are already known. A fictional repair business might offer “book a repair,” “read the warranty policy” and “ask about an existing job.” Each choice can point to a different supported route without generating new policy wording.
Write the destination beside each choice before configuring the bot. Booking belongs with the scheduler, the warranty question belongs with the published policy, and a private job-status query belongs with authenticated support. Include a general-question exit so the menu does not force someone into an inaccurate category.
An AI response becomes relevant when visitors ask in varied language and the business has a maintained public source to answer from. It should add a way to find or explain that information, rather than expand what the business is willing to promise. Compare the actual knowledge controls in each candidate, alongside the staff handoff.
Keep a small decision sheet with three columns: the question users ask, the system that can establish the answer, and the allowed next action. “When do you close?” can use the published hours. “Will you stay open late for me?” needs staff. “Has my payment cleared?” needs the secure payment or account route. If those columns cannot be completed, adding a more powerful model will not supply the missing business process.
This separates two selection problems: understanding the visitor’s wording and having authority to perform the task. Choose a chatbot for the former only when the latter already has a reliable destination.
Choose by the narrow task, maintained source and receiving process. A small team may need a simple rule path or human chat rather than a broad AI system. Check the current package and ongoing limits. Staff size alone does not find a universal winner.
This guide makes no such guarantee. Define the allowed source, inspect unsupported questions and keep a useful fallback. A fluent reply can still be wrong. The business remains responsible for the policy, account actions and claims it presents to users.
Not necessarily. Human chat, fixed flows and AI can have separate plan limits and usage units. Trial access may differ from the ongoing free tier. Read the vendor's current plan and refresh rules before relying on automation as a continuing free service.
It should find its limit and offer the planned human or contact route. Confirm that route works when staff are present and absent. A repeated prompt loop or an invented answer is not a useful replacement for a clear fallback.
