An approval that takes a minute to understand gets answered tomorrow. In CRAIM an AI employee's proposal is an action card: a title, a summary, the preview, the customer context and the facts it used, with approve, edit and a request for another version. Here is what the card carries, who gets told, and how to write instructions so the cards are worth reading.
Approvals fail in a predictable way. The request arrives without context, the reviewer has to open the thread to understand it, opens it later, and by then the customer has written again. The employee did its job in twenty seconds and the reply went out the next afternoon.
The fix is not to approve faster. It is to make the card answerable in the time it takes to read it, and to make sure the right person sees it arrive.
What the card carries
Every proposal an employee makes is stored as an action with the same shape, whatever the kind: a message draft, a CRM update, or a next-step suggestion. The card the reviewer sees is built from those fields.
- The title: what the employee wants to do, in one line. "Reply to Anna about order 1042", not "New draft".
- The summary: why, in one or two sentences, with the facts that decided it. Paid on the third, shipped on the fifth, carrier says out for delivery.
- The preview: the message itself, or the field change, exactly as it would go out.
- The customer context: the conversation the action belongs to, one click away, and the deal it sits in.
- The status: suggested, pending approval, approved, rejected or cancelled, so a card never leaves the reviewer guessing what already happened.
- Three controls for a draft: approve and send, edit by hand, or ask the employee to regenerate or revise it with a note. Editing by hand does not consume a run; asking for a revision does.
The card shows up where the reviewer already works: in the conversation, in the workstream chat, or on the dashboard, depending on the action's preferred surface. And it triggers a notification, "an AI employee is waiting for approval", with the employee's name and the action's title, delivered through the channels the account has connected, which since September includes Telegram.
Who should be asked
The notification goes to the company's owners and administrators; the card itself sits in the conversation, where its owner works. Two rules make that work in practice.
| Rule | How to set it | What goes wrong without it |
|---|---|---|
| Every conversation has an owner | Pipeline rules assign one on creation; the participant node in a process names one explicitly | Cards land in a queue nobody owns and age there |
| Expensive actions have a fixed policy | Set the approval policy of discounts, term changes and cancellations to "always" | In autopilot they go out without anyone; in copilot they hide among routine drafts |
Writing instructions that produce good cards
The summary on a card is written by the employee, and it is only as clear as the instruction that told it what matters. Three lines in the instruction change the cards more than anything else.
- Name the facts a reviewer needs to decide. "When proposing a discount, state the deal amount, the margin rule from the offers document and the customer's reason" turns a vague request into a decision.
- Say what to do when a fact is missing. "If the delivery date is not in the order, say so in the summary and do not estimate" keeps the card honest rather than plausible.
- Say when not to ask at all. An employee told to hand a complaint to a person immediately creates a task, not a card, and the reviewer's queue stays for decisions.
Explain the outcome, in the thread
A rejected card with no reason is a mistake the employee will repeat. Rejection with a note is the fastest correction there is, because the same note, pasted into the instruction, is a rule. Approval with an edit is the same thing: compare what you changed with what was proposed, and if the change is one you would make every time, it belongs in the instruction or in the document, not in your hands.
Everything that happened to a card stays with it: who approved, what was edited, when it was sent. The person who picks up the thread next week can see that the discount was approved by a named colleague on a Tuesday, which is the difference between an audit and an argument.
Common questions
- What does an approval card in CRAIM contain?
- A title, a summary with the facts the employee used, the preview of the message or field change, a link to the conversation and deal, the status, and controls to approve, edit by hand, or ask for a regenerated or revised version.
- Who is notified when an employee is waiting?
- The company's owners and administrators receive a notification naming the employee and the action, through the channels the account has connected, including Telegram. The card itself appears in the conversation it belongs to.
- What is the difference between editing a draft and asking for a revision?
- Editing by hand changes the text before sending and costs no run. Asking for a regeneration or a revision with a note makes the employee run again and consumes balance.
- Which actions should always require approval?
- Anything that costs money or changes terms: discounts, changes of conditions, cancellations. Set their approval policy to always; it holds in autopilot as well.
- How do I stop the employee from asking too often?
- Tell it in the instruction when to hand over instead of asking, and which facts it must include when it does ask. A well-specified request is answered in seconds; a vague one waits.