You have three inbound channels open: email, WhatsApp, and your website form. You're answering most of them yourself at 11 p.m., and the volume is climbing. Hiring a support person costs £20–30k a year. An embedded AI chat widget costs £50–300/month and handles 60–70% of the questions you're actually tired of answering—pricing clarifications, FAQ hits, scheduling requests, and basic troubleshooting. The catch: most chat widgets are dumb. They're trained on generic product docs or nothing at all. They don't see your customer history, your actual pricing model, or your FAQ. They hallucinate. They break conversions. Here's how to deploy one that actually works, what data it needs to see, how latency kills conversion, and when you stop using it because hiring support finally makes sense. What data should your AI chat widget actually access? Start with three data sources. In order of importance: Your FAQ and help docs. This is non-negotiable. Every answer to a repeated question should live in a searchable doc the widget can read. If it can't find the answer there, it should say so instead of inventing one. Test this ruthlessly: ask it five questions you know the answers to. If it hallucinates on any of them, the training is incomplete. Your CRM data (lite version). The widget should see: your pricing tiers, product features, integrations you support, and known issues. Do not give it access to customer-specific data—payment history, signed contracts, or personal notes. You'll leak private information and break trust. A widget trained on your public pricing page and feature list is enough. Your product roadmap and known limitations. This is where most widgets fail. Someone asks, "Do you support X?" The widget says yes because you have a feature request for it. You've just made a promise you can't keep. Instead, train the widget on what you actually have live now, plus a short list of what's in progress (if you want transparency). Otherwise: "We don't support X today. Here's what we do support." Set a hard rule: never give the widget write access to your CRM. It should read only. A misguided automation that creates fake contacts or corrupt deal records will cost you hours to clean up. How to train the widget on your actual data Most AI chat platforms offer three ways to feed it information: Upload a static document (PDF, HTML, or text). Simple, slow to update. Good for your FAQ. Bad for pricing, which changes monthly. Use this for anything that's truly stable. Paste a URL and let it crawl your website. Faster than manual upload, but it crawls only what's public. It won't see your CRM. It works for help docs and pricing pages. Crawl errors are common—verify the widget actually read what you think it did. API integration to your CRM or knowledge base. This is the gold standard. The widget reads live data from your CRM or a connected tool like Notion or Airtable. When you change your pricing, the widget sees it within minutes. Orin's embedded chat widget can sync with your CRM data , so pricing, feature flags, and FAQ updates propagate automatically. Most competitors charge extra for this or don't offer it at all. Start with option 2 (URL crawl), test that it actually works, then move to option 3 if you're updating FAQs more than quarterly. Latency kills conversion faster than bad answers An AI chat response that takes 6 seconds to appear feels broken. After 3 seconds, visitors start to doubt whether anything will happen. After 8 seconds, they close the widget and look for your support email. Latency comes from three places: Network latency. Where your inference server lives. If your widget pings an API in the US and your users are in Southeast Asia, add 200–400ms just for the round trip. Choose a provider that has regional endpoints (Singapore, India, Europe) and measure actual response times from your target geography. Token generation time. The model has to think through your question and generate a response word by word. An average answer takes 2–4 seconds. A long, nuanced answer can take 8–12 seconds. Longer isn't always better—train your widget to answer briefly. "What's your pricing?" should get a two-sentence answer with a link, not a 400-word essay. Your data source latency. If the widget has to query your CRM every time someone asks a question, you're adding 500ms–2 seconds per question. Cache aggressively. If pricing changes once a month, cache it for 24 hours. If your FAQ is truly static, cache it forever. Measure it from your user's location, not from your office. A 1-second response time in London doesn't mean the same in Bangkok. Tools like WebPageTest can simulate this. What questions should the widget actually answer? Your first metric is deflection rate : what percentage of chat conversations the widget resolves without handing off to you. Aim for 60–70% in the first month. Here's what that looks like: It should answer: pricing, features, timelines, known issues, account access, and billing questions