1664 results found

1. Feature Enhancement Request: Bulk Download and Bulk Upload for Audio Files in RingCX

   Feature Request Details
   Customer: Brie / RingCentral Contact Center Customer

   Feature Area: Audio Library / Call Recordings & Media Management

   Requested Features:

   Bulk Download: Ability to download multiple call audio recordings in bulk from the Audio Library or reporting views, rather than having to download files individually.

   Bulk Upload: Ability to upload multiple audio files simultaneously, as the current system restriction only permits uploading files one at a time.

   Business Value & Use Case
   Efficiency: Customers managing large volumes of audio files or announcements spend an excessive amount of time performing repetitive, manual single-file downloads and uploads.

   Workflow Optimization: A bulk management option streamlines compliance archiving, auditing processes, and large-scale IVR prompt updates.

   Feature Request Details
   Customer: Brie / RingCentral Contact Center Customer

   Feature Area: Audio Library / Call Recordings & Media Management

   Requested Features:

   Bulk Download: Ability to download multiple call audio recordings in bulk from the Audio Library or reporting views, rather than having to download files individually.

   Bulk Upload: Ability to upload multiple audio files simultaneously, as the current system restriction only permits uploading files one at a time.

   Business Value & Use Case
   Efficiency: Customers managing large volumes of audio files or announcements spend an excessive amount of time performing repetitive, manual single-file downloads and uploads.

   Workflow Optimization: A… 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  ·  Admin experience  ·  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. 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

3. 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

4. Notification for agents when being on a call for too long

   Configurable alert to the agent based on time in call.

   We have an guideline for our agents of approximately how long they should be on a call, would be nice if a supervisor/admin could set an alert for an agent or groups of agents. So if an agent is on a call for X minutes, they get a pop-up alert on the screen, or ideally a separate pop-up window in case they've switched focus to another system, letting them know they should consider escalating the call to a higher level.

   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  ·  Agent & supervisor experience  ·  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. Audible notification for incoming call & DTMF support

   Our agents must use "RingCentral Phone" as their device type in RingCX because RingCX does not provide an audible indicator for incoming calls, when using Integrated Phone. When they do this, they are not able to enter DTMF tones while in the RingCX UI when conferencing in a third party translator service. The DTMF tones must be entered via the RingCentral softphone app. This is incredibly confusing for our agents, as they perform all other call functions such as hold, transfer, etc in the RingCX web interface. It will be great if we can disbale the diapad in RingCX in this instance to lessen the confusion

   Our agents must use "RingCentral Phone" as their device type in RingCX because RingCX does not provide an audible indicator for incoming calls, when using Integrated Phone. When they do this, they are not able to enter DTMF tones while in the RingCX UI when conferencing in a third party translator service. The DTMF tones must be entered via the RingCentral softphone app. This is incredibly confusing for our agents, as they perform all other call functions such as hold, transfer, etc in the RingCX web interface. It will be great if we can disbale the diapad in RingCX in… 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

   Implemented  ·  3 comments  ·  Agent & supervisor experience  ·  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. Function to Disable Extensions

   We would like to implement a functionality to disable the extensions for certain Representatives from receiving external calls or direct transfers. We want to ensure the only calls received are through a skill.

   34 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  ·  Admin experience  ·  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. Fix Inverted ANI / DNIS Mapping on Outbound Reports in RingCX

   In RingCX Interaction Details reports, outbound call records invert standard telephony definitions:
   -The ANI column displays the customer/lead number called.
   -The DNIS column displays the outbound Caller ID presented by the dialer.
   -Under industry standards, ANI is the calling party (Caller ID), while DNIS is the number dialed.

   Business Impact :
   -Compliance Confusion: Auditing tools and compliance teams check the DNIS column to ensure calls are within legal daytime hours; inverted columns make fully compliant calls look like illegal curfew violations.
   -Wasted Support Time: Administrators and engineers spend weeks troubleshooting non-existent dialer bugs simply because the report mislabels the lead's number.
   -Loss of Trust: Customers lose confidence in RingCX when their own reports lead them to believe the platform is calling people outside business hours.

   Proposed Solution:
   -Flip the Columns for Outbound: Make ANI always show the Caller ID used, and DNIS always show the customer number called.

   In RingCX Interaction Details reports, outbound call records invert standard telephony definitions:
   -The ANI column displays the customer/lead number called.
   -The DNIS column displays the outbound Caller ID presented by the dialer.
   -Under industry standards, ANI is the calling party (Caller ID), while DNIS is the number dialed.

   Business Impact :
   -Compliance Confusion: Auditing tools and compliance teams check the DNIS column to ensure calls are within legal daytime hours; inverted columns make fully compliant calls look like illegal curfew violations.
   -Wasted Support Time: Administrators and engineers spend weeks troubleshooting non-existent dialer bugs simply because the report mislabels the lead's… 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  ·  Realtime & historical analytics  ·  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

