What the AI Can Know About a Deal — and What It Has to Ask
A deal card looks like a form, but it works as a log. The owner opens it to answer one practical question: what actually happened here? The AI assistant answers that question from the same material a person would use — the stage, the dates, the links to a contact and a company, and the entries in the activity feed. Nothing is read from the future.
The board is built from columns. A new firm gets six: New Lead, Contacted, Qualified, Proposal, Negotiation and Won. They can be renamed, added to, reordered or removed, so the names are a habit, not a law. A card carries the deal title, the contact and company names, start and end dates, deal type, responsible person, source, and the activity trail. There is no amount field and no probability field.
When the assistant looks for deals, it uses a locator, not a report. The list shows the deal name, stage, contact, company, dates, responsible person and the date of the last change. It can filter by words in the deal, contact or company name, or by a stage name, and it returns the newest first. The default is fifteen cards, the maximum is forty. That is enough to find a card; it is not a pipeline total.
The full card is deeper but still bounded. The assistant receives the stage, contact, company, dates, type, responsible person, creation date and the last fifteen activity entries. Each entry is shortened to three hundred characters. Notes, comments, calls, e-mails and messages attached to the card, and system entries for creation and stage changes, all appear there. Older entries stay in the CRM but do not reach the model in that call. The summary also omits fields that people see: the lead source, UTM and recurring settings are on the card, but they are not part of that reading.
This is the first honest limit: the assistant knows only what was written down. A call that nobody logged, a meeting that stayed in a notebook, a promise made in a corridor — none of it exists for the card. The assistant must not fill those gaps with a plausible story. When the trail is thin, the correct answer is that the card does not show it.
A stage move is a real change, so it asks first. When the assistant moves a card, it writes a system entry with the new column name and fires the stage event that automation rules listen to. From that moment a rule for the new stage can create a task, send a message or start an AI step. The confirmation is not decoration; it is the point where a person authorises a chain.
One distinction surprises people: moving a card through the assistant does not mark it as won. The won date is a separate mark that the board sets when a card is dragged to the last column. An assistant move to another stage clears that mark, because the deal is back in work. The trophy remains a human decision; the machine can move the card, but it cannot declare the sale closed.
Reading is treated differently from acting. A deal card contains customer notes and e-mails, and text from a customer is untrusted: it may contain an instruction that looks like a request to the assistant. After reading a card, the assistant asks for confirmation before any change, even when the owner has switched confirmations off. A sentence inside an e-mail cannot move a deal by itself.
Creating a deal follows the same pattern. A name is required; the stage defaults to the first column; contact, company, expected close date and responsible person are optional. The new card starts with a created entry, and by default a person confirms the action. If the same customer already has a card, the assistant can find it first instead of adding a duplicate — but it has to be asked to look.
Finding the right card is part of the job. Search works by words in the deal, contact or company name. When the assistant is asked to change a card by name, an exact match wins over a partial one; if several cards still match, it gets a short list and a reason to ask which one is meant. It does not pick the first result when two customers share a name. That small pause prevents a note or a stage change from landing on the wrong deal.
Then come the questions the card cannot answer. How much is the deal worth? How likely is it to close? What is the next step, and who owns it? Why did the last similar customer leave? Those are not fields, so the assistant must ask rather than invent. It can list cards in a stage up to forty at a time and read the dates, but it cannot sum a pipeline that was never priced or forecast a probability that nobody entered.
The useful requests are therefore concrete. Ask what changed on a deal since Monday, which cards are still in Negotiation and when they were last touched, or for a summary of the last fifteen entries before a call. Ask it to add a note after the call, and confirm it. The assistant is good at recall and at putting a trail into three sentences; it is not a source of numbers that were never recorded.
Automation is the reason a move deserves care. The card speaks to rules through three events: a deal was created, a deal changed stage, a deal was won. A rule can be limited to one stage, so a move into Negotiation may start a different sequence than a move into Proposal. The assistant can start the first two events when a person confirms; the won event comes from the board, because the assistant cannot mark a sale as won. That is why it asks first and writes the stage change into the history.
The value of the assistant on the deal board is not prediction. It is recall, a clean summary, and a habit of asking for the missing fact instead of inventing it. A card is only as good as the notes on it; the machine makes that clear every time it says the history does not show the answer.