Cookbook
Put a gate in front of a closing deal
Every sales operation has a list of things that must be true before a deal is allowed to close. Most CRMs enforce it with a rule engine. Indraft has no rule engine, so the enforcement is the agent, and that difference is worth understanding before you rely on it.
The situation
Your close checklist is real: a signed order form, a named billing contact, a close date that is not in the past, a reason if it is a loss. In a traditional CRM you would express that as validation and the system would refuse the save.
Here, moving a deal to Won or Lost is always allowed. Nothing stops an incomplete close. That is the honest starting point, and pretending otherwise would be the fastest way to have you discover it during a quarter end.
Why it works this way, and when that is wrong for you
A rule engine sounds like the stronger answer and mostly is not. Rules accumulate: within a year there are forty of them, three contradict each other, nobody can say what the fifth one is for, and the team's real skill is knowing which fields to fill with placeholder text to get past them. The checklist stops describing your business and starts describing the obstacle course.
An agent applying a written checklist can hold "unless it is a renewal under ten thousand" without a new rule, and can tell you what it found rather than only that it refused. What it cannot do is stop somebody who goes around it. If you need a close that is technically impossible to perform incomplete, this product will not give you one, and that is worth knowing now rather than in month four.
What must be true when you are done
- The checklist is written in one place, in your words.
- The agent runs it before every close, without being reminded.
- A close that fails the check is reported to you, not silently blocked.
- What the check found is on the record, so a later reader can see it.
Write the checklist as a standing instruction
This lives in the agent's own instructions rather than in Indraft: your assistant's custom instructions, your project's system prompt, whatever your tool calls it. It is the one part of this recipe that is not a call.
You
Watch it hold
You
Agent
This is the behaviour you want, and it is also the behaviour that shows you the limit. The deal did not move because the agent decided not to move it. Ask it again and insist, and it will move it, exactly as a colleague would. The gate is a habit enforced by something that reads, not a wall.
The one check the product will hold for you
Mark a field required and a new record cannot be created without it. That is enforced rather than advisory, so it is the right place for the small number of things that must exist from the first moment: a lost reason on a deal, an owner, whatever your business genuinely cannot file without.
It applies on creation only, and that limit is deliberate. A partial update is how an agent records what it just learned without restating the whole record, so demanding every required field on every write would break the way you actually work. A deal cannot come into existence without them; correcting one field at a time afterwards stays possible.
Which means the two halves divide cleanly. Required fields hold the line on what a record must contain. The agent-side checklist above holds the line on what must be TRUE before a stage changes, which is a judgment about the state of a deal rather than about the presence of a value, and no field can express it.
Put the result on the record
A check that only ever appears in a chat window is not evidence. When the close does go through, have the agent record what it verified, so the next person reading the deal sees the same thing you did.
You
Agent
Verify it
- Try to close something deliberately incomplete. If it goes through without comment, the instruction is not being read, and you want to find that out on a deal that does not matter.
- Try it in a new conversation. A checklist that only works in the session where you wrote it is not a gate. It belongs in standing instructions, and this is the test that tells you whether it actually got there.
- Read a closed deal a week later. The note saying what was checked should be there. If it is not, you have a habit rather than a record.
Run it again
Revisit the checklist each quarter, and delete from it as readily as you add. The reason a rule engine becomes an obstacle course is that nobody is ever allowed to remove a rule; a checklist in a paragraph is much easier to shorten. If a check keeps failing for the same reason, that is usually a signal about what your records are missing rather than about the deal in front of you.