9. 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

10. 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

    12 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

11. Allow Maximum Ring Timer Configurability for IVA Integration Workflow Nodes

    Allow Maximum Ring Timer Configurability for IVA Integration Workflow Nodes.

    There is currently no ability to configure or limit the amount of time the RingCX platform attempts to connect to an IVA Integration Workflow node. The "Route" node includes a "Ring Duration" setting. This same setting would be very helpful to be configured for IVA integration nodes or within the admin portal IVA integration settings.

    Use case: If an IVA integration is working as normal and has no issues, the RingCX platform will hand the contact off to the IVA integration in milliseconds. However, if there is a connectivity issue with the IVA integration, the RingCX platform will attempt to connect to the IVA integration for 25-30 seconds before the workflow moves through the failure path.

    Impact: In the event of a connectivity issue with an IVA and a contact attempts to contact us via a workflow that includes the broken IVA integration, the contact is left waiting for nearly 30 seconds before their contact takes a workflow path that allows for the contact to be serviced by the workflow's fallback / failure path. This leads to an increase in abandons.

    Testing: I verified the 25-30 second connection attempts to a broken IVA integration by creating an intentionally broken IVA integration (With an intentionally incorrect SIP URI in the IVA Integration settings) and implemented that IVA integration in a RCX workflow. On each connection attempt, I had to wait 25 - 30 seconds before my contact would move down the failure / fallback path.

    Please allow for a maximum ring timer or maximum connection attempts setting for IVA integrations in either the RingCX Workflow IVA Integration Node or in the Admin Portal IVA Integration Settings.

    Allow Maximum Ring Timer Configurability for IVA Integration Workflow Nodes.

    There is currently no ability to configure or limit the amount of time the RingCX platform attempts to connect to an IVA Integration Workflow node. The "Route" node includes a "Ring Duration" setting. This same setting would be very helpful to be configured for IVA integration nodes or within the admin portal IVA integration settings.

    Use case: If an IVA integration is working as normal and has no issues, the RingCX platform will hand the contact off to the IVA integration in milliseconds. However, if there is a connectivity issue… 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  ·  Integrations & APIs  ·  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

