Decide what the bot should do
Identify the repeated questions and the action customers need. That might be checking what a service includes, collecting a short brief or passing an enquiry to a team member.
Keep the first version bounded. A bot that is expected to answer anything can create uncertainty about prices, availability and commitments.
Compare the alternatives
| Need | Useful starting point |
|---|---|
| A person wants to describe a custom project | A labelled contact form and human reply |
| Customers repeatedly ask the same factual questions | Clear service information and a maintained FAQ |
| A guided conversation adds useful context | A bounded chatbot with an agreed handoff |
| The team copies each enquiry between systems | Automation behind the form |
Keep a route to a person
Explain what the assistant can help with and how someone can contact the team. Preserve the original message when passing it on. A summary should not replace the customer's own words.
Confirm the operating rules
Agree the approved information, data access and escalation points. Review recurring usage costs and who updates the answers when the business changes.
Test unexpected questions and failure cases, not only the easiest conversation. A useful assistant should recognise when it does not have a reliable answer.
Does every business need a chatbot?
No. Start with the actual customer task and the team's workload. If a form and clear content work well, add a chatbot only when it solves a specific remaining problem.
Apply this to your business.
Tell us about the website or workflow you want to improve. We can discuss a practical scope and starting point.