253 results found

1. Transcriptions for voicemail email notifications in RingCX

   Current Behavior:
   When a call routed to a workflow or voice queue is sent to voicemail, the email notification received contains only the voicemail recording as an attachment. There is no voicemail transcription included in the email body.

   Requested Enhancement:
   Enable voicemail transcriptions to be included directly in the email notifications sent when a voicemail is left for a workflow or voice queue.

   This functionality already exists in the RingEX platform, and we would like to have the same capability available in RingCX for consistency and usability.

   Important Clarification:

   This request is not related to the Queue Voicemail Channel feature.
   The Queue Voicemail Channel routes voicemails to agents assigned to a digital channel, which is a different use case.
   The requirement is to receive voicemail transcriptions in the company email inbox that currently receives voicemail notifications, not within the queue voicemail channel or agent workspace.

   Business Value:

   Improves accessibility and readability of voicemail messages
   Reduces the need to download and listen to voicemail recordings
   Aligns RingCX capabilities with existing RingEX functionality
   Enhances customer experience and operational efficiency

   Current Behavior:
   When a call routed to a workflow or voice queue is sent to voicemail, the email notification received contains only the voicemail recording as an attachment. There is no voicemail transcription included in the email body.

   Requested Enhancement:
   Enable voicemail transcriptions to be included directly in the email notifications sent when a voicemail is left for a workflow or voice queue.

   This functionality already exists in the RingEX platform, and we would like to have the same capability available in RingCX for consistency and usability.

   Important Clarification:

   This request is not related to the Queue Voicemail Channel feature.… more

   9 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  2 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Allow moving into aftercall while on an active call
   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Caller ID Override for Callbacks in RingCX

   Currently, the callback feature has no caller ID override. By default, it uses the DNIS as the caller ID when a callback is made by the system. For calls to external numbers that are forwarded to the RingCX number, it shows the number where the external number is forwarded as the caller ID.

   Looking to have a feature or option to set the forwarded number (external number) as the caller ID.

   31 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  2 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Feature Enhancement Request: Generate Post-Call State for Bad Number Calls

   Feature Request

   Enhance RingCX to generate and update the appropriate post-call state when an outbound call is classified as a Bad Number, instead of ending the call without a standard post-call state.

   Current Behavior

   Engineering confirmed that the current behavior is expected. When a destination number is identified as a Bad Number—such as an invalid, unreachable, disconnected, or otherwise non-callable number—the call does not proceed through the normal call flow.

   Because the call is terminated or classified at an earlier stage, the normal post-call processing is not triggered, and no post-call state is generated or updated.

   Customer Impact

   The absence of a post-call state for Bad Number calls may limit the customer's ability to:

   • Track the final outcome of these calls consistently.
   • Apply the same post-call processing used for other outbound call outcomes.
   • Maintain complete and consistent call disposition/reporting data.
   • Accurately distinguish Bad Number outcomes from calls where post-call processing was not completed.

   Requested Enhancement

   • Provide a post-call state or equivalent call outcome for calls classified as Bad Number.

   Ideally, RingCX should:

   • Identify the call as a Bad Number.
   • Terminate the call according to the existing Bad Number handling.
   • Generate an appropriate post-call state or disposition indicating the Bad Number outcome.
   • Make this outcome available for applicable reporting, analytics, and downstream processing.

   Expected Behavior

   • When an outbound call is classified as a Bad Number, RingCX should provide a clearly identifiable post-call outcome, such as Bad Number, Invalid Number, or another appropriate system-defined disposition.

   This would allow customers to consistently track and report all outbound call outcomes, including calls that fail before entering the normal call flow.

   Business Value

   • Providing a post-call state for Bad Number calls would improve call outcome tracking, reporting accuracy, and automation capabilities, while giving customers a more complete view of outbound dialing activity.

   Request: Please evaluate the feasibility of generating a post-call state/disposition for Bad Number calls and consider this behavior as a RingCX product enhancement.

   Feature Request

   Enhance RingCX to generate and update the appropriate post-call state when an outbound call is classified as a Bad Number, instead of ending the call without a standard post-call state.

   Current Behavior

   Engineering confirmed that the current behavior is expected. When a destination number is identified as a Bad Number—such as an invalid, unreachable, disconnected, or otherwise non-callable number—the call does not proceed through the normal call flow.

   Because the call is terminated or classified at an earlier stage, the normal post-call processing is not triggered, and no post-call state is generated or updated.

   Customer Impact

   The absence… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Ring CX Place in Queue announcement to be able to play multiple times

   Currently, the "Place in Queue" announcement plays only once when the "Route to Agent" queue event is first triggered. The desired functionality is to have an option for this announcement to loop and repeat at adjustable intervals. Ideally, the position in queue should be recalculated and announced each time, without the need to chain multiple "Route to Agent" events sequentially.

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  1 comment  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Improved Callback Reporting and Functionality for Early Caller Disconnects

   In the current RingCX callback flow, if a caller disconnects before the system successfully queues the callback, the interaction is categorized as “Inbound ACD Callback Incomplete” in Analytics reporting. This occurs even in cases where the caller has already expressed intent to receive a callback.

   Problem:
   This classification does not accurately reflect customer intent or agent workload. From a business perspective, these interactions often represent valid callback requests that were interrupted due to timing or user behavior, rather than true failures. As a result:
   1) Callback demand may be underreported
   2) Metrics may not align with actual customer experience
   3) Reporting lacks visibility intended/successful callbacks

   Requested Enhancement:
   Introduce improved reporting granularity for callback flows where the caller disconnects before queue confirmation. Specifically:
   1) Add a new disposition or category (e.g., “Callback Requested – Caller Disconnected Before Queue”)
   2) Alternatively, provide a configurable reporting option to classify these interactions separately from true incomplete callbacks
   3) Ensure these events are trackable in Analytics dashboards and exports

   In the current RingCX callback flow, if a caller disconnects before the system successfully queues the callback, the interaction is categorized as “Inbound ACD Callback Incomplete” in Analytics reporting. This occurs even in cases where the caller has already expressed intent to receive a callback.

   Problem:
   This classification does not accurately reflect customer intent or agent workload. From a business perspective, these interactions often represent valid callback requests that were interrupted due to timing or user behavior, rather than true failures. As a result:
   1) Callback demand may be underreported
   2) Metrics may not align with actual customer experience
   3)… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  2 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. terminate calls in CX queue at end of business hours

   Our call center agents leave at 5pm. On high volume days, we may have 10 calls waiting in queue at 5pm when our agents logout for the day. We find that many of these calls will continue to remain in queue without accepting the callback option because they are unaware no one is going to be available until 8am the next morning. If we configure a queue event to disconnect calls when there are No Agents Signed In, we run the risk of disconnecting calls during the middle of the day when agents are leaving and returning from lunch. There is the chance we may have brief moments when all agents are logged out during business hours. So, the priority queue event, No Agents Signed In, is not preferred for our environment. I have configured the priority queue events for Queue closed, with a single play audio message that explains the office hours have ended and to call back during normal office hours with the event type set to “Call Termination.” However, this does not occur for active calls at 5pm. Needing an option to terminate calls with an announcement at the end of the day.

   I have an open support ticket for this question, but support has yet to provide a clear answer and is researching. This seems like a simple request. We previously used Cisco CCX and this action was in place by default.

   Our call center agents leave at 5pm. On high volume days, we may have 10 calls waiting in queue at 5pm when our agents logout for the day. We find that many of these calls will continue to remain in queue without accepting the callback option because they are unaware no one is going to be available until 8am the next morning. If we configure a queue event to disconnect calls when there are No Agents Signed In, we run the risk of disconnecting calls during the middle of the day when agents are leaving and returning from lunch. There… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. SMS Conversation Assigned to Different Agent During Active Voice Call with Same Customer

   We would like to know if there is a way to keep SMS interactions with the same agent who is currently handling an active voice call with the customer.

   Workflow:
   - An agent is on an active voice call with an install partner
   - During the call, the agent asks the customer to send photos via SMS
   - When the customer sends the SMS, the new SMS conversation is automatically assigned to a different available agent instead of the agent currently handling the voice call

   Our goal is to have the SMS conversation remain with the same agent handling the active call, allowing them to continue the interaction without transferring context or involving another agent

   We would like to know if there is a way to keep SMS interactions with the same agent who is currently handling an active voice call with the customer.

   Workflow:
   - An agent is on an active voice call with an install partner
   - During the call, the agent asks the customer to send photos via SMS
   - When the customer sends the SMS, the new SMS conversation is automatically assigned to a different available agent instead of the agent currently handling the voice call

   Our goal is to have the SMS conversation remain with the same agent handling the… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Support # (Pound Sign) as a Collectible DTMF Input in RingCX Workflows

   Currently, in RingCX workflow nodes (such as Get Voice Input or DTMF Collection), the # (pound/hash) key is hardcoded or designated by default as the Terminating Key (Termination Digit).

   Because the system intercepts # as a control signal to end input collection:

   It is automatically stripped from the collected string or ignored as a valid data character.

   Workflow designers cannot map # as a standalone interactive choice (e.g., "Press # to repeat options" or "Press # to return to the main menu").

   The input grammar masks strictly expect numeric digits (0–9), treating # strictly as a trigger to halt evaluation rather than actionable input.

   A. Configurable Terminating Key Property
   Add a configuration field in the Get Voice Input / DTMF Node properties allowing workflow designers to explicitly set or disable the Terminating Key.

   Options:

   Default (#)

   Custom (Select *, 0–9, or None)

   None (Disable Termination Key)

   B. Allow # in DTMF Input Mask & Grammar
   Allow # to be included as a valid character in standard input masks (e.g., allowing regex/grammars that match # as a valid single digit or part of a string).

   Currently, in RingCX workflow nodes (such as Get Voice Input or DTMF Collection), the # (pound/hash) key is hardcoded or designated by default as the Terminating Key (Termination Digit).

   Because the system intercepts # as a control signal to end input collection:

   It is automatically stripped from the collected string or ignored as a valid data character.

   Workflow designers cannot map # as a standalone interactive choice (e.g., "Press # to repeat options" or "Press # to return to the main menu").

   The input grammar masks strictly expect numeric digits (0–9), treating # strictly as a trigger to halt evaluation… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. call offers for the longest wait time

    RCX system prioritizes agents based on their overall Available Status time for the day, rather than their current Highest Availability:

    -agents who have recently returned from an offline state (such as breaks or lunch) receive calls before those who have been continuously available.

    -to better accommodate the varying preferences of our clients, we kindly request the addition of an option to enable or disable this feature. This adjustment would allow clients to configure their queues according to their specific needs and ensure a more equitable distribution of calls.

    We understand that this behavior aligns with the current design of RCX, where an agent's overall available time is accumulated rather than resetting with each offline period. However, this has led to some challenges for our users, who have noted that agents who have been available continuously are not receiving calls as expected.

    RCX system prioritizes agents based on their overall Available Status time for the day, rather than their current Highest Availability:

    -agents who have recently returned from an offline state (such as breaks or lunch) receive calls before those who have been continuously available.

    -to better accommodate the varying preferences of our clients, we kindly request the addition of an option to enable or disable this feature. This adjustment would allow clients to configure their queues according to their specific needs and ensure a more equitable distribution of calls.

    We understand that this behavior aligns with the current design of RCX,… more

    233 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Under Review  ·  13 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Ability to control playback speed for variable audio that is captured in a workflow

    Need the ability to control playback speed for variable input audio that is captured in a workflow, e.g. credit card number. We want to make the playback slower so that the caller can clearly understand the number.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  1 comment  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. RingCX Digital Queue Agent Priority setting

    Currently, RingCX supports agent priority ranking for voice skills, allowing administrators to route interactions to the most qualified agent first, with automatic fallback to other available agents. This same capability does not exist for digital skills.

    We are requesting the ability to assign priority rankings to agents within digital skills, enabling digital interactions to route to the highest-ranked available agent before cascading to others. This would support proficiency-based routing, improve efficiency, and provide consistency across voice and digital channel configuration.

    8 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Implemented  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Route Calls to the Agent With the Longest Time in AVAILABLE State

    Issue Summary:
    Calls are not being routed to the agent with the longest available time. Based on the RingCX Real-time Analytics report, calls are not consistently directed to the agent who has been available the longest.

    Current Behavior:
    RingCX routes calls without correctly prioritizing the agent with the longest AVAILABLE duration. Analytics (“Agent State Change Raw” report) confirmed that when a call arrives, the agent with the longest AVAILABLE state time is not always selected.

    Expected Behavior:
    RingCX should route calls to the agent who has been in the AVAILABLE state the longest.

    Troubleshooting Performed:

    Reviewed “Agent State Change Raw” in RingCX Analytics.

    Filtered the timeframe when agents were AVAILABLE at the moment of call arrival.

    Verified that calls were not routed to the agent with the longest AVAILABLE duration.

    Client Need / Requested Enhancement:
    The client requires that idle time be reset whenever an agent switches from WORKING / AWAY / BREAK / LUNCH back to AVAILABLE. This ensures accurate calculation of “longest available time” and correct routing behavior.

    Requested Action:
    Please implement a system update so that idle state automatically resets each time an agent re-enters AVAILABLE, ensuring proper longest-idle routing.

    Refer to:
    SF Case ticket: https://rc.lightning.force.com/lightning/r/Case/500TU00000lFlUzYAK/view?sv=%2Flightning%2Fo%2FCase%2Flist%3FfilterName%3D__Recent
    jira Ticket: https://jira.ringcentral.com/browse/EVSE-4563

    Issue Summary:
    Calls are not being routed to the agent with the longest available time. Based on the RingCX Real-time Analytics report, calls are not consistently directed to the agent who has been available the longest.

    Current Behavior:
    RingCX routes calls without correctly prioritizing the agent with the longest AVAILABLE duration. Analytics (“Agent State Change Raw” report) confirmed that when a call arrives, the agent with the longest AVAILABLE state time is not always selected.

    Expected Behavior:
    RingCX should route calls to the agent who has been in the AVAILABLE state the longest.

    Troubleshooting Performed:

    Reviewed “Agent State Change Raw”… more

    11 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  2 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Option to Route Unanswered External Phone Connections to Next Available Agent

    Option to Route Unanswered External Phone Connections to Next Available Agent

    When a RingCX agent uses an external phone number for their voice connection, the system currently treats the handoff like a call forward. If the agent does not answer, the call falls to the external phone's ring settings, and RingCX marks it as answered. We need a configuration option for RingCX to pull the call back to the queue if it is not physically answered by the agent, allowing it to route to the next available agent rather than ending up in a personal external mailbox.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Add Agent Capacity Profiles to manage concurrent async and real-time workloads

    Description:
    In the legacy Engage Digital platform, there was a valuable capability called Agent Capacity Profiles, allowing administrators to define how many asynchronous conversations (e.g. email, Apple Business Chat, WhatsApp, social messaging) an agent could handle simultaneously, while also reserving capacity for real-time channels such as webchat or voice.

    RingCX currently lacks an equivalent mechanism, making it difficult to manage agent workload across mixed interaction types.

    Pain Point:
    Without agent capacity control:

    Agents supporting both async and real-time channels can easily be over-allocated, leading to missed SLA targets or delayed responses.

    Supervisors cannot reserve a portion of agent availability for live channels while still allowing them to contribute to async workloads.

    It reduces flexibility and efficiency for operations that handle multiple channel types.

    Example Scenario:
    A managed service provider supports several businesses using RingCX. Each business uses Apple Business Chat for async messaging and LiveChat for real-time web interactions. Ideally, the same set of agents should contribute to both, but with clear limits — for example, each agent could manage 3 async conversations while keeping 50% of their capacity free for immediate live chat assignment. This is not currently possible without manual monitoring or third-party workarounds.

    Proposed Solution:
    Introduce an Agent Capacity Profile feature in RingCX similar to Engage Digital, enabling:

    Definition of concurrent conversation limits by interaction type (async and real-time).

    Ability to assign different profiles to agents, queues, or roles.

    Dynamic capacity management so agents aren’t overloaded.

    Benefits:

    Optimizes agent utilization while maintaining responsiveness on real-time channels.

    Improves SLA adherence across all communication types.

    Allows businesses to better manage diverse digital workloads without custom routing hacks.

    Aligns RingCX with proven features from Engage Digital, supporting a smoother migration path for customers transitioning between platforms.

    Description:
    In the legacy Engage Digital platform, there was a valuable capability called Agent Capacity Profiles, allowing administrators to define how many asynchronous conversations (e.g. email, Apple Business Chat, WhatsApp, social messaging) an agent could handle simultaneously, while also reserving capacity for real-time channels such as webchat or voice.

    RingCX currently lacks an equivalent mechanism, making it difficult to manage agent workload across mixed interaction types.

    Pain Point:
    Without agent capacity control:

    Agents supporting both async and real-time channels can easily be over-allocated, leading to missed SLA targets or delayed responses.

    Supervisors cannot reserve a portion of agent availability for… more

    7 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Under Review  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Feature Enhancement Request: Customer-Controlled Azure Text-to-Speech (TTS) Voice Selection via SSML in RingCX Workflows

    Feature Enhancement Request: Customer-Controlled Azure Text-to-Speech (TTS) Voice Selection via SSML in RingCX Workflows

    Title:
    Enable SSML Support and Customer-Controlled Azure Text-to-Speech Voice Selection for IVR Workflows

    Product:
    RingCX Workflow / IVR Text-to-Speech (Azure TTS)

    Business Justification:
    Following the migration from Poly TTS to Azure Text-to-Speech, customers have lost the ability to control which voice is used for IVR prompts. The platform currently assigns a default Azure voice with no option for customers to select a preferred voice or configure speech characteristics.

    This has resulted in:

    • Unexpected voice changes without prior customer notification.
    • Customer dissatisfaction due to inconsistent IVR branding and user experience.
    • Reduced flexibility for multilingual deployments and accessibility requirements.
    • Lack of documentation explaining the change, supported voices, and current platform limitations.

    Several enterprise customers have requested the ability to choose Azure voices directly, particularly through Speech Synthesis Markup Language (SSML), allowing customization of voice, language, speaking style, pronunciation, and other speech attributes.

    Current Limitation
    • Workflow Text-to-Speech uses a fixed Azure voice.
    • Customers cannot specify:

    Azure voice name
    Language or locale
    Neural voice
    Speaking style
    Prosody (rate, pitch, volume)
    • No SSML input is supported.
    • No fallback or notification mechanism exists when the Azure TTS backend experiences failures.
    • Documentation does not clearly describe supported voices or service limitations.

    Requested Enhancement

    • Implement SSML support within the Workflow Text-to-Speech function to allow customers to fully leverage Azure Speech capabilities while maintaining compatibility with the existing Azure backend.

    The enhancement should allow customers to:

    1. Enter SSML directly within the TTS node.
    2. Select supported Azure voices.
    3. Configure: • Voice • Language • Speaking style • Rate • Pitch • Volume • Pronunciation
    4. Support multilingual voice selection where available.
    5. Validate SSML before execution.
    6. Maintain backward compatibility for customers who continue using plain text.

    Additional Requested Improvements

    1. Supported Voice Documentation

    Provide documentation that includes:
    • List of supported Azure voices
    • Supported locales
    • Neural voice availability
    • SSML examples
    • Feature limitations
    • Usage guidelines
    2. Advanced Voice Clarification

    Clarify whether premium Azure/OpenAI voices (for example, Nova Multilingual Neural HD) will be supported and whether their usage incurs additional licensing or operational costs.

    1. Backend Monitoring and Failure Handling

    Improve resiliency of the TTS service by providing:

    • Detection of Azure TTS service failures.
    • Workflow error handling when synthesis fails.
    • Optional fallback logic.
    • Monitoring and alerting for backend outages.
    • Customer-facing notifications for service-impacting events.

    1. Customer Change Communication

    Establish a standardized process for notifying customers whenever backend speech engines or default voices change to avoid unexpected IVR behavior and preserve customer experience.

    Expected Benefits
    • Restores customer control over IVR voice experience.
    • Enables richer, more natural speech using Azure SSML.
    • Improves multilingual support.
    • Reduces customer complaints following backend changes.
    • Improves documentation and product transparency.
    • Enhances reliability through better monitoring and failure handling.
    Aligns RingCX with Azure Speech capabilities and customer expectations.
    Priority

    High

    This enhancement addresses a customer-facing functionality gap introduced during the migration from Poly TTS to Azure TTS and impacts IVR branding, accessibility, multilingual deployments, and overall customer experience.

    Customer Impact
    • Customers currently cannot customize Azure voices.
    • Existing IVRs may sound different after backend changes without customer awareness.
    • Organizations relying on branded voice experiences cannot maintain consistency.
    • Lack of failure visibility can result in silent IVR issues during Azure TTS outages.

    Proposed Next Steps
    • Design and implement SSML support within the Workflow TTS node.
    • Confirm the list of Azure/OpenAI voices that will be supported.
    • Determine any licensing or pricing implications for premium voices.
    • Publish comprehensive product documentation.
    • Implement monitoring, fallback handling, and customer notification mechanisms.
    • Communicate the implementation timeline to affected customers.

    This enhancement was discussed jointly with Engineering and Support, with agreement to pursue SSML support as the long-term solution for restoring customer control over Azure Text-to-Speech voice selection.

    Feature Enhancement Request: Customer-Controlled Azure Text-to-Speech (TTS) Voice Selection via SSML in RingCX Workflows

    Title:
    Enable SSML Support and Customer-Controlled Azure Text-to-Speech Voice Selection for IVR Workflows

    Product:
    RingCX Workflow / IVR Text-to-Speech (Azure TTS)

    Business Justification:
    Following the migration from Poly TTS to Azure Text-to-Speech, customers have lost the ability to control which voice is used for IVR prompts. The platform currently assigns a default Azure voice with no option for customers to select a preferred voice or configure speech characteristics.

    This has resulted in:

    • Unexpected voice changes without prior customer notification.
    • Customer dissatisfaction due to inconsistent… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Include Audio File Attachments on RingCX Voicemail Notifications

    Instead of the weblinks attached to access voicemail messages from RingCX, we'd like to attach the exact audio file to the email notification.

    19 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  6 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. RingCX Feature Request: Native Integration for RingEX Call Queue Transfers

    When an agent is using the RingCX application, they have the ability to transfer calls to RingEX users and see their extensions in the corporate directory. However, there is no native integration that allows RingCX agents to transfer calls directly to RingEX call queues. The customer is currently using a workaround where they manually upload the DIDs of the RingEX call queues into the RingCX phone book, which allows for transfers as if it were an external contact. This is a time-consuming and inefficient process that requires manual maintenance whenever a call queue is changed or added. The customer would like a feature that automatically integrates RingEX call queues into the RingCX directory, providing a seamless and automated way to transfer calls. This is a feature request, not a Salesforce adapter issue.

    When an agent is using the RingCX application, they have the ability to transfer calls to RingEX users and see their extensions in the corporate directory. However, there is no native integration that allows RingCX agents to transfer calls directly to RingEX call queues. The customer is currently using a workaround where they manually upload the DIDs of the RingEX call queues into the RingCX phone book, which allows for transfers as if it were an external contact. This is a time-consuming and inefficient process that requires manual maintenance whenever a call queue is changed or added. The customer would… more

    20 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Enable Automated Disposition Email Generation for Manual Outbound Calls

    RingCX currently supports automated email generation for inbound calls based on the disposition selected by the agent, through custom workflow. This feature has already been designed, presented, demo’d, and validated for inbound workflows.

    However, during UAT, customers requested that this same functionality be extended to manual outbound calls, which is not currently supported.

    Current Limitation:
    Automated disposition-triggered emails only work for inbound calls
    Manual outbound calls do not generate emails, even when dispositions are applied
    Agents must perform follow-up communications manually, leading to inconsistent workflows between inbound and outbound calls

    Requested Enhancement
    Enable automated email generation for manual outbound calls, using the same logic that exists for inbound calls.
    The system should automatically generate an email with the following fields:

    Subject: Disposition name selected by the agent
    Recipient: Email address pulled from the client database
    Email Body:

    First Name
    Last Name
    Caller’s phone number
    AI-generated call summary
    Any additional data stored in the database
    Feedback (if available)

    RingCX currently supports automated email generation for inbound calls based on the disposition selected by the agent, through custom workflow. This feature has already been designed, presented, demo’d, and validated for inbound workflows.

    However, during UAT, customers requested that this same functionality be extended to manual outbound calls, which is not currently supported.

    Current Limitation:
    Automated disposition-triggered emails only work for inbound calls
    Manual outbound calls do not generate emails, even when dispositions are applied
    Agents must perform follow-up communications manually, leading to inconsistent workflows between inbound and outbound calls

    Requested Enhancement
    Enable automated email generation for manual outbound calls,… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  3 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Callback Flow Improvement

    There should be a way in RingCX to enhance the callback experience by allowing callback requests to be honored immediately after the caller’s initial input, without requiring a second confirmation—even if the caller disconnects early.

    Current Behavior
    1) Callers press “1” to request a callback.
    2) A second confirmation (“press 1 again”) is required before the callback is officially queued.
    3) If the caller disconnects before completing the second confirmation or before system disconnect, the interaction is marked as “Inbound ACD Callback Incomplete.”
    4) No callback is generated, even if the caller already indicated intent.

    Problem Statement
    • The two-step confirmation is not intuitive for callers.
    • Callers often assume their request is complete after the first input and hang up.
    • This leads to failed callback requests and a poor customer experience.

    Enhancements
    1) Introduce logic and/or configuration that:
    • Queues the callback immediately after the first “press 1” input.
    • Does not require a second confirmation if the caller disconnects after the first input.
    • Treats the first confirmation as sufficient intent to proceed with the callback.

    2) Introduce improved reporting for callback flows where the caller disconnects before queue confirmation. Specifically:
    • Add a new disposition or category (e.g., “Callback Requested – Caller Disconnected Before Queue”)
    • Provide a custom report option to identify these interactions separately from true incomplete callbacks

    There should be a way in RingCX to enhance the callback experience by allowing callback requests to be honored immediately after the caller’s initial input, without requiring a second confirmation—even if the caller disconnects early.

    Current Behavior
    1) Callers press “1” to request a callback.
    2) A second confirmation (“press 1 again”) is required before the callback is officially queued.
    3) If the caller disconnects before completing the second confirmation or before system disconnect, the interaction is marked as “Inbound ACD Callback Incomplete.”
    4) No callback is generated, even if the caller already indicated intent.

    Problem Statement
    • The two-step… more

    4 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  Interaction routing, workflow & queuing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating