Answering customer messages with workflows

In short: Every customer message is first read and understood. Then the event Message read (message.understood) goes to your workflows. A workflow with the step Write the reply (agent.reply) has an AI agent write the reply, as a proposal in the ticket. If you want to answer differently per kind of question, sort first with Choose from a list (agent.choose) and give each route its own reply step. Put everything for one message in one workflow.

Where to find this

Go to Account > Workflows. The workflow Answering customer messages (label Standard) answers every customer message by default. You need the role Organisation admin to change it or to create an answering workflow of your own.

The path of a customer message

1. A customer sends a message. The event A message comes in (message.received) fires. Workflows on that trigger start straight away, even before aishaa has read the message.
2. aishaa reads the message and determines the language, the question in one sentence, the topic on your topic map, whether it is urgent and whether a reply is needed.
3. The event Message read (message.understood) fires. Every active workflow with this trigger and matching conditions starts a run, each on its own.
4. In a workflow, the step Write the reply writes the reply. The AI agent looks up what it needs itself (knowledge, earlier replies, data from connected systems through its skills) and puts a proposal in the ticket.
5. A colleague sends, edits or rejects it. Only where a person has allowed the AI agent to send by itself on the topic of this message, and every guard holds, does the reply go out by itself.

A message that no workflow answers gets no proposal. It is then simply for a colleague, like any unanswered conversation.

What Message read knows

You can use these fields of message.understood in trigger conditions and in steps (as {{trigger.<field>}}):

A step can also read the content of the message and the ticket, for example {{trigger.message.text}} (the text of the message), {{trigger.ticket.number}} (the ticket number) and {{trigger.ticket.customerName}}. You cannot use that content in a trigger condition; test it in a Condition or Choose a route step. All fields are listed in Triggers and events.

The standard workflow

At the first customer message, every organisation gets the workflow Answering customer messages, if there is no workflow of its own yet that writes replies. Its definition:

{
  "trigger": { "event": "message.understood" },
  "steps": [
    { "id": "reply", "block": "agent.reply", "label": "Write the reply", "inputs": { "agent": 12 } }
  ]
}

Here 12 is the number of the AI agent that replies. That is the AI agent the organisation started with. If you want a different AI agent to reply, choose it under Agent in the step and publish.

The Write the reply step

The step returns draft (the proposal), replyNeed, reason, sentByItself (true or false) and heldBack: why the reply stayed a proposal. You also see that reason on the canvas:

Write the reply only works in a workflow with the trigger Message read. The reference for all agent steps is in Building blocks: agents.

Sort first, then answer per route

If you want to do something different per kind of question, sort the message first with Choose from a list (agent.choose). An AI agent reads the message and picks one of your options, or other. Every option is an exit of its own.

The canvas of an answering workflow: the trigger Message read, a Choose from a list step with three routes and other, and a Write the reply step per route (menu Account > Workflows, open a workflow).

1. Open the standard workflow (or create a new workflow with the trigger Message read).
2. Add a Choose from a list step and move it to the top with Move up.
3. Under Options, enter short words, such as retour, levering, klacht. At most 30, each at most 80 characters, not other.
4. Under What each option means, write for each option what it means (at most 400 characters). The AI agent chooses on that basis.
5. Optionally, under Label per option, choose the label that goes on the conversation when that option is chosen. That way, sorting and labelling are one step.
6. Switch on May choose several if a message can be about several things. The AI agent then chooses every option that clearly applies (output choices), and puts on the label for each chosen option. The route follows the option that fits best.
7. Leave What the agent reads on {{trigger.message.text}}, unless you want something else to be sorted.
8. Connect a step to each exit (If retour, If levering, If other). Usually that is a Write the reply step with its own Extra instruction for this step.
9. Under If this fails of the sorting step, set the reply step of other, so that the customer also gets a reply if sorting does not work.
10. Try it out on a few real messages and publish.

Per route you can also do something other than a reply:

Sorting without AI is also possible: with a trigger condition or a Condition step on trigger.topicId, or with Choose a route (flow.switch) on {{trigger.channel}}. That costs no AI, but uses the topics of your topic map instead of your own options.

A complete example with JSON is in Workflow recipes.

A compact sorting workflow

