1589 results found

1. AI Audio Redaction Service

   AI Audio Redaction Service
   1. The Problem Statement
   Currently, RingCentral Session Border Controllers (SBCs) capture raw audio and attach it to RingEX (REX) or RingCX (RCX). When these recordings move into RingSense/ACE, the system successfully redacts PII and PCI from the text transcripts, but the raw audio files remain untouched.
   The Risk: Unredacted audio containing sensitive PII/PCI resides in REX/RCX for 30–90 days, and in ACE for up to 12 months.
   The Liability: This exposes clients to severe compliance violations (PCI-DSS, HIPAA, GDPR), a risk compounded by the common client misconception that audio is redacted alongside transcripts.
   2. The Proposed Solution
   Develop and integrate a native AI Audio Redaction Service. This service will act as a mandatory processing gateway for recordings before they are committed to long-term or short-term storage.
   End-User Control: Administrators will have the ability to select from standard compliance templates (e.g., PCI, HIPAA) or program specific PII/PCI fields to be targeted for redaction.
   Mechanism: The AI will identify the selected spoken elements and overwrite those specific audio segments with white noise.
   Outcome: A sanitized audio file that protects clients across all downstream platforms.
   3. Proposed Architectural Workflow & SLA
   To balance compliance with operational efficiency, the workflow introduces a brief, defined processing window:
   SBCs / Recording Service: Audio is captured.
   AI Audio Redaction Service (New): Audio is routed here first.
   Processing SLA: The redaction service processes the file and applies white noise to targeted elements. The sanitized audio will be available within 3–5 minutes post-call.
   Storage & Analytics: The sanitized file is then pushed to REX, RCX, or AIR Pro.
   Long-Term Archive: The file moves to ACE for 12 months of compliant storage.
   4. Legal Framework & Client Acceptance
   Because this process fundamentally alters the original recording, legal and QA safeguards must be built into the onboarding flow:
   Destructive Edit Acknowledgment: Clients must explicitly accept that the redaction is a destructive process—the original raw audio containing the sensitive data is overwritten with white noise and cannot be recovered.
   AI Accuracy Disclaimer: The Terms of Service will require clients to acknowledge that while AI speech-to-text is highly accurate, it is not 100% perfect. Variables like poor audio quality, heavy accents, or crosstalk can impact detection, and RingCentral does not assume liability for occasional false negatives (missed redactions) or false positives (over-redacted segments).

   AI Audio Redaction Service
   1. The Problem Statement
   Currently, RingCentral Session Border Controllers (SBCs) capture raw audio and attach it to RingEX (REX) or RingCX (RCX). When these recordings move into RingSense/ACE, the system successfully redacts PII and PCI from the text transcripts, but the raw audio files remain untouched.
   The Risk: Unredacted audio containing sensitive PII/PCI resides in REX/RCX for 30–90 days, and in ACE for up to 12 months.
   The Liability: This exposes clients to severe compliance violations (PCI-DSS, HIPAA, GDPR), a risk compounded by the common client misconception that audio is redacted alongside transcripts.
   2. The Proposed… 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  ·  0 comments  ·  Call & screen recording  ·  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. Show Indicator for Inbound Queue Callback on Agent Side

   Description:
   Currently, when a call comes in as a callback from a queue, the RingCX agent interface treats it as a normal inbound call. There is no visual indication or label to inform the agent that this call was requested via a queue callback.

   This makes it difficult for agents to differentiate between standard inbound calls and callbacks, which can impact handling priority and customer experience.

   Requested Feature / Enhancement:

   • Add an option (script or toggle) in RingCX Admin / Studio / Agent Interface to clearly indicate on the agent side when a call is an inbound queue callback.

   • Suggested display options:

     • A label in the incoming call popup (“Callback”)
     • Optional notes or metadata showing original callback request time
     • Distinct ringtone or visual marker (optional)

   Expected Benefit:

   • Agents can immediately identify that a call is a callback.
   • Improves handling and prioritization of callback calls.
   • Reduces confusion between normal inbound calls and queued callbacks.

   Current Behavior:

   • Queue callbacks are routed to agents but appear as standard inbound calls.
   • No distinguishing indicator in the agent interface.

   Impact:

   • This affects all RingCX customers using queue callbacks with agents relying on the agent desktop or softphone interface.
   • Callers who requested a callback may not be treated differently, affecting service experience.

   Description:
   Currently, when a call comes in as a callback from a queue, the RingCX agent interface treats it as a normal inbound call. There is no visual indication or label to inform the agent that this call was requested via a queue callback.

   This makes it difficult for agents to differentiate between standard inbound calls and callbacks, which can impact handling priority and customer experience.

   Requested Feature / Enhancement:

   • Add an option (script or toggle) in RingCX Admin / Studio / Agent Interface to clearly indicate on the agent side when a call is an inbound queue… more
   6 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  ·  Call & screen recording  ·  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. Disable agent RingCX login

   Disable agent RingCX login. This option was available before but was removed.

   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  ·  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

