Assistance required to improve the voice call script received for P1/P2 alerts through JSM On-Call

Ashok Murugesan

Currently, the voice notification only indicates that a JIRA alert has been received, without providing any relevant incident information or context. This makes it difficult for the on-call engineer to understand the nature and severity of the incident, particularly when alerts are received outside of business hours or during late hours.

As part of our current setup, JSM On-Call is integrated with Helix, which is our incident management tool. We would like to explore whether relevant details from the Helix incident can be included in the voice call notification, such as:

• Incident/Alert number
• Priority (P1/P2)
• Short description or incident summary
• A brief description of the issue or impact
• Any other critical information that would help the on-call engineer quickly understand the incident

Could you please advise whether the JSM On-Call voice call script can be customized to include these details from the corresponding Helix incident?

If this is supported, please also advise on the recommended approach or configuration required to implement it.

Josh

Hi — JSM On-Call / Opsgenie-style voice notifications are driven by the alert's message fields, not by a free-form IVR script editor. You generally cannot drop in an arbitrary Helix template for the spoken text; you shape what gets spoken by shaping the alert that triggers the call.

Practical approach:

1. Put the spoken details into the alert message / description when the alert is created or updated from Helix: incident/alert number, P1/P2, short summary, impact. Voice typically reads the alert message (and sometimes alias/priority), so if Helix only sends "Jira alert received," that is all the engineer will hear.
2. Check the Helix → JSM On-Call integration mapping. Map Helix fields into alert Message, Description, and Priority. Many integrations default Message to a generic string unless you override the field mapping.
3. Notification rules. Confirm the voice contact method is attached to the P1/P2 policy you care about, and that the rule is not using a stripped-down "alert created" template.
4. Test with a manual alert whose Message is P1 INC12345 — Payment API down — checkout failing. If that is spoken correctly, the voice path is fine and the gap is entirely in what Helix sends.

If Helix cannot push a rich Message today, an interim automation on the Jira/On-Call side (when alert is created → update alert message from linked issue fields) is usually easier than customizing the telephony script itself. Full custom TTS scripts are not a native On-Call admin setting.