Como Construimos um CRM que Voce Controla Inteiramente por Chat

When we set out to build SalesSheet, we had a controversial thesis: every button, form, and dropdown in a CRM could be replaced by a single chat interface. Not as a gimmick or a secondary feature, but as the primary way users interact with their data.

Twelve months later, that thesis is our shipping product. SalesSheet is a chat-based CRM where every operation - creating contacts, updating deals, drafting emails, scheduling meetings - happens through natural language. This post is a technical deep-dive into how we built it.

The Architecture: Chat as the Universal Controller

Traditional CRMs have dozens of pages, each with their own forms and workflows. A contacts page, a deals page, an email composer, a calendar view. Each page is a separate engineering surface with its own state management, validation logic, and UI components.

We replaced all of that with a single conversational layer. The chat sidebar sits on the left side of the application, always available. Every message the user sends is parsed by our AI, which determines intent, extracts entities, and routes the request to the appropriate tool.

The key architectural insight is that CRM operations are fundamentally CRUD operations with context. "Add Maria Lopez from TechCorp" is a CREATE. "Move the TechCorp deal to Closed Won" is an UPDATE. "Show me all deals closing this month" is a READ. "Remove the duplicate contact" is a DELETE. Once you frame it this way, the entire CRM becomes a set of tools that the AI can invoke.

Tool Calling: How the AI Executes Actions

Under the hood, our AI assistant has access to a library of tools - functions that map to CRM operations. When a user sends a message, the model decides which tools to call and with what parameters. This is the same function-calling paradigm pioneered by OpenAI and adopted across the industry, but applied specifically to CRM workflows.

Here is what happens when you type "Add Maria Lopez from TechCorp, she's VP of Sales":

1. The AI model parses the message and identifies the intent as createContact
2. It extracts structured data: name, company, title
3. It calls the createContact tool with those parameters
4. The tool creates the record in the database and returns a confirmation
5. A second tool, enrichContact, runs automatically to pull LinkedIn and web data
6. The AI formats the response and shows the user what it did

The tool labels you see below each AI response - like "createContact" and "enrichContact" - are real. We show them intentionally so users can see exactly what the AI did. Transparency builds trust, and trust is critical when AI is modifying your sales data.

Smart Model Routing: The Right Brain for the Job

Not every message needs the same level of AI capability. Asking "how many contacts do I have?" is a simple database query. Asking "draft a follow-up email to Sarah referencing our pricing discussion and the case study I sent last week" requires deep contextual reasoning.

We built a three-tier routing system that matches each request to the appropriate model:

• Flash Lite - Simple queries, quick lookups, basic CRUD. These are the fast, cheap operations that make up about 68% of all requests. Response time: under 500ms.
• Flash - Medium-complexity tasks like filtered searches, multi-step updates, and structured data extraction. About 24% of requests. Response time: 1–2 seconds.
• Pro - Complex reasoning tasks like email composition, deal analysis, and multi-entity operations. About 8% of requests. Response time: 2–4 seconds.

The router itself is a lightweight classifier that runs before the main model. It analyzes the user's message, checks for keywords and structural patterns, and assigns a complexity tier. This happens in under 50ms, so the user never notices the routing decision.

The result is that 68% of requests resolve in under a second, while the complex tasks get the processing power they need. And because we are not sending every simple lookup to an expensive model, the cost per user stays low. This is how we offer bring-your-own-key pricing at a fraction of what competitors charge.

Conversation History and Context

A chat-based CRM is only useful if it remembers context. When you say "move that deal to Closed Won" after discussing TechCorp, the AI needs to know which deal you mean.

We maintain a sliding context window for each conversation. The last several messages are included in every request, giving the AI short-term memory. For longer-term context, we embed conversation summaries and reference them when relevant entities come up again.

The conversation sidebar shows your full history, organized by topic. Each conversation thread has its own context, so you can switch between a pipeline review and a contact cleanup session without confusing the AI. This is similar to how you might use separate chat threads in a messaging app, but each thread is backed by your CRM data.

Smart Suggestions: Guiding Without Constraining

One concern with chat-based interfaces is discoverability. With a traditional CRM, you can see all the buttons and menus. With chat, new users might not know what to ask.

We solved this with smart suggestion chips - contextual prompts that appear below the AI assistant's greeting and after certain responses. These suggestions are generated based on your CRM state: if you have deals closing soon, the AI might suggest reviewing your pipeline. If you just added a contact, it might suggest creating a deal or sending an introduction email.

The suggestions are not static. They update as your data changes, effectively turning the chat interface into a dynamic to-do list. The sparkle icon at the top signals that these are AI-generated recommendations, not hardcoded options.

Why Chat Beats Forms

After a year of building and iterating on this interface, we have learned that chat is not just a novel interaction model - it is genuinely faster for CRM work. Here is why:

• Batch operations are natural. "Add these three contacts and create a deal for each" is one sentence. In a form-based CRM, that is 6 separate form submissions.
• Context carries forward. "Send her a follow-up" works because the AI knows who "her" is from the conversation. Forms have no memory.
• Ambiguity is handled gracefully. If you say "add John" and there are two Johns in your database, the AI asks which one. A form would just create a duplicate.
• Complex queries are simple. "Show me all deals over $50K that haven't been updated in two weeks" is natural language. In a traditional CRM, that is a filtered view with multiple criteria selectors.

We wrote more about the broader philosophy behind this approach in our post on why forms are dead in AI-native CRMs. The technical architecture described here is what makes that vision real.

What We Learned

Building a conversational CRM taught us several non-obvious lessons. First, latency matters more than accuracy for simple operations. Users will tolerate a slightly imperfect response at 500ms over a perfect response at 3 seconds. Second, showing your work builds trust. The tool labels are not just a nice touch; they are essential for adoption. Third, suggestions are a feature, not a crutch. Even power users click the suggestion chips because they surface actions the user had not thought of yet.

If you are interested in how we handle the AI provider layer, including letting users choose their own model, that is a separate engineering story worth reading. And if you care about how we keep all of this secure on the server side, we have written about that too.