4. Feature Request: Improve Error Handling for RCX Agent Profiles with Deleted/Unreachable REX Users

   eature Request: Improve Error Handling for RCX Agent Profiles with Deleted/Unreachable REX Users

   Product: RingCX (RCX)
   Category: Feature Enhancement / Usability
   Suggested Priority: Medium

   Issue / Customer Impact:
   When accessing an RCX Agent Profile, the platform may display the generic error message:

   “An internal error has occurred. Please try again.”

   In our investigation, we identified that the RCX Agent Profile was synchronized with a RingEX (REX) user whose extension had already been deleted. However, the error message does not indicate that the issue is related to the associated RingEX user or extension.

   This resulted in additional troubleshooting and investigation time before we were able to identify the actual cause.

   Requested Enhancement:
   Improve the error handling and messaging when an RCX Agent Profile is associated with a RingEX user whose extension is no longer available or whose user account has been deleted.

   Instead of displaying a generic internal error, the platform should provide a clear and actionable message, for example:

   “Unable to load this agent profile because the associated RingEX user or extension is no longer available. Please verify that the RingEX user is still active or connect this agent profile to another available user.”

   Ideally, the system should also provide an option to reconnect the existing agent profile to a new/active RingEX user, rather than requiring the administrator to delete the agent profile and create a new one.

   Expected Benefits:

   Provides administrators with actionable information immediately.
   Reduces unnecessary troubleshooting and escalation time.
   Avoids misleading “internal error” messages when the underlying cause is a configuration/synchronization issue.
   Allows administrators to resolve the issue without recreating the RCX Agent Profile.
   Improves the overall administration experience between RingCX and RingEX.

   Additional Recommendation:
   A clear visual indicator, such as a red error banner within the Agent Profile, could identify that the associated RingEX user/extension is no longer reachable and provide a direct “Reconnect User” or “Change Associated User” action.

   eature Request: Improve Error Handling for RCX Agent Profiles with Deleted/Unreachable REX Users

   Product: RingCX (RCX)
   Category: Feature Enhancement / Usability
   Suggested Priority: Medium

   Issue / Customer Impact:
   When accessing an RCX Agent Profile, the platform may display the generic error message:

   “An internal error has occurred. Please try again.”

   In our investigation, we identified that the RCX Agent Profile was synchronized with a RingEX (REX) user whose extension had already been deleted. However, the error message does not indicate that the issue is related to the associated RingEX user or extension.

   This resulted in additional troubleshooting and investigation time… 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  ·  1 comment  ·  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

5. auto dialer with automated system

   I would like to have a feature that when i dialed the customer's number using RingCentral App
   there will be an Automated system will tell my customer that im on my way.

   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  ·  0 comments  ·  Automated outbound dialing, campaign & lead mngmt  ·  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. Enhanced Call Termination Attribution with Contextualized Termination Reason

   Summary:
   Improve call reporting by clearly separating true disconnect source attribution from termination reason (routing/system event context), ensuring customers can accurately interpret why a call ended and what system event preceded it.

   Problem Statement:
   The current “Termination” field in the Inbound Call Detail Report can reflect an internal routing or system event rather than the actual disconnect source. This creates confusion because the same field is often interpreted as the definitive reason the call ended.

   In many cases, customers cannot distinguish between:
   - the actual disconnect event (who ended the call), and
   - the system/routing event that occurred immediately prior to termination.
   - Additionally, backend session logs contain more precise information, but this is not exposed in customer-facing reporting.

   Proposed Enhancement:
   1. Split “Termination” into Two Distinct Fields

   A. Disconnect Source (New Primary Field – Required)
   - A definitive field that identifies who or what actually ended the call:
   Caller Disconnected
   Agent Disconnected
   System Disconnected
   Network/Media Failure
   Timeout Expiry
   Transfer Failure (final hop failure)

   B. Termination Reason (Contextual Field – Existing Concept Refined)
   Retain and clarify the current “Termination” field, but redefine it as:
   The last known routing or system event preceding call termination.

   Examples:
   Queue Transfer
   Agent-to-Queue Requeue
   Skill-Based Routing Action
   Internal System Redirect
   Conference Bridge Attempt

   1. Add Relationship Clarity Between Fields

   Introduce reporting UI/labels that make the relationship explicit:

   “Termination Reason (Pre-Disconnect Event)”

   This prevents misinterpretation in reporting dashboards and exports.

   1. Enhanced Call Timeline Visibility

   Where possible, provide a structured event timeline per interaction:

   Call Entered Queue
   Routed to Agent
   Internal Requeue / Transfer Attempt
   Agent Connected
   Disconnect Event (Source)
   Termination Reason (Last System Action)

   This helps correlate both fields in sequence.

   Customer Impact

   This enhancement would:

   Eliminate confusion between routing events and disconnect ownership
   Reduce misinterpretation of “Termination” as a failure or disconnect cause
   Improve accuracy in QA, auditing, and escalation analysis
   Reduce dependency on backend Support logs
   Enable more reliable root cause analysis for short-duration calls

   Summary:
   Improve call reporting by clearly separating true disconnect source attribution from termination reason (routing/system event context), ensuring customers can accurately interpret why a call ended and what system event preceded it.

   Problem Statement:
   The current “Termination” field in the Inbound Call Detail Report can reflect an internal routing or system event rather than the actual disconnect source. This creates confusion because the same field is often interpreted as the definitive reason the call ended.

   In many cases, customers cannot distinguish between:
   - the actual disconnect event (who ended the call), and
   - the system/routing event that occurred immediately prior… more

   5 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  ·  Realtime & historical analytics  ·  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. Include Customer DTMF Inputs in RingCX Queue Reporting

   Business Need / Context:
   We currently have reporting visibility for DTMF (keypad) inputs while a caller is navigating the initial IVR/Workflow. However, once a call enters a queue, any DTMF inputs made by the customer (e.g., pressing a digit to request a callback, change priority, or trigger an automated action) are not captured in any standard, pullable reports.

   Currently, our team can only verify queue DTMF inputs by running a manual backend trace on individual calls using internal tools. This is highly inefficient, delays troubleshooting, and limits our ability to track customer behavior and queue performance at scale.

   User Persona Impacted:
   Contact Center Managers, Quality Assurance Teams, Operations Analysts, and Support Engineers.

   Proposed Solution:
   Expand our standard interaction and queue reporting capabilities to log and display DTMF digits pressed by customers after the call has exited the IVR and entered a queue. Ideally, this data should be available via:

   Interaction Detail Records: A visible field in the call history showing digits pressed during the queue state.

   Historical Queue Reports: An aggregate report showing how many callers pressed specific digits while waiting in queue (e.g., to track how many users are opting for callbacks).

   Value / Benefits:

   Time Savings: Eliminates the need for technical teams to run manual backend traces to verify customer inputs.

   Better Insights: Allows business operations to analyze queue exit behaviors and improve the customer experience.

   Autonomous Troubleshooting: Empowers supervisors and standard users to audit call flows independently without escalating to engineering.

   Business Need / Context:
   We currently have reporting visibility for DTMF (keypad) inputs while a caller is navigating the initial IVR/Workflow. However, once a call enters a queue, any DTMF inputs made by the customer (e.g., pressing a digit to request a callback, change priority, or trigger an automated action) are not captured in any standard, pullable reports.

   Currently, our team can only verify queue DTMF inputs by running a manual backend trace on individual calls using internal tools. This is highly inefficient, delays troubleshooting, and limits our ability to track customer behavior and queue performance at scale.

   User Persona… 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  ·  0 comments  ·  Realtime & historical analytics  ·  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. Recording from RingCX should be assigned to the agent who answered the call

   For call recordings in RingCX, if the initial segment of the call is RNA or deflected and then routed to another agent, the recording name should be on the agent who answered the call, not on the agent who gets the ring first. It would be ideal if there were additional tokens to choose from under the destination directory.

   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  ·  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

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

