Before you start configuring, we recommend checking out our article on the overall logic of automation rules in Deskie or watching the quick video guide on rules.
Task: hand off first-line communication to the AI assistant
This logic requires you to have the integration with OpenAI — Responses API connected.
When a customer reaches out to support, the AI assistant jumps in first to handle their message. If the customer needs to speak with a human, they have clear instructions on how to request an agent, and when they do, a support specialist joins the conversation. Plus, if the AI runs into an error or can’t resolve the issue, a human agent steps in automatically. After the human interaction, if further AI assistance is needed, the case can easily be handed back to the assistant.
The flowchart outlines how the rules trigger this handoff process. To get everything running smoothly, you’ll need to set up 6 rules: 1 for new cases, 4 for updated cases, and 1 for existing cases.
Step 1: Set up your assistant
This example uses the "OpenAI — Responses API" integration, which we named "AI assistant 'YourFlight'" when we connected it. For more on configuring and using it in Deskie, see here.
The example instruction and the file uploaded to the Vector Store are provided for illustration purposes only and represent just one possible approach, not a definitive template.
1. In the integration's connection/edit form, add an instruction for the assistant and define how it should behave. Our test assistant for the fictional ticket sales service "YourFlight" received the following guidelines:
Example of instructions for the assistant
#1. Role You are a support agent at the company "YourFlight". Your task is to provide accurate answers based on data from the Vector Store, as well as taking into account the context and information provided by the user during the current dialogue. User's name: [user_full_name] --- #2. Main Rules 2.1. Provide one clear and comprehensive answer without alternative versions. 2.2. DO NOT start with a greeting or brief introduction. The greeting has already been given. 2.3. Maintain a polite and professional tone. 2.4. Always take the conversation context into account: be able to connect short or incomplete user questions to the topic discussed in earlier messages of the current session. 2.5. Periodically address the user by name using [user_full_name], if the name was provided. Do this naturally within the response (not in every message, but tastefully and where it fits) to keep a personal, polite tone. --- #3. Workflow 3.1. Receive a question from the user. 3.2. Check the message format: - If the message consists solely of a file in an unsupported format that the assistant cannot process — respond with the phrase: Unfortunately, I cannot answer your question. 3.3. Use the dialogue history to take the user's previous messages into account, understand the context of the current question, and answer questions about the dialogue itself. Take information about the company, services, and other subject-matter data only from the Vector Store. 3.4. Formulate the response: - If the question relates to the earlier conversation — use the dialogue history to answer. - If the question requires information about the company, services, or other subject-matter data — use the data from the Vector Store, taking the dialogue history into account to understand the context of the question. - If the user's question is too brief or unclear and its meaning cannot be recovered from the context — ask a clarifying question using only the following phrase: Please provide more details so I can give you a comprehensive answer. - If the user's question is substantial and clear, but there is insufficient data in the Vector Store and the dialogue history – report this using only the following phrase: Unfortunately, I cannot answer your question. - If you have twice in a row responded with the phrase "Unfortunately, I cannot answer your question," and the next question also lacks sufficient data in the Vector Store or the dialogue history, respond only with this phrase: It seems I'm struggling. Better call human! - Never respond with phrases like: ...there is no information in the provided data... --- #4. Examples Example 1 (using the Vector Store): Question: "Is information about purchased tickets saved in my personal account?" Answer: "Yes, full information about purchased tickets is available in your personal account." Example 2 (linking context and follow-up questions): Prior conversation: User: "Can I cancel my booking 14 days before departure?" Assistant: "Yes, cancelling 14 days before departure is free of charge, with a full refund." New user question: "What about 7?" Answer: "Cancelling a booking 7 days before departure incurs a fee of 20% of the ticket price; the remainder is refunded to your card."
We explicitly instructed the assistant to take subject-matter data only from the files we uploaded, and to use the dialogue history to understand context and questions about the conversation itself.
2. Upload the data for the assistant’s responses into the Vector Store. For our test bot, we added this file: https://gist.github.com/deskie-io/96fe8826b3251c31d6e27669d76eade8
3. Enable context tracking. In the "OpenAI — Responses API" integration, tick the checkbox "Consider the context...".
Step 2: groups and access
Create a group in advance where you will place the cases for the assistant – we named it "AI in action". Also, create a group where cases resolved by the assistant without involving an agent will be moved – we called it "Resolved by AI". If you use business hours and SLA settings, exclude these groups from those configurations.
Responses sent by the AI assistant through rules in Deskie are treated as regular auto-responses. This means they are not counted when calculating response speed metrics in reports or when calculating SLA compliance. Read more
Make the group "AI in action" the default group in channels where the assistant handles first-line cases. If you plan to delegate only some cases to the assistant, you can move them to this group using rule 1) for new cases; be sure to include your conditions in the rule.
The "Resolved by AI" group is intended for cases where the assistant has responded without agent involvement. This simplifies analyzing AI performance and excludes such cases from overall reports.
Rules that forward customer messages to the assistant set the case status to "pending", so agents won’t be distracted. However, if desired, you can fully restrict agents’ access to the "AI in action" and "Resolved by AI" groups or set their access to read-only.
Step 3: set up rules
In our example, we focus on rules for chats – these are defined by the condition "Channel – is equal to – any synchronous channel". Our rules will be triggered regardless of business hours, as if both the bot and agents operate 24/7. If you need different logic, include it in the conditions by specifying the required business hours set in the "All of the following conditions" block. If you require different logic for business and non-business hours, you have to set up separate rules for each period.
1) The rule for new cases will forward the customer's first message to the assistant and send the assistant’s response back to the customer.
The user’s first message in the case is passed through the variable [case_description]. The assistant’s response is recorded via the variable [ai_response_by_text_request], but you can also add your own text in the response field, which will always be sent along with the assistant’s reply. We have added:
a greeting;
an explanation for the customer that they are communicating with an AI assistant, along with instructions on how to request a human agent.
2) The rule for updated cases will forward the customer's subsequent messages to the assistant and send the assistant’s response back within the case.
The customer’s subsequent messages in the case are passed through the variable [last_message], while the assistant’s response continues to use the variable [ai_response_by_text_request]. In addition to this, we have kept an explanation in the response field informing the customer that they are communicating with an AI assistant, along with instructions on how to request a human agent
3) The rule for updated cases connects an agent to the conversation when the customer requests one using the method specified in the assistant’s response.
The customer is not following the instructions
For cases where the assistant is unable to help, we separately included a fallback phrase in the OpenAI-side instructions to be used if it fails to provide a useful answer twice in a row. If, after the phrase "It seems I'm struggling. Better call human!" the customer writes to the bot again instead of contacting a staff member through the method you specified, you can route the conversation to a staff member using a rule.
The rule logic is based on the condition "Subject or content – contains – ..." checking the case subject and the last three messages in the case. The trigger for the rule is a message sent by the customer after the assistant’s response: "It seems I'm struggling. Better call human!"
An example of the conditions for such a rule for updated cases:
This rule helps ensure that cases from customers who get confused by the flow are not overlooked, and also prevents the assistant from being used inappropriately, for example for meaningless messages and wasted tokens. The rule’s actions can be configured in the same way as rule 3, which brings a staff member into the conversation when the customer asks for one using the method specified in the assistant’s reply.
4) The rule for updated cases connects an agent if the assistant responds with an error instead of an answer.
Sometimes the AI assistant may respond with an error. However, all other rule actions that send requests to the assistant are still executed, including setting the case status to "pending". In such situations, Deskie adds a system note along with a non-removable label ai_error_in_rule_action.
To ensure the customer does not remain without a response, these situations can be monitored through rules for updated cases using the following conditions:
More information about errors when using the AI assistant is available here.
In Deskie, it is not possible to activate a chat using the standard rule conditions. If your scenario requires the chat to appear in the active chats interface, this logic can be configured through a webhook sent to the Deskie API address. More details
Chat activation via API
Chats in Deskie are activated only when a customer message or an agent’s response is added to them. To activate a chat, we will use a rule to trigger a webhook to the Deskie API, which will add a message to the case on behalf of the customer.
On the customer’s side, such a message will appear only in their personal account and will not be delivered to the messenger itself. Nevertheless, choose text that will be clear to the agent and will not confuse the customer if they ever see it.
Instructions on setting up a webhook for chat activation
A webhook sent to the Deskie API will add a message on behalf of the customer and simulate chat activation.
Within the rule, pick the action "Send webhook"
Choose the POST method;
In the "URL for sending request to" field, specify:
https://[domen].deskie.io/api/cases/[case_id]/messages.json
If you have a custom domain connected, you can use it:
https://[name].[domen]/api/cases/[case_id]/messages.json
Tick the box "authentication is required via", then select the "login-password" option. In the "Login" field, enter the login (email address) of an agent with full access rights. In the "Password" field, enter the API key, which can be created by navigating to: administrator account → "Settings" section → "API" subsection;
Select "Custom request" in JSON format and enter the following request text in the "Your custom request" field:
{
"message" : {
"user_id" : "[user_id]",
"content" : "Your text"
}
}
- Detailed information about webhooks can be found here (an article and a video guide).
- API documentation is available here.
Rule examples
If you want to distribute such a chat among available agents, you will need a separate rule.
5) The rule for updated cases returns the case to the assistant when the agent believes the AI can continue the dialogue. To reconnect the assistant, the agent must add the label "assistant" back to the case.
The intended logic is as follows:
When the customer requests a human agent or the assistant responds with an error, an agent is assigned to the case. If, upon review, the agent determines that their intervention is not necessary (for example, the error was temporary), they add the label "assistant" to the case without replying to the customer. After that, the case is automatically returned to the AI for further handling.
If human involvement is needed, the agent can step in and chat with the user, for example, to help with an issue the assistant couldn’t handle. But if the next question from the customer is something the assistant can easily manage, the agent simply adds the "assistant" label instead of replying, and the user’s latest question gets sent back to the assistant.
6) The rule for existing cases will close the case if the customer doesn’t send any more messages, assuming the assistant has successfully resolved the issue. Since we’re setting up rules for real-time chat, we’ve added the condition "Hours since "pending" status is set – is greater than – 0.5". This means the case will be closed between 30 and 80 minutes after the AI's last response. You can find more details about how the rules for existing cases work here.