12. Ability to only show numbers assigned to the sub account to be used as outbound caller ID on RingCX Campaign

    currently it shows all assigned numbers for the whole account instead of showing only numbers assigned to the sub account as outbound caller ID

    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  ·  1 comment  ·  Admin experience  ·  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. Full Telephony Migration to RingCX with Physical Phone Support

    Request Summary
    The customer would like the ability to migrate their telephony operations entirely to RingCX, eliminating the current dependency on RingEX for initial call handling. At present, inbound calls are routed through RingEX first and are only transferred to RingCX when no agents are available. The customer's preferred design is for calls to be handled directly within RingCX from the outset.

    Business Need
    The customer is seeking a streamlined contact center architecture that leverages RingCX as the primary telephony platform. This would simplify call routing, reduce reliance on multiple platforms, and provide a more centralized agent experience and reporting model.

    Requested Functionality

    Support for full telephony operations within RingCX without requiring RingEX as the initial call-handling layer.
    Ability for agents to receive and manage RingCX interactions using a physical desk phone while remaining logged into RingCX as a softphone agent.
    Clarification on whether a hybrid configuration is supported where:
    RingCX remains the agent platform for call control, reporting, and routing.
    A physical desk phone serves as the endpoint for voice communications.
    Documentation and guidance outlining:
    Supported deployment models
    Configuration requirements
    Licensing prerequisites
    Dependencies between RingEX and RingCX
    Known limitations or restrictions

    Current State

    Inbound calls are initially processed by RingEX.
    Calls are only routed to RingCX under specific conditions (e.g., agent unavailability).
    The customer would like to remove this dependency and have RingCX act as the primary telephony platform.

    Desired State

    Inbound calls enter RingCX directly.
    Agents can continue using a physical desk phone for call audio while operating within the RingCX agent interface.
    The solution is fully supported and documented by RingCentral.

    Business Impact

    Simplifies the customer’s telephony architecture.
    Improves operational efficiency by consolidating telephony and contact center workflows.
    Reduces administrative overhead associated with managing separate RingEX and RingCX call flows.
    Supports the customer's planned telephony migration strategy.

    Request for Product Team Please evaluate and confirm:

    Whether full telephony migration directly to RingCX is supported.
    Whether agents can use physical desk phones as their voice endpoint while remaining active in RingCX.
    Any technical, licensing, or architectural requirements needed to support this deployment model.
    If the functionality is not currently supported, consider this a feature enhancement request for future roadmap evaluation.

    Request Summary
    The customer would like the ability to migrate their telephony operations entirely to RingCX, eliminating the current dependency on RingEX for initial call handling. At present, inbound calls are routed through RingEX first and are only transferred to RingCX when no agents are available. The customer's preferred design is for calls to be handled directly within RingCX from the outset.

    Business Need
    The customer is seeking a streamlined contact center architecture that leverages RingCX as the primary telephony platform. This would simplify call routing, reduce reliance on multiple platforms, and provide a more centralized agent experience and reporting… 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  ·  Other  ·  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

14. Provide More Granular Control Over Available Caller ID Options in RingCX

    Issue / Customer Request:
    Customers would like more control over the caller ID options displayed in the RingCX Alternate Caller ID dropdown. Currently, numbers made available through RingEX, including IVR menu numbers and call queue numbers, may continue to appear even after Caller ID restriction settings have been configured in the RingEX Admin Portal.

    Current Behavior:
    RingCX displays available RingEX caller ID options according to the current system design. The existing RingEX Caller ID restriction settings apply to number categories rather than individual numbers and may not provide the level of control customers expect within RingCX.

    Expected Behavior:
    RingCX should provide more granular control over the caller ID options available to users, allowing administrators to manage which numbers appear in the Alternate Caller ID dropdown.

    Requested Enhancement:
    Consider implementing the following capabilities:

    Ensure RingCX appropriately reflects applicable RingEX Caller ID restriction settings.

    Allow administrators to exclude specific numbers, such as IVR menu numbers and call queue numbers, from the Alternate Caller ID dropdown.

    Provide more granular configuration options for managing available outbound caller IDs.

    Business Impact:
    Without more granular control, customers may be unable to remove unwanted caller ID options from the RingCX interface, potentially creating confusion for users and limiting administrative flexibility.

    Issue / Customer Request:
    Customers would like more control over the caller ID options displayed in the RingCX Alternate Caller ID dropdown. Currently, numbers made available through RingEX, including IVR menu numbers and call queue numbers, may continue to appear even after Caller ID restriction settings have been configured in the RingEX Admin Portal.

    Current Behavior:
    RingCX displays available RingEX caller ID options according to the current system design. The existing RingEX Caller ID restriction settings apply to number categories rather than individual numbers and may not provide the level of control customers expect within RingCX.

    Expected Behavior:
    RingCX should… 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  ·  Agent & supervisor experience  ·  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. Separate Timer Configuration for the Away Base State in RingCX

    Introduce a Dedicated Timer Setting for the Away Base State

    Current Behavior:
    Currently, the Away base state does not have its own configurable timer. Instead, it follows the Break Timer configured under the account settings, which also controls the On Break state.

    As a result, when an agent uses a state with the Away base state, the timer counts down based on the configured Break Timer rather than allowing the Away state to operate independently.

    Requested Enhancement:
    Introduce a dedicated, configurable timer for the Away base state, separate from the existing Break Timer.

    This would allow administrators to configure the timer behavior for the Away base state independently without affecting the On Break state or its timer settings.

    Business Justification:
    Currently, administrators have limited flexibility in managing agent states because the Away and On Break states share the same Break Timer configuration.

    The existing workarounds are to change the base state to Working or remove the Break Timer entirely. However, changing the base state may not align with the intended workflow, while removing the Break Timer also affects the On Break state.

    A dedicated Away timer would provide greater flexibility and allow administrators to configure agent states according to their operational requirements.

    Introduce a Dedicated Timer Setting for the Away Base State

    Current Behavior:
    Currently, the Away base state does not have its own configurable timer. Instead, it follows the Break Timer configured under the account settings, which also controls the On Break state.

    As a result, when an agent uses a state with the Away base state, the timer counts down based on the configured Break Timer rather than allowing the Away state to operate independently.

    Requested Enhancement:
    Introduce a dedicated, configurable timer for the Away base state, separate from the existing Break Timer.

    This would allow administrators to configure the… 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  ·  Agent & supervisor experience  ·  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

