Accessibility in IT service delivery has moved from a compliance checkbox to an operational priority. Over the past three years, support organizations have expanded their channel mix beyond voice and chat, driven by stricter ADA enforcement, a remote-first workforce, and mounting pressure on CSAT scores. Within that shift, one technology has emerged with particular relevance for contact centers and help desks: Real-Time Text calling. Understanding what is RTT calling, how it works technically, and where it fits inside a modern ITSM workflow is now a practical concern for IT managers, not just a legal one. Teams that ignore it risk SLA breaches, unresolved tickets from underserved user segments, and measurable drops in first-contact resolution for accessibility-related incidents.
What Is RTT Calling? How it Works
According to Genesys, an RTT call is a real-time text communication method that lets users send text instantly during a phone call without waiting for the other party to finish typing. That single distinction separates RTT from SMS, chat, and even TTY relay services. With TTY, text is transmitted only after the user completes a message and presses send. RTT delivers every keystroke to the recipient as it happens, character by character, over the same call session.
On a technical level, RTT operates over modern voice infrastructure including VoLTE (Voice over LTE) and VoIP networks. Both Android devices and iPhones support RTT natively through carrier settings, meaning no third-party application is required for end users. When an RTT-enabled call is placed, the device opens a simultaneous data stream alongside the audio channel. Agents see text appearing in real time on their interface while still maintaining the option to speak. The audio and text channels coexist in the same session.
This architecture matters for IT teams because it integrates with VoIP infrastructure already deployed in most enterprise environments. Teams managing CMDB entries for telephony assets should note that RTT support is a configuration-level attribute, not a separate system. Enabling it does not require a separate ticket queue or a new escalation path. It extends the existing voice channel rather than creating a parallel one.
Five9 notes that RTT enables users to type and read text during a phone conversation, in real time, without having to click send. For a support agent handling an incident with a deaf or hard-of-hearing user, that immediacy eliminates the back-and-forth delay that inflates MTTR on accessibility-related tickets.
RTT Calling in the Context of IT Service Accessibility Compliance
Section 255 of the Telecommunications Act and Title II of the ADA require that telecommunications services be accessible to individuals with disabilities. RTT calling satisfies the FCC’s mandate for advanced communications services to support real-time text, replacing the older TTY standard as the baseline for accessible telephony. For IT managers at US companies, this has a direct implication: if the organization operates a contact center or internal help desk that handles calls from employees or customers, RTT readiness is now part of the compliance surface.
Consider an IT support team of 12 managing 500 weekly tickets across three priority tiers. If even a small subset of those tickets originates from employees with hearing or speech disabilities, and the team’s telephony stack does not support RTT, those tickets are either misrouted, escalated unnecessarily, or abandoned. Each abandoned ticket represents a failed FCR event and a potential compliance exposure. Enabling RTT on the voice infrastructure closes that gap without adding headcount or restructuring the escalation path.
Beyond legal compliance, accessibility directly affects customer experience outcomes. Teams that measure CSAT across channel types frequently find that users who cannot communicate effectively over voice report the lowest satisfaction scores. RTT addresses that gap at the channel level, before the ticket is even logged.
“Accessibility is not a feature layer added on top of service delivery. It is a baseline expectation that shapes how every user experiences the support channel.”
| Method | Transmission Speed | Requires Third-Party App | Works on Existing VoIP | FCC Compliant |
|---|---|---|---|---|
| RTT Calling | Character by character, real time | No | Yes (VoLTE/VoIP) | Yes |
| TTY Relay | Message sent on completion | No (requires TTY device) | Partial | Yes (older standard) |
| Chat/Messaging | Message sent on completion | Yes (separate platform) | No | Varies |
| Video Relay Service | Real time (ASL interpreter) | Yes | No | Yes |
| Email Ticketing | Asynchronous | No | No | No |
Integrating RTT into Help Desk Workflows and ITSM Platforms
Adding RTT support to an existing ITSM environment requires changes at three layers: telephony configuration, agent training, and ticket logging. At the telephony layer, IT administrators must confirm that the organization’s carrier and phone system support VoLTE with RTT passthrough. Most major US carriers have enabled this, but enterprise PBX and contact center platforms vary. This is a change request that belongs in the CMDB as a configuration item update, not a standalone project.
At the agent layer, the primary adjustment is interface familiarity. Agents accustomed to voice-only calls need to monitor a text stream simultaneously. This is a training and workflow issue, not a technology barrier. Support team leads should update their knowledge articles to include RTT call handling procedures, including how to acknowledge the text channel at call start, how to handle simultaneous audio and text, and how to log the RTT interaction type in the ticket record for reporting purposes.
At the ticket logging layer, the interaction type field in the ITSM platform should be updated to capture RTT as a distinct channel. This matters for KPI reporting. Tracking the right KPIs for support requires channel-level granularity. If RTT tickets are logged as generic voice interactions, teams cannot measure FCR, CSAT, or MTTR for that segment separately. That blind spot makes it impossible to improve service for the users who need it most.
Modern help desk platforms with AI-assisted routing can be configured to flag incoming RTT calls for agents with RTT training, reducing the risk of mishandled interactions. The platform auto-classifies the ticket by channel type using the call metadata, and SLA breach risk is flagged before deadline based on queue depth. This keeps accessibility incidents within the same SLA framework as all other priority tiers.
Measuring the Operational Impact of RTT on Support Team Performance
Once RTT is operational and tickets are being logged correctly, support leaders can begin measuring its effect on team performance. The most direct metrics are FCR rate for RTT-tagged tickets, average handle time, and CSAT scores from post-interaction surveys sent to RTT users. These three data points tell a clear story about whether the channel is functioning well or generating escalations.
Teams that implement RTT without updating their logging and reporting frameworks often undercount its volume and misattribute poor CSAT scores to other factors. The fix is straightforward: add RTT as a channel filter in the reporting dashboard, set a baseline during the first 30 days of operation, and review it alongside voice and chat metrics in the same weekly cadence.
According to NICE, RTT calling enables both parties to see each character as it is typed, creating a communication experience that is more immediate than any store-and-forward messaging system. That immediacy translates directly to shorter resolution cycles for text-based support interactions, which reduces queue pressure during high-volume periods.
Operations directors reviewing workforce management data should also account for RTT in capacity planning. RTT calls may run slightly longer than voice-only calls during the initial adoption period, as agents develop fluency with the dual-channel interface. Factoring that into scheduling models prevents unintended SLA degradation. The workforce management implications are manageable but should be planned rather than discovered reactively.
The broader takeaway for IT service leaders is precise: RTT is not an edge-case accessibility feature. It is a channel configuration that affects compliance posture, CSAT reporting, and FCR rates for a specific and often underserved user segment. Teams that treat it as infrastructure, the same way they treat email routing or chat widget configuration, will manage it more effectively than those that treat it as a one-time compliance project.
