What this covers
A chatbot is only useful if it does something. The bots that frustrate customers are the ones built to look modern and trained on nothing. The ones that work are grounded in your real data — your services, your knowledge base, your product information — and have specific jobs.
Three patterns cover most projects:
- Sales / qualifier bots — site widget that qualifies visitors, captures leads, and books or hands off to a human.
- Customer-support bots — answer questions from your knowledge base, deflect tickets, escalate the ones that need a person.
- Internal copilots — chatbots for your team that pull from internal docs, SOPs, or Salesforce data, so people stop interrupting each other to ask the same questions.
How we build them
The architecture varies, but the building blocks are stable:
- Anthropic Claude, OpenAI GPT, or open-weight models depending on your data sensitivity and budget.
- Retrieval-augmented generation — the bot pulls from your real content, with citations, instead of making things up.
- Tool calls — the bot can read a Salesforce record, write a lead, schedule a meeting, or trigger a workflow.
- Streaming UI — fast first-token responses so the chat feels conversational, not transactional.
- Guardrails — what the bot will and won't talk about, written down and tested.
How we typically engage
Chatbot projects scope cleanly to a single use case. A typical bot is a three-to-five-week build, with a one-week discovery up front to define the conversation flow and the data sources.
What "done" usually looks like
- The bot completes its job — qualifying, supporting, or answering — without making things up.
- Conversations are logged and reviewable so you can see what users asked and how it responded.
- Hand-off to a human is clean: when the bot needs to escalate, the receiving person has the full context.
- A clear update path: when your services or content change, the bot reflects it within a deploy.