16. 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

17. Add the Polish language (audio CALLBACK)

    Add Polish to callback audio messages to enhance the experience for Polish-speaking users by improving message comprehension and the quality of the customer journey in a multilingual context.

    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  ·  Digital experience  ·  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. AI Summaries for RingCX Plugin for Dynamics after Call Disposition

    AI Summaries for RingCX Plugin for Dynamics after Call Disposition

    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  ·  Integrations & APIs  ·  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

19. Allow Call data to populate in Agent Assist window Post Call

    Current functionality:
    Agent Assist only works while a call is connected. Agents must open it during the call, or have it already open from earlier in the call.

    If an agent opens Agent Assist for the first time after hanging up, it can’t load that call’s context. It starts without it, so the Knowledge Base, AI Checklist results and call transcript don’t appear, or the panel stays stuck loading.
    The information loads normally if the panel was opened before the call ends.
    As a result, an agent who doesn’t open Agent Assist before the call ends loses access to the AI output from that call.

    Desired functionality:
    Transcript, Knowledge Base content and AI Checklist results for a call should stay accessible in the Agent Assist tab after the call ends, including during wrap-up and disposition. This should hold even if the agent never opened the panel during the call. The AI data is already generated during the call, so opening the tab afterward should show it rather than fail to load.

    Why this is important:
    -Adoption and ROI of the AI add-ons. Customers pay extra for Agent Assist. Removing the “open it first” requirement means they get full value from it on every call, not only the calls where the panel happened to be open.
    -Agent and quality review. Agents and supervisors can review checklist compliance and transcripts after the call, which supports coaching and performance review.
    -Better wrap-up and dispositions. Agents can refer to the transcript or KB content while writing notes and choosing a disposition.

    Current functionality:
    Agent Assist only works while a call is connected. Agents must open it during the call, or have it already open from earlier in the call.

    If an agent opens Agent Assist for the first time after hanging up, it can’t load that call’s context. It starts without it, so the Knowledge Base, AI Checklist results and call transcript don’t appear, or the panel stays stuck loading.
    The information loads normally if the panel was opened before the call ends.
    As a result, an agent who doesn’t open Agent Assist before the call ends loses access to the… 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  ·  AI quality management  ·  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

20. RingCX and Slack integration

    Many of the tools in our environment work with Slack. There is a RingEX integration with Slack, but our users are requesting the ability to set status in Slack that corresponds to RingCX. If the user sets themselves as unavailable in Slack, to have that update the RingCX status to unavailable as well.

    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  ·  Integrations & APIs  ·  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