You've set up a custom rating request for chats or emails, but the rules provided in the instructions don't fully align with your workflow? In this case, you can tailor the rules to suit your specific needs. Let's go through a few common scenarios:
Before you begin configuring settings, we recommend familiarizing yourself with the article on the general logic of automation rules in Deskie or watching a brief video tutorial on rules.
How to avoid sending rating requests in certain cases
Let's say you don't need to send rating requests when communicating with a specific customer/company or in other cases that meet certain criteria, which can be accounted for in the rules.
Similar to checking for the presence of a label, you can add the necessary exceptions in the "All of the following conditions" block: group, channel, specific assignee or user, keywords in the subject or content of the response, check notes, custom field data, etc.
Here's an example of the rule that won't be triggered if the group equals "Management", if the last note equals "do not rate," if the case came via Skype, and so on:
Such excluding conditions can be written in any rule that sends a rating request.
In the "ALL of the following conditions" block, the logical operator "AND" is used, so for the rule to be triggered, ALL conditions listed in this block must be met.
In the "ANY of the following conditions" block, the logical operator "OR" is used, so for the rule to be triggered, all conditions from the "ALL of the following conditions" block must be met, and at least one from the "ANY of the following conditions" block.
Attention! If you're using negative conditions with the particle "not" — such as "group is not equal to" or "labels do not contain", etc. — be sure to place them in the "ALL of the following conditions" block, where the logical operator "AND" is used. The rule will not function correctly if you place negative conditions with "not" in the "ANY of the following conditions" block.
Let's clarify with a specific example. Suppose in the "ANY of the following conditions" block, you have two conditions: "Group is not equal to General questions" and "Group is not equal to Billing".
Since this block operates with the logical operator "OR," ultimately the rule will be triggered for any group. Consider this: if a case belongs to the "General questions" group, the rule will be triggered because the condition "Group is not equal to Billing" will be met. Similarly, if the case belongs to the "Billing" group, the rule will still be triggered because the condition "Group is not equal to General questions" will be met.
If the negative conditions with "not" are placed in the "ALL of the following conditions" block, where the logical operator "AND" is used, then the rule will not be triggered in either the "General questions" group or the "Billing" group. Instead, it will only be triggered when the case is in any other group besides these two.
How to close cases without sending a rating request
There are situations when you don't need to send a custom rating request. For example, you were informed about a mass problem or bug sent a suggestion, or a customer duplicated his/her question in different channels. In such cases, there is no point in evaluating an agent's performance.
The settings will depend on which custom rating request sending logic you have chosen.
You can simply close the case manually, through the API or a rule that triggers before your rule to send a custom rating request, if you chose one of these scenarios when setting it up:
in chats — agents do not manually set the status to "closed" and the rating request is sent via a rule for existing cases;
in emails — if there is no response from the user within a specified time, the rating request is sent through the rule for existing cases.
In these scenarios, the rule sends the rating request for existing cases after the specified time the case has been in the "pending" status. Thus, if you simply set the status to "closed" in a case, the rule for existing that sends the rating request will not work, because the conditions for the case status will not be met — and the rating request will not be sent.
Adjustments to the rules you use to send a custom rating request will need to be made if you have configured the following scenarios:
In chats — agents set the status to "closed" manually, the rating request is sent through the rule for updated cases;
In emails — agents set the status to "closed" manually, the rating request is sent through the rule for updated cases;
In emails — a rating request is sent within a certain time after the agent has set the status "closed".
The task is solved using labels.
How it works:
Add a label to cases where sending a rating request isn't necessary, and track it in all the rules you've set up for the custom rating request.
What you need to do:
Add to your rules for sending a custom rating request in the All of the following conditions block "Labels — do not contain — do not send a rating request".
Example rule:
The screenshot below shows a rule for chats where a rating request is sent immediately after the case is closed, so you can use the label to not send a rating in some cases.
In the rules for emails where the rating is sent immediately when the case is closed or after the time you specify, make similar edits to implement this logic.
How to remove the "do not send rating request" label using a rule
If you want to remove the "do not send rating request" label when it is no longer needed, you will need a rule for existing cases:
The rule will be triggered 48 hours after the "closed" status is set. You can set your own value, but note that it must be greater than the value specified in the rules for existing cases to send a custom rating request, if you use them — so that the label is not deleted beforehand;
Checking the labels that are added by the rules for sending custom rating requests with the "Labels — do not contain — ..." condition is necessary in case an agent has added the "do not send rating request" label after the rating request has been sent. In these situations, you should not remove the label automatically to be able to find such cases using the filter of the all cases list and analyze the situation.
Important: If you decide to remove the "do not send rating request" label, keep in mind that it will be more difficult for you to track cases in which agents did not send a rating request. The record about adding the label to the history of actions in communication will remain, of course, but you will not be able to sort all such cases using the filter.
How to add a "do not send rating request" label using rules
If there are specific case parameters that when matched you don't want to send a rating request, you can add a "do not send rating request" label via a rule for new or updated cases.
Here are a few possible scenarios:
you use a specific email to correspond with colleagues in another department and there is no need to rate this correspondence;
customers send you a request via the feedback form, and if they select "suggestion" in the custom "request type" field, you do not need to rate the case;
you do not need to send a rating request in correspondence with specific customers or companies;
in the process of correspondence you realize that a rating request will be inappropriate - for example, you are offered to discuss cooperation;
sometimes a manager is involved in processing cases, and if he/she is an assignee for the case, you do not need to rate the dialog.
The method suggested below is an alternative to adding the necessary exceptions to a standard rating request rule.
a. Create a rule for new cases to immediately label them "do not send rating request":
under such conditions, the label will be added to both new cases initiated by customers and outgoing cases created by agents. If you need a different logic, add the "Status — is equal to — open" condition to the "All of the following conditions" block for the rule be triggered only in cases initiated by customers and "Status — is equal to — pending" for cases created by agents;
in the "Any of the following conditions" block, list the conditions under which you want to set the label and thus not send a rating request in the case.
b. If you want to take into account situations when there are changes in a case, and considering the new parameters it is not necessary to send a rating request, then create a rule for updated cases, which will set the label "do not send rating request" when necessary:
the condition "Labels — do not contain — 'do not send rating request'" ensures that the label is added only once. If the label was already added to the case earlier, this rule will not be triggered;
in the "Any of the following conditions" block, list the conditions under which you want to set the label and thus not send a rating request in the case.
How to send a request for re-rating cases
Task:
You believe an agent's rating is unfair. Or the customer didn't add it at all in the given time, and you want to resend the rating request sometime after closing. The problem is also solved through labels.
What type of rules are needed:
For updated cases — to send a customized re-rating request to the user when a label is added in a closed case.
When and how to add a label:
1. In the case where you want to send a re-rating request, the status should be set to "closed", and the labels "send rating request" and "rating received" should already be removed from the case parameters. Whether a rating was given or not does not matter.
2. Add the label "chat/email rating request has been sent" (i.e., the same label you use in your rules for rating requests). Save the changes.
3. The rules you set up for adding ratings will be triggered again.
Instructions
Select the option where you want to send a customized re-rating request:
If you want to send custom re-rating requests in emails or chats selectively — only when a label is added, then disable the rules that send custom rating requests in chats or emails respectively, and use the rules suggested in this article instead.
Sending a custom re-rating request in chats
Add a rule for updated casesthat, upon adding a label to a closed case in the synchronous channel, will send an auto-response with a rating request and set the status to "pending":
Changing the status of a case to "open" is necessary so that a new case is not created when a rating request is sent;
Ending a chat and setting the status to "pending" is necessary so that the rules for the existing ones, which you have configured for adding a rating in Deskie, count down the time for adding a label correctly. Also, a chat completed in "pending" status will not be a distraction to agents;
Add your auto-response content.
Example of auto-response text:
Please rate the support you received, this will help us become better. Current rating: [current_rating] Send back only the corresponding number or emoji: 1 — 😡 Terrible 2 — 👍 Good 3 — 🔥 Excellent
Sending a custom re-rating request in email cases
Add a rule for updated cases that, when a label is added to a closed email case, sends an auto-response with a new rating request:
When sending an auto-response using rules, the status of the case does not change, so the action to change the status to "closed" is not necessary;
Add your auto-response content.
Example of auto-response text:
Hello! Current rating: [current_rating]. To choose another option, send back only the corresponing number or emoji, where: 1 — 😡 Terrible 2 — 👍 Good 3 — 🔥 Excellent Regards, [support_center_name]. [previous_messages]
How to create a new case based on the customer's response within the case after the rating request
Some customers often continue correspondence in an old thread, even if the previous issue has been resolved and the agent has been rated. Within the standard Deskie logic for asynchronous channels, such a case will receive an open status — but will not be automatically separated into a new one, as it happens in chats. This means that such an email will not be checked by the rules for new cases, will spoil the SLA closure indicators, and may cause confusion in the work of the support department in general.
We recommend creating a rule so that in such situations a new case is created based on the user's response. You can find detailed instructions on how to set up such logic here. But if you need this logic only for closed cases where a rating was added or the customer received a rating request but did not submit it, configure a rule for updated cases, which will create a new case if the customer wrote to the old thread:
If, in cases where the customer hasn't provided a rating within the designated timeframe outlined by your custom rating request rules, you wish to reopen the case and continue the conversation within the existing thread, ensure to incorporate this scenario into the rule by including an additional condition: rating — is not equal to — "—":
We would like to remind you that for email cases, agents can always manually separate a customer's message into a separate case.