10. Support Combining Agent State and Call Metrics in a Single Custom Analytics Report

    Enable Agent State and Call/Interaction Metrics to Be Combined in a Single RingCX Custom Analytics Report

    Product Area

    RingCX Analytics / Custom Analytics

    Request Type

    Feature Enhancement

    Customer Request

    Customers would like the ability to create a single custom analytics report containing both Agent State metrics and Call/Interaction metrics.

    Currently, when creating a custom analytics report, the available metrics/KPIs are dependent on the underlying data source. Agent State data and Call/Interaction data are derived from different datasets, preventing users from combining metrics from both sources within the same custom report.

    Current Limitation

    When creating a custom analytics report:

    Selecting Agent State-related metrics makes Call/Interaction KPIs unavailable.
    Selecting Call/Interaction KPIs makes Agent State metrics unavailable.
    As a result, customers must create separate reports and manually correlate the information.

    This prevents customers from having a consolidated view of agent activity and performance.

    Customer Use Case

    The customer wants to create one report that provides a complete view of agent productivity by combining call performance metrics with the amount of time agents spend in different states.

    Requested metrics include:

    Call/Interaction Metrics:

    Agent First Name
    Abandoned within SLA Calls (API)
    Answered Calls (API)
    Handle Time
    Avg Inbound Handle Time
    Total Phone Available
    Long Call
    Hold Time
    Available State Time
    Engaged State Time

    Agent State Metrics:

    State
    Bio Break
    Call Back / CSM
    LUNCH
    Manager / Development
    ON-BREAK
    Supervisor
    Tickets / Chats
    WORKING
    Agent Voice State Time

    The desired report would allow these metrics to be viewed together by agent and/or selected reporting period.

    Business Impact

    The current limitation requires customers to generate and reconcile multiple reports to obtain a complete picture of agent performance.

    This creates several challenges:

    Additional manual reporting effort.
    Increased complexity when comparing call performance against agent availability and state behavior.
    Difficulty identifying relationships between productivity and time spent in specific agent states.
    Increased possibility of discrepancies when manually combining data from separate reports.
    Reduced usefulness of Custom Analytics for workforce and operational reporting.

    A unified report would allow customers to more easily analyze:

    Agent productivity versus available time.
    Handle time versus agent state utilization.
    Time spent in non-productive states versus call performance.
    Agent availability versus answered/contacted calls.
    Overall agent utilization and performance.

    Enable Agent State and Call/Interaction Metrics to Be Combined in a Single RingCX Custom Analytics Report

    Product Area

    RingCX Analytics / Custom Analytics

    Request Type

    Feature Enhancement

    Customer Request

    Customers would like the ability to create a single custom analytics report containing both Agent State metrics and Call/Interaction metrics.

    Currently, when creating a custom analytics report, the available metrics/KPIs are dependent on the underlying data source. Agent State data and Call/Interaction data are derived from different datasets, preventing users from combining metrics from both sources within the same custom report.

    Current Limitation

    When creating a custom analytics report:

    Selecting Agent… 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  ·  Realtime & historical analytics  ·  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. 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

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

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

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

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

16. Real-Time Dashboard rules

    Currently, Real-Time Dashboard rules does not include any of the callback metrics on its "If" drop down.

    If the client wants to create a rule that highlights a certain queue if they Missed a callback or if there is a queued Callback, they can't due to callbacks not being part of the "If" selection

    Use Case :
    • Allow admins to create a Real-time Dashboard that would give them an option to visually highlight all the queued/missed/presented/answered callbacks for their voice queues

    6 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  ·  Realtime & historical analytics  ·  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. 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

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

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

20. Feature Request: Time Zone Configuration for RingCX

    Current Behavior
    As confirmed via RingCX T3, eW Analytics reporting derives its time zone exclusively from the account-level setting. There is currently no option to override or adjust the time zone on demand.

    Problem / Limitation
    This model does not support organizations operating across multiple geographic regions. When queues span different time zones, both real-time call handling and historical reporting become misaligned with local operating hours, SLA measurements, and staffing analysis.

    Requested Enhancement
    Introduce the ability to define time zones at a more granular level, specifically:

    Per Queue

    Call Handling Logic

    Historical Reporting (eW Analytics)

    Each queue should be able to operate and report in its assigned local time zone, independent of the account-level default.

    Business Impact / Use Case

    Multi-region contact centers with centralized RingCX accounts

    Accurate SLA tracking and performance reporting by region

    Improved workforce management, scheduling, and compliance

    Reduced need for manual time conversions and post-report adjustments

    Expected Outcome

    Queues operate according to their configured local time zone

    Historical and real-time analytics reflect correct regional timestamps

    Account-level time zone remains as a default, not a hard constraint

    Priority
    Medium–High for enterprises and globally distributed contact centers.

    Current Behavior
    As confirmed via RingCX T3, eW Analytics reporting derives its time zone exclusively from the account-level setting. There is currently no option to override or adjust the time zone on demand.

    Problem / Limitation
    This model does not support organizations operating across multiple geographic regions. When queues span different time zones, both real-time call handling and historical reporting become misaligned with local operating hours, SLA measurements, and staffing analysis.

    Requested Enhancement
    Introduce the ability to define time zones at a more granular level, specifically:

    Per Queue

    Call Handling Logic

    Historical Reporting (eW Analytics)

    Each queue should be able… more

    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

    New  ·  1 comment  ·  Realtime & historical analytics  ·  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