A message comes in, the employee answers, the client goes quiet, a call goes out, the call ends with an outcome, and a person picks it up. In CRAIM that chain is one process drawn from six triggers, two conditions, participants and waits. This is what each piece does and how to test the whole chain before it meets a customer.
The conversation, the approvals queue and the calls are three screens, and it is easy to run them as three separate things: the employee answers here, someone approves there, a call is dialled from a list. The customer, though, experiences one sequence. The process builder exists to draw that sequence once, so nobody has to remember the next step by hand.
A process is a graph of five kinds of node. A trigger starts it. A participant decides who acts, a person or an AI employee. A condition branches on what happened. An action does the step. A wait pauses until something arrives or a period passes.
The triggers and the conditions that exist
The list is short on purpose, and the builder does not let you invent new ones.
| Kind | Available | Typical use |
|---|---|---|
| Trigger | A deal was created | Greet and qualify a new lead |
| Trigger | A deal entered a stage | Send the offer when the stage says so |
| Trigger | A message was received | Wake the employee on a reply |
| Trigger | A person on the team sent a message | Follow up on a human's message |
| Trigger | The AI sent a message | Start the wait for a reply |
| Trigger | The client went silent | Re-engage after a set period without a reply |
| Condition | The client replied | Branch: continue or escalate |
| Condition | Call outcome | Branch on what the call ended with, including a request for a person |
How the three connect
The chain most companies draw first looks like this.
- A message is received. The participant is the AI employee attached to the channel, so it wakes up, reads the thread, and prepares a reply. In copilot the reply waits as an approval card; in autopilot it goes out.
- The AI sent a message. The process waits for a reply. The condition "client replied" branches: replied, continue the conversation; not replied within the period, the client went silent.
- The client went silent. An action places an outbound call from the voice employee. The voice employee can search the catalogue and the customer's record during the call, and it has one tool the chat employee does not: asking for a human.
- Call outcome. The condition branches on how the call ended. One outcome is "handoff requested", which means the customer or the employee asked for a person; the branch for it creates a task for a named participant with the thread and the call attached.
- A person acts. The participant node names who. The process passes through a human participant without waiting for them to finish, so the task is the handover, not a pause in the graph.
One thing the participant node does that is easy to miss: when you put an AI employee or a person as the participant, the builder fills that identity into the steps below it. You do not repeat who acts on every node.
What the approval queue is in this chain
The approval is not a separate process, it is a state of the message the employee prepared. The card in the queue carries the draft, the customer context and the facts used, and the company's owners and administrators are notified that an employee is waiting, on Telegram if connected. Approve sends it and the process continues as if the employee had sent it; reject stops that branch. The person editing the draft is editing the message the trigger "AI sent a message" will fire on.
How to test the chain
Test from the customer's side, once, end to end, before a real customer does.
- Send a message to the connected channel from a phone that is not in the CRM. Find it in the inbox: a new contact, a new conversation, the owner set by the pipeline rules.
- Read the draft in the queue. Check that the facts came from the materials and not from the model's general knowledge. Approve it.
- Do not reply. Wait for the silence period you set, and confirm the call is placed. Answer it and ask for a person.
- Confirm the task appears for the named person, with the thread and the call outcome attached, and that the process shows the branch it took.
- Reply in the thread as the customer once more, and check that the employee, not the process, is the one who answers.
If a step does not fire, the usual reasons are two: the channel is bound to a different employee than the participant node names, since one channel binds to exactly one employee, or the condition is waiting on a period that has not elapsed. Both are visible in the process run's history.
Common questions
- Which triggers can start a process?
- Six: a deal was created, a deal entered a stage, a message was received, a person on the team sent a message, the AI sent a message, and the client went silent.
- Which conditions can a process branch on?
- Two: whether the client replied, and the outcome of a call. There is no condition on deal fields.
- How does a call hand over to a person?
- The voice employee has a tool to request a human. The call ends with the outcome "handoff requested", the call-outcome condition branches on it, and an action creates a task for the named person with the thread and the call attached.
- Does the process wait for a person to finish their task?
- No. A human participant is passed through; the task is the handover. Waits in a process are for replies and for periods of time.
- Where does an approval sit in the process?
- It is a state of the message the employee prepared. Approving sends it and the process continues from the trigger that the AI sent a message; rejecting stops that branch.