Original Message:
Sent: 04-10-2023 08:43
From: Nikhil Ponnam
Subject: Beta: Real-time Alerting
@Hichem Agrebi Thank you very much for the feedback!
Let me get back to you with clarifications on the questions you raised about muting/snoozing. And we are working on refactoring some of this functionality, to address the points you raised here - specifically muting applicable to the rule and snoozing to the alert.
Thanks,
------------------------------
Nikhil Ponnam
Principal Product Manager, Genesys Cloud CX
Original Message:
Sent: 04-08-2023 06:39
From: Hichem Agrebi
Subject: Beta: Real-time Alerting
Here's how I personally expect the alerts to work as am really struggling to understand the rationale behind current design.
Muting and snoozing alerts in the past is just something I am not able to justify in my own logic.
Actions at the Rule level:
Create: creates the rule as designed today
Delete: deletes the rule as designed today
Enable/Disable: this disables the rule for everyone
Mute: this should mute the rule for all alert recipients
Snooze: this is similar to mute but applies only for the user requesting the snooze action. It will "mute" the rule for that specific user during 15min by default then enabled back automatically.
Genesys doesn't allow to unsnooze, or unmute but would be nice if it was possible as the user could make a mistake and mute instead of snoozing. Since muting impacts other users then there must be a way to unmute if muted by mistake. Can't see a good reason for not allowing to undo these actions (may be Genesys wants to prevent impacts on the backend if users abuse this feature, in this case you can allow undoing it only once during the 15min period)
Set priority: this would be very nice to have to allow users to differentiate between alerts. valid values would be High, Medium, Low or add Critical to the list.
Feature request: allow disabling SMS and email to send only desktop notifications or alerts to AWS Event bridge as it is the case today. I don't get why we have to select email or SMS when these are subject to limits anyway. Some users just don't want SMS and email and it should be fairly simple to disable these> I see already many requesting this feature.
The Mute if applicable to all users, is not clear to me as I could be a recipient of 10 alerts configured by other admin, would only the rule creator have the mute privilege or any recipient can mute the alert for everyone?
The way it is currently designed seems to force users to create rules for themselves only.
In my humble opinion, Mute and snooze should both only apply to the requesting user. With mute being indefinite and requiring an unmute action (that isn't offered by Genesys) and snooze being for a configured time that enables alerts to get through after the snooze period elapses.
I wish Genesys publishes a clear and detailed alert workflow so it becomes clear who is impacted and what makes sense to do as a workaround for those who don't agree with the way it has been designed.
Actions at the Alert level:
Read/Unread: as designed today
Delete: deletes the selected alert as designed today
View Alert rule: opens the link to alert rule as designed today
Mute: update the rule for all configured alert recipients. The rule remains muted until the user unmutes it.
Snooze: update the rule for the requesting user only. The difference to mute is that the rule applies only to the requesting user and is paused for 15min and resumed automatically after that.
I assume this is how Genesys wants it by design.
It's not a bad idea to allow users Snooze and Mute the alert rules at the alert level, but the Rule Id should be updated and not the Alert Id.
This allows the the users to avoid having to navigate to the rule to update it
=> all alerts linked to the muted/snoozed rule will show the mute/snooze icon
If alerts are always designed to be user specific then we don't need to specify the userId when calling the API, that's for Genesys developers to figure out what's best to do.

This is assuming Mute applies to all recipients and snooze applies only to the requesting user.

My personal feature request: Enhance alert evaluation with schedules. (Good to see it is already logged under ANLS-I-1275)
Schedules/Schedules groups is already an existing feature so it's just a matter of leveraging it for alerts.
Alerts are very useful but by design they should not turn to a spam tool. So using schedules should be implemented from the start as far as am concerned.
Thanks Genesys for your continuous efforts and for listening to your customers.
------------------------------
Hichem Agrebi
Original Message:
Sent: 04-07-2023 09:44
From: Hichem Agrebi
Subject: Beta: Real-time Alerting
Hi Nikhil, I tried snooze and mute and not convinced these are working properly.
My rule is simple, it's based on my user status if availabele state > 5 sec
When I snooze the alert, it shows snooze in 15min, however if during the next 15min I change my status to on Queue then back to available for over 5 sec I get the desktop notification + email.
I tried the same with muet and getting the same result and get notified
The design doesn't make sense from my perspective as users shouldn't be snoozing or muting an alert but these actions should rather apply to the rule alert.
I don't get the logic of muting an alert that happened in the past when you should rather apply this to the alert rule and only if the rule is enabled, as otherwise you can mute and snooze and not even aware that you disabled the Alert rule. May be it's just me struggling with the concept here.
Also if you have the same past alerts from the past days multiple times and one of these is muted and the other is snoozed, it's unclear how to interpret these.
So really my expectation here is that these actions should apply to the Rule not the the resulting alert.
I still don't understand muting alerts if you say it stops alerts acorss the board, that still applies only to the configured persons in the alert rule or what other persons beyond?
I also have a request to please allow disabling email and SMS if the user only wishes to receive desktop notifications, why do we force the user to get spammed by email and SMS when it would ave been easy to make these notification media optional and the desktop notification + Event bridge notification being by default always enabled: many thanks for considering this request.
Thanks for clarifying how this was designed to work
Regards
Hichem
------------------------------
Hichem Agrebi
Original Message:
Sent: 03-30-2023 09:55
From: Nikhil Ponnam
Subject: Beta: Real-time Alerting
@Alberto Vilchez - sorry for the late reply.
Muting alert stops notifications across the board for the specific alert.
Snoozing alert stops notifications to the parties listed in the rule.
The time period for which the alert will be muted or snoozed is 15 minutes.
Mark as read - will result in the alert not showing as counted in the bell icon on the top right. Unread alerts stay counted (on the bell icon on top right) until 8 hours, after which they will remain in the user's Genesys Cloud inbox where they will be still shown as unread alert.
Delete alert deletes the alert from the inbox. Alerts older than 30 days will be automatically deleted from the user's alerts inbox by Genesys Cloud
Thanks,
------------------------------
Nikhil Ponnam
Principal Product Manager, Genesys Cloud CX
Original Message:
Sent: 03-20-2023 16:49
From: Alberto Vilchez
Subject: Beta: Real-time Alerting
Hi,
Could you please clarify what are the alert managment options used for and how do they affect the notifications (toast, SMS, email) behavior?
- Mark as Read
- Snooze Alert
- Mute Alert
- Delete Alert

Thanks.
------------------------------
Alberto Vilchez
Evolutio Cloud Enabler, S.A.
Original Message:
Sent: 01-19-2023 09:42
From: Nikhil Ponnam
Subject: Beta: Real-time Alerting
Hi everyone,
We are excited to announce the availability of Real-time Alerting feature beta to the community.
This feature enables the real-time alerting capability based on user-defined alerting rules. With this feature, users can define multi-conditional alerting rules based on queue and agent metrics as well as enable notifications via email and SMS.
If you are interested, please sign-up by filling out the form below.
Real-time Alerting Beta Sign-up
After we enable the feature for your org, we will reach out to you to confirm and provide the documentation for high-level feature overview.
Thanks,
#BetaAnnouncement
#NowRecruiting
------------------------------
Nikhil Ponnam
Principal Product Manager, Genesys Cloud CX
------------------------------