## Info
🌐 This article was translated from Japanese with AI assistance, then reviewed by the author.
Original (Japanese): https://qiita.com/yosuke-suzuki/items/24b555ec3125f9e42527
Introduction
In the April 20, 2026 update, Amazon Connect added touchtone buffering, a feature that temporarily stores and holds digits a caller presses on the keypad before or during a voice prompt.
https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-connect-touchtone-buffering/
With this, callers can enter digits before a prompt finishes, and inputs are no longer lost even if they press too early or in rapid succession. Because callers reach their destination faster, it can improve the customer experience.
In this article, I actually build this into a contact flow and check how it behaves.
ℹ️ Information is current as of June 2026. Please check the official documentation for the latest details.
What you'll learn
- What touchtone buffering does (Before / After)
- How the
Play promptandGet customer inputblocks behave when combined with the buffer
Conclusion first
When touchtone buffering is enabled, the IVR input experience changes as follows.
| Aspect | Before | After (buffering enabled) |
|---|---|---|
| Pressing early / in bursts | Inputs may be lost | Held in the buffer, up to 30 digits |
| Skipping prompts | Key barge-in is possible, but there is no way to skip a prompt | If digits are buffered, the prompt can be skipped entirely without playing to the end |
| Caller context | Only input after the call connects | Can be passed in advance via the dial string |
The first two ("pressing early / in bursts" and "skipping prompts") improve the input experience during the call itself: inputs are not lost when pressed early, and on a familiar menu the caller can move ahead without waiting for the prompt.
The third ("caller context") applies to calls originated from a website or app (choose-to-call / app-to-call). The official documentation describes it as follows:
Touchtone buffering also enables applications to pass known caller context into a flow before the conversation starts. In choose-to-call and app-to-call scenarios, the originating application can append a customer identifier, web session reference, or other context to the dial string. For example,
tel:+15555555555,1234567sends the digits1234567into the buffer the moment the call connects.
1. What is touchtone buffering
Below is an excerpt from the official documentation. In short, it is a mechanism that enables "type-ahead" input in an IVR.
Touchtone buffering in Connect Customer eliminates a common frustration in IVR systems by allowing customers to enter their complete menu path immediately (such as pressing 1-2-3 in rapid succession) or input identification numbers (such as account IDs or order numbers) without waiting for each prompt to finish or losing their inputs. This "type-ahead" capability reduces call handling time and improves self-service containment.
Overview
- Callers can type a menu path ahead, such as pressing
1, 2, 3(DTMF) together - Identification numbers such as account or order numbers can also be entered without waiting for each prompt to finish
- Entered digits are collected in a temporary buffer of up to 30 digits and consumed when the flow needs them
- Used digits are discarded immediately after processing; once the buffer reaches 30 digits, further input is ignored until space frees up
The result is shorter call handling time and improved self-service containment.
2. Supported channels
Only the Voice channel is supported. Other channels go to the Error branch.
| Channel | Supported |
|---|---|
| Voice | Yes |
| Chat | No (Error branch) |
| Task | No (Error branch) |
| No (Error branch) |
3. Hands-on
3.1 Test environment
- AWS Region: Tokyo (
ap-northeast-1)
3.2 What I tested
I check how the IVR input behavior changes with touchtone buffering on / off.
| # | Test case | Buffering | Expected behavior |
|---|---|---|---|
| 1 | Pressing a digit while the Get customer input block is running | Off | Since the block is waiting for input, a digit pressed during the prompt is accepted (DTMF barge-in; possible before this update too) |
| 2 | Pressing a digit while the Get customer input block is running | On | If a digit is in the buffer, it is dequeued automatically and the flow advances without prompting the caller |
| 3 | Pressing a digit while the Play prompt block is running | Off | Not waiting for input, so a digit pressed during playback is not held and is lost |
| 4 | Pressing a digit while the Play prompt block is running | On | With the skip option enabled, the prompt is skipped entirely as long as digits remain in the buffer |
| 5 | Multi-digit input | Off | Digits pressed before the input block's prompt are lost; the caller must enter them again after the prompt |
| 6 | Multi-digit input | On | Digits pressed before the prompt are dequeued by the Get customer input block without prompting |
3.3 Building the contact flow
I build a contact flow for testing. The overall layout is below. It consists of 18 blocks in total, but I will explain the key ones: ① Set Touchtone Buffer Behavior, ② Play prompt, and ③ Get customer input.
3.4 Block settings
① Set Touchtone Buffer Behavior
- Touchtone buffer option:
Enable Buffering
② Play prompt
-
Text to speak (set to wait 5 seconds so I can test input during playback)
<speak> Prompt playback test<break time="5000ms"/> Playback finished </speak> Interpret as:
SSML
ℹ️ When you enable the "Skip or interrupt this prompt when touchtone buffering is enabled" option, the prompt is skipped if digits remain in the buffer. It is OFF by default, so leave it unchecked for prompts that must always be played.
③ Get customer input (3 places)
- Text to speak:
DTMF test - Options (DTMF):
1, 2, 3
4. Verification
I test whether digits pressed ahead during each block are held / consumed with touchtone buffering on / off, and whether the prompt is skipped. The test flow places a Play prompt that waits 5 seconds, followed by three Get customer input blocks for DTMF 1 / 2 / 3. During prompt playback I press 1, 2, 3 ahead and check how each block processes it.
Results
| # | Test case | Buffering | Result |
|---|---|---|---|
| 1 | Pressing a digit while Get customer input is running | Off |
Input during the prompt was accepted ✅ |
| 2 | Pressing a digit while Get customer input is running | On |
Advanced to the next block without prompting ✅ |
| 3 | Pressing a digit while Play prompt is running | Off |
Input during playback was lost ✅ |
| 4 | Pressing a digit while Play prompt is running | On |
The prompt was skipped ✅ |
| 5 | Multi-digit input | Off |
Digits pressed before the prompt were lost ✅ |
| 6 | Multi-digit input | On |
Buffered digits were received without prompting ✅ |
From the tests, I confirmed the effect of touchtone buffering on the following points:
- For the Get customer input block, when a digit is in the buffer the flow advances automatically without prompting (
#2) - For the Play prompt block, with the skip option enabled the prompt is skipped entirely while digits remain in the buffer (
#4) - Multi-digit type-ahead is also received without being lost (
#6)
None of these behaviors appeared when buffering was off, so type-ahead is clearly working.
Summary
In this article, I tried out type-ahead digit input with touchtone buffering. Only when buffering was on were the digits pressed during and before a prompt carried over to the following blocks. For IVRs that repeat "long announcement" → "collect digits" many times, it seems worth considering from a customer-experience perspective.
Top comments (0)