Configure Alerts
Personalise Alerts to work for your requirements
We have added the ability to configure alerts basis your preferences in interacting with your customer. These preferences are currently backend configurations, but will soon be available within the webapp.
As an example, if you see that your customers typically do not thread messages, and send you multiple messages for one underlying request, you can set the Conversation Grouping Window to your liking.
Configuration details
Configuration Name | Configuration Description | Default Value | Type of Alert |
---|---|---|---|
Request Detection | Will incoming customer messages be automatically classified as a request? | True | Request |
Request Notification Channel | Which channel should the detected request be sent to? | n/a | Request |
Conversation Grouping window | The window (in seconds) within which all customer messages are grouped as a single unit. Only one message in a grouping window can have workflows (request, sla, etc) on it. | 120 | Request, 1st Response SLA |
Suppress Requests in Open Request threads | If there is already an open/in progress request thread, new messages on the thread will not be flagged as request. Basically, one thread is one request until the request is closed. | True | Request |
Suppress Requests in Open Ticket threads | If there is already an open/in progress ticket thread, new messages on the thread will not be flagged as request. | True | Request |
Use Customer Name in Notifications | For Customer related notifications, use the name of the customer instead of 'Thena'. | True | Request, 1st Response SLA |
Use Customer Logo in Notifications | For Customer related notifications, use the customer workspace logo instead of Thena Logo. | True | Request, 1st Response SLA |
Auto Assign request to first responder | Auto assign the request to the first Vendor team user who responds on a message thread that was a request | True | Request |
Holiday Calendar | Array of holidays for which response and ticket resolution SLA time calculation is suspended | Null | Request, 1st Response SLA |
Days that are working in a month (e.g. Monday- Saturday). | Array of Working Days used for the purposes of response and ticket resolution calculation | Null | Request, 1st Response SLA |
Working Hours in a Day | Daily working hrs also known as business hours. Used for the calculation of ticket and response resolution SLAs | Null | Request, 1st Response SLA |
Enable the concept of Working Hours for Vendor communication | Enable Working Hrs Config | False | Request, 1st Response SLA |
Use First Response SLA | Does the workspace have the first response SLA breach check configured | False | 1st Response SLA |
First Response SLA in hours | Number of hours before which we check for an SLA breach | 2 | 1st Response SLA |
First Response Notification Channel | Which channel to send the first response SLA breach alert on | n/a | 1st Response SLA |
Vendor Response in a conversation | Consider a message from a vendor user or Thena app as a response to the customer | True | 1st Response SLA |
Reactions are a response | Consider a vendor reacting to a customer message using emoticon as a response to the customer | False | 1st Response SLA |
No Alert for closed requests | If there was a message on the request, and the request was closed, don’t consider it for the SLA breach | False | 1st Response SLA |
Pending responses on Tickets are suppressed | If there is a customer message on a ticket, then the First Response SLA is not sent. | False | 1st Response SLA |
Conversation Grouping
This feature is turned on by default.
In Slack, a customer can send multiple messages within a channel, instead of threading messages. An example could look like this (where Unmukt is a customer).
Lets take First Response SLA as an example here. These messages were all sent within 60 seconds of each other, and Tony (the vendor) responded to one of them.
Sending you different alerts for this group of messages creates noise and confusion, especially if you have responded to one of those messages. That is why we have introduced Conversation Grouping.
Using this feature, you will only be alerted when a group of messages from the customer have not been replied to.
A grouping consists of multiple customer messages within 2 minutes. This time limit is configurable basis your requirement. In a grouped message set, one response to any customer message ensures that you do not get alerted for a first response breach.
Request Closed should suppress First Response
This feature is turned off by default.
An alert is sent whenever a request is detected (if enabled). If the vendor team marks this request as closed, then the alert for first response on that message will be suppressed.
The rationale here is that the user has already highlighted that there is no further action required on this message, and so sending an alert for pending response on this message adds no value.
Reactions should be included as a response
This feature is turned off by default.
Often, a reaction to a customer message is enough to acknowledge the message. This is basis the communication style of your organisation. Using this configuration, you will not be alerted if there has been an emoticon reaction used to respond to a customer message.
Pending responses on Tickets are suppressed
This feature is turned off by default.
When you create a support ticket, and there is a customer message on that ticket, then the first response SLA will not flag if this feature is set to 'on'.
The rationale here is that the support team is often sitting on tools like Zendesk, Freshdesk, Intercom, and so sending a Slack alert to them is not necessarily helpful. Also, each of these individual tools has advanced alerting themselves, so we would rather not duplicate functionalities.
With that being said, if you want to send an alert outside of Slack, then we can set that up as well.
Updated 5 months ago