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 NameConfiguration DescriptionDefault ValueType of Alert
Request DetectionWill incoming customer messages be automatically classified as a request?TrueRequest
Request Notification ChannelWhich channel should the detected request be sent to?n/aRequest
Conversation Grouping windowThe 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.120Request, 1st Response SLA
Suppress Requests in Open Request threadsIf 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.TrueRequest
Suppress Requests in Open Ticket threadsIf there is already an open/in progress ticket thread, new messages on the thread will not be flagged as request.TrueRequest
Use Customer Name in NotificationsFor Customer related notifications, use the name of the customer instead of 'Thena'.TrueRequest, 1st Response SLA
Use Customer Logo in NotificationsFor Customer related notifications, use the customer workspace logo instead of Thena Logo.TrueRequest, 1st Response SLA
Auto Assign request to first responderAuto assign the request to the first Vendor team user who responds on a message thread that was a requestTrueRequest
Holiday CalendarArray of holidays for which response and ticket resolution SLA time calculation is suspendedNullRequest, 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 calculationNullRequest, 1st Response SLA
Working Hours in a DayDaily working hrs also known as business hours. Used for the calculation of ticket and response resolution SLAsNullRequest, 1st Response SLA
Enable the concept of Working Hours for Vendor communicationEnable Working Hrs ConfigFalseRequest, 1st Response SLA
Use First Response SLADoes the workspace have the first response SLA breach check configuredFalse1st Response SLA
First Response SLA in hoursNumber of hours before which we check for an SLA breach21st Response SLA
First Response Notification ChannelWhich channel to send the first response SLA breach alert onn/a1st Response SLA
Vendor Response in a conversationConsider a message from a vendor user or Thena app as a response to the customerTrue1st Response SLA
Reactions are a responseConsider a vendor reacting to a customer message using emoticon as a response to the customerFalse1st Response SLA
No Alert for closed requestsIf there was a message on the request, and the request was closed, don’t consider it for the SLA breachFalse1st Response SLA
Pending responses on Tickets are suppressedIf there is a customer message on a ticket, then the First Response SLA is not sent.False1st 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.