{
  "trigger": { "event": "message.understood" },
  "steps": [
    { "id": "sort", "block": "agent.choose", "label": "Determine what the message is about",
      "inputs": {
        "options": ["retour", "klacht"],
        "explanations": { "retour": "wants to return or exchange something", "klacht": "is unhappy with a product or service" },
        "input": "{{trigger.message.text}}"
      },
      "exits": { "retour": "reply-retour", "klacht": "reply-klacht", "other": "reply" },
      "onError": "reply" },
    { "id": "reply-retour", "block": "agent.reply", "label": "Answer the return question",
      "inputs": { "instruction": "Explain the returns procedure and mention the time limit." } },
    { "id": "reply-klacht", "block": "agent.reply", "label": "Answer the complaint, always as a proposal",
      "inputs": { "instruction": "Acknowledge the problem and name a concrete next step.", "send": "propose" } },
    { "id": "reply", "block": "agent.reply", "label": "Answer the message" }
  ]
}

Everything for one message in one workflow

Workflows have no priority over each other. Every workflow whose trigger matches starts. So put everything to do with answering a message in one workflow: sorting, and the reply per route.

• If you build an answering workflow of your own, change the standard workflow, or pause it as soon as your own workflow goes live. Otherwise both answer every message.
• Workflows that do not answer but do something next to the reply (put on a label, assign, leave a task) can simply stand on their own.
• A workflow that sends the customer something separate from the reply, such as an acknowledgement, you set to May write next to an answer.

If two workflows answer the same message

Nothing blocks. What happens:

1. The first Write the reply step that starts writes the reply.
2. A Write the reply step in another workflow writes a proposal of its own next to it. In the ticket you move between the proposals with Previous proposal and Next proposal. Each proposal shows which workflow it comes from.
3. Whoever sends sees the notice This customer already got a message about this from workflow {name}., with Open workflow. An Organisation admin also sees {name} may write next to an answer, stop pointing it out. That button switches on May write next to an answer for that workflow, so that the notice no longer appears.
4. A reply that would go out by itself stays a proposal if another workflow already wrote to the customer about this message (Another workflow already wrote to the customer about this message). Otherwise nobody would see it.

On the ticket above the editor the notice This customer already got a message about this from workflow …, with the buttons Open workflow and … may write next to an answer, stop pointing it out.

The editor already warns you beforehand. The Workflow panel shows Also active on this trigger and writing to the customer: with the names of those workflows. When you Publish, you see the message Also writing to the customer, with Publish anyway and Cancel. A workflow with May write next to an answer does not count for this. Within one workflow aishaa reports nothing: there you see on the canvas what happens.

Messages that no workflow answers

• If no workflow with a reply step starts, or the last answering run ends without a reply, aishaa closes the processing of that message without a proposal. The conversation is then for a colleague.
• If a step fails, the workflow itself determines what happens: via an exit such as failed or via If this fails. Nothing takes over by itself. You see a failed run with the workflow.
• If the customer writes again before the reply has started, the run for the older message stops (status Taken over by a newer message) and the new message is answered. A reply that is already being written is set aside by aishaa if it is outdated.
• If a conversation is closed after the message came in, no proposal comes, unless a colleague asks for one.
• If a colleague asks for a proposal themselves, the AI agent of the conversation writes it straight away, outside the workflows.

Proposals and trust

Every reply from an AI agent starts as a proposal. Per topic, a person can let an AI agent send by itself, once that AI agent has built up enough trust there: enough proposals that colleagues sent unchanged. Even then, a reply only goes out by itself if:

• the step has Send by itself set to Where the agent may (earned and allowed per topic);
• the organisation’s emergency stop is off and AI is not paused;
• the AI agent still earns it and the reply does not fall in the fixed sample that always goes past a colleague;
• the reply has no values to fill in, the AI agent did not ask for a check itself and the safety check allows it;
• no other workflow already wrote to the customer about this message.

If you want a route never to send by itself, set Send by itself to Never: always a proposal. See Trust and letting an agent send by itself.

Workflows from your earlier settings

Organisations that had automations before the switch to workflows got them once as workflows of their own, with Made by aishaa from your earlier settings in the description:

What a workflow could not take over is stated in the description. The old settings pages point to the workflows.

Good to know

• Write the reply does not start a new analysis: it completes the reading of the message. Per run, one step answers the message. So do not put two Write the reply steps one after the other in the same route: the second one fails.
• The label Draft written means that the reply is in the ticket as a proposal.
• You cannot delete an AI agent that is in a workflow step.
• On the Agents page you see which AI agent replies where, with Change in workflow to change that.
• The sorting choice uses the instructions of the chosen AI agent. Without a chosen AI agent, the AI agent that the organisation’s answering workflow names makes the choice.
• The exits of Choose from a list are exactly the options as you type them. If you edit an option, check the route.

Related

• What are workflows
• Workflow recipes
• Building blocks: agents
• Building blocks: conversation and messages
• Triggers and events
• Trust and letting an agent send by itself
• AI agents
• Taxonomy: support areas and query patterns