What a Web3 chatbot should handle
Quick test: Take 20 questions from your support chat and see how many your docs answer clearly.
A Web3 AI chatbot should resolve repeat questions using approved product information, then make it easy to reach a person when a request needs judgment. It is useful when users repeatedly ask about product features, setup, supported networks, documentation, or where to get help.
Before development, list the questions the assistant should answer and the decisions it must leave to your team. Separate public information from internal material, and identify any subjects that require a human response. For example, product instructions can be handled from documentation, while a request about an individual account or an unusual transaction can be routed to support.
A focused first release is easier to test and maintain than an assistant expected to answer every possible question. Share:
- The primary audience and the channel they already use.
- Current documentation, FAQs and support replies.
- Topics that need a human review or must not receive an automated answer.
- The person or team responsible for escalations.
For a broader view of the build options, see Web3 development and AI agent development.
How do we ground answers in your documentation?
We organize your approved materials so the chatbot can use them as the basis for responses, then shape its behavior around what those materials actually say. That starts with a source-by-source documentation review: we check what is current, who owns it and whether separate pages conflict.
The useful preparation is not simply to collect the largest possible archive. Start with the materials users need most, remove superseded instructions, and mark content that is private or unsuitable for public answers. If a product name, network, process or policy has changed, tell us which version is authoritative. We can also identify gaps where the source material does not answer a common question, so your team can decide whether to add guidance or direct the user to support.
Conversation design then sets a response style and clear boundaries. The assistant should say when the approved sources do not provide an answer rather than present an unsupported policy or price. Your team can review sample questions and responses before launch.
For related product work, explore Web3 website and landing development or dApp development.
Your 7-point chatbot readiness checklist
Check these 7 items before development starts. The quality of the sources decides the quality of the answers, so most of the work happens before any code. Do the ticking together in one short call, and write down who owns each line before the call ends.
- List the documents the bot may use.
- Remove or mark outdated pages.
- Collect 20 real user questions.
- Write 5 things the bot must never answer.
- Pick the first channel.
- Name who receives handoffs.
- Agree how docs updates reach the bot.
Terms in one line
Grounded answer: a reply based on your approved sources, with no guessing.
Handoff (in plain words: passing a question to a person when the bot should not answer).
Website, Telegram or Discord: which channel suits your users?
The right chatbot channel is the one that puts help where your users already ask for it and where your team can manage escalations. A website assistant suits visitors looking for product or onboarding information; a Telegram assistant fits support in an existing Telegram community; a Discord assistant can serve members inside a project server.
The channel affects the practical setup, not the source of truth: each version should answer from the same approved documentation and follow the same boundaries. For each channel, agree on the placement, welcome message, expected question types and what happens when a person needs help. In community channels, decide how the assistant should behave alongside moderators so it supports the conversation instead of obscuring it.
| Channel | Useful for | Prepare before launch |
|---|---|---|
| Website | Product discovery and common support questions | Page placement, public sources and contact route |
| Telegram | Questions in an existing community | Channel access, moderator handoff and response boundaries |
| Discord | Help in a project server | Server access, relevant support spaces and escalation owner |
You can begin with one channel and extend the same documentation approach later. For a channel-specific build, see Telegram bot and mini app development.
Handoff and multiple languages
Common mistake: Feeding the bot old docs. Retire outdated pages before you connect anything.
A useful chatbot makes the next action clear when it cannot resolve a question. We design the human handoff around your support workflow: what counts as an escalation, where the user should go, and what context should accompany the request.
Agree on escalation cases before implementation. Common examples include account-specific issues, sensitive requests, conflicting documentation, and questions where a user needs a decision rather than a general explanation. Decide whether the assistant should provide a support link, direct the user to a team member, or collect a short summary for follow-up. The chosen route must match the way your team actually handles requests.
For multilingual answers, provide the approved source material and tell us which languages matter to your audience. We can design responses across those languages and flag source content that has no reviewed equivalent. This avoids treating an unreviewed translation as authoritative. Test examples should include ordinary questions, ambiguous wording, unsupported requests and handoff scenarios in each planned language.
If the project needs fitted on-chain product behavior as well as support answers, smart contract development is a separate workstream that can be planned alongside the chatbot.
What testing and tuning include
Testing checks whether the assistant gives useful answers from your approved sources and follows the agreed escalation rules. We prepare representative questions with your team, review the responses together, and revise unclear wording or source coverage before launch.
A practical test set should cover:
- Frequent questions and alternate ways users may phrase them.
- Questions answered directly by a source and questions with no approved answer.
- Conflicting or outdated material that needs an owner to resolve it.
- Requests that should go to a human rather than receive a self-service answer.
- The channels and languages included in the agreed plan.
After launch, reporting on unanswered questions gives your team a concrete way to improve the experience. We can help distinguish a missing source from an unclear question or a case that belongs with support. Your team approves changes to product guidance, and we tune the chatbot against the revised material and response expectations.
MarketingExtra keeps the work actionable by sharing the reviewed test examples, open documentation questions and agreed follow-up tasks with your project contact. For projects that also need a user-facing interface, coordinate the chatbot plan with Web3 website development so the placement and support route are consistent.
What to confirm before launch
A launch is ready when approved sources, channel access, response boundaries and human ownership are clear. Confirm who can authorize the integration, who approves answers, and who receives escalations; then test the agreed user journeys in the intended channel.
Access permissions and channel configuration are controlled by your team and the relevant platform, so they can affect integration and launch readiness. We cannot promise that every user phrasing will produce a complete answer or that every question can be resolved from the documentation; we can deliver the agreed integration and review the behavior against approved test cases.
Before kickoff, gather the current source documents, the channel you want to start with, sample user questions, your escalation contact and any languages in plan. We will review the materials, flag decisions your team needs to make, and confirm a practical plan for implementation. Send MarketingExtra those items and your preferred channel to start the chatbot review.
Send 3 things: your current docs, the channel to start with, and 20 real user questions.
How it works
- Share sources and channel goalsSend the current documentation, target channel, audience and examples of common questions. Identify any material that should remain private.
- Review sources and boundariesWe check the source material for ownership, gaps and conflicting instructions, then agree on what the chatbot can answer and when it should escalate.
- Design conversations and handoffWe map common questions, response style, supported languages and the route to a human for requests that need review.
- Implement and testWe configure the agreed channel and review representative questions with your team, including unanswered and escalation cases.
- Launch and tuneAfter launch, we review unanswered-question patterns and coordinate approved source or response updates with your team.
Frequently asked questions
Can one chatbot use the same docs on web, Telegram and Discord?
Yes. The assistant can be planned around one approved source set and adapted to the channels included in plan. Each channel still needs its own access, placement and handoff decisions, so specify which channels you want at kickoff.
What documentation should you prepare?
Prepare current product documentation, FAQs, support guidance and any approved explanations users regularly need. Mark outdated or private material, name the owner of each source, and tell us which version takes priority if documents conflict.
Can it answer in more than one language?
Yes. Share the languages you want to support and the source material approved for each. We can design multilingual answers and identify where a language lacks reviewed guidance, so your team can decide whether to supply a translation or route the question to a person.
How does it pass a question to a person?
The handoff follows the support route agreed with your team. It can direct a user to a support contact or pass along a summary where the channel and workflow allow it. We define escalation triggers and test them before launch.
How many weeks does a chatbot build take?
Timing is set once we review the documentation, target channels and access needs. The work proceeds through source review, conversation design, implementation, testing and launch. Having current materials and a named escalation owner ready helps the team make decisions without avoidable delays.
Can it promise a right answer every time?
No. Platform access and configuration are controlled by your team and the relevant platform, and some user questions will fall outside the approved documentation. We test against agreed examples and deliver the planned integration, but cannot promise a complete answer for every phrasing or situation.
Can you update it when your docs change?
Yes. Updates to approved sources can be included in an ongoing tuning plan or planned as follow-up work. Assign an owner to notify us when product guidance changes, and review the affected questions and responses before revised material is treated as authoritative.
Tell us about your project
Answer four quick questions and a manager will send you a plan, timing and a price range within the hour. Everything stays confidential.
Loading the form…