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.