This post covers the decisions behind Floor Walker Reports and what they mean for the people who run a contact center on Flex.
Flex's built-in historical reporting is Flex Insights. It is a reasonable choice for many teams, and it is included in Flex's paid plans. According to Twilio's documentation, a few of its properties shape what you can do with it:
Together they mean two screens can count the same contact center differently, and changing a target is not a supervisor's job.
The most important decision: the live wallboard and the historical reports read the same events. Twilio sends the contact center's TaskRouter and Studio events to Floor Walker as they happen, through Event Streams in your Twilio account. The wallboard, the supervisor console and the reports are all built from that one feed, so a call shows up in today's report seconds after it ends.
From those events Floor Walker keeps four kinds of records:
The business rules are decided once, when each contact is stored, not in each report. Every queue visit knows whether it was offered, how it ended (answered, abandoned, short abandon, transferred), how long the customer waited, and whether it counted toward service level and was within it.
That makes the definitions short and explicit:
Because the rules are part of the stored record, every metric is a plain count, sum or ratio, and anyone who counts the same way gets the same answer, including your analysts in their own tools.
Every metric is defined once, with its name, its formula, a plain-language description and whether higher is better. The same definitions drive the wallboards on the TVs, the supervisor console, the reports and report builder, exports and scheduled emails, and Ask AI and the MCP server for AI assistants. So "abandoned" means the same thing on the wall at 4 p.m. and in the monthly review, and the same metric over the same period is the same number on every screen. It sounds obvious; in practice it is what ends the morning argument about whose number is right.
A sales line might aim for 80% in 20 seconds, a collections queue for 90% in 60. In Floor Walker each queue has its own threshold, target and short-abandon time, set by supervisors in one screen, with defaults of 20 seconds, 80% and 5 seconds. There are no separate service level settings on the wallboard or in the console: they read the same values.
When a supervisor changes a queue's threshold, that queue's stored contacts are re-evaluated with the new value, and the confirmation says how many were affected. Last month's report then uses today's definition.
That is a deliberate trade-off: a spreadsheet exported last week can differ from the same report run today. We chose "one definition everywhere" over "numbers frozen when they were run", because comparing this month with last month only works if both are counted the same way.
Every Studio execution, an IVR call or a bot conversation, becomes a journey with one step per widget, joined to the contact. Each journey ends in one of a few ways: handed to an agent, contained (the flow finished without an agent), abandoned in the IVR, or an error.
That gives containment rate, IVR abandon rate and the menu step where callers hang up, next to queue metrics, without changing flows. Two details matter in practice:
Any task attribute can become a report field: a customer tier, a product line, a region. It can be grouped and filtered like any built-in dimension. There is no fixed number of fields and no length limit, and because the values are read from the stored task data, a new field works for history too.
A reporting tool should be easy to leave, so the data is open from the start:
Ask AI answers questions such as "which queue had the worst service level last week?". The model plans up to three structured queries against the metric definitions; they run like any report, with the asking user's permissions, and a second step writes the answer from the numbers that came back. The model never writes code or database queries, and every answer shows the queries it ran.
The MCP server gives AI assistants such as Claude the same access: list the metrics and their definitions, run a query, ask a question, search contacts and open one contact end to end, from the IVR to the AI summary of the call.
Permissions are the same everywhere: agents see only their own numbers in reports, exports, Ask AI and MCP alike, checked on every request.
TaskRouter keeps 30 days of events, so at switch-on Floor Walker can import the last 30 days and you start with a month of history. IVR journeys and hold times begin from the day the live feed is connected, and anything older stays in Flex Insights or its export. Report data is kept for 25 months by default, in the Floor Walker environment you chose: hosted by us, or in your own cloud or data center.
Yes. Flex can send its TaskRouter and Studio events through Event Streams as they happen, so a reporting product can count the same contacts with your own definitions. Floor Walker Reports does that and imports the last 30 days when you start.
Treat every Studio execution as a journey: store each widget step and how it ended, and join it to the contact. That gives containment, IVR abandons and menu drop-off without adding tasks to every flow.
Feed both from the same events and count with the same definitions. In Floor Walker the wallboard, the supervisor console and the reports share one set of metric definitions and one per-queue service level setting, so the same metric over the same period is the same number everywhere.
Floor Walker adds live and historical reporting, a wallboard, a supervisor console, a predictive dialer and per-task screen recording to Twilio Flex, hosted by us or installed in your own cloud or data center. Read the reports docs at https://floorwalker.dev/docs/reports.
Book a demo: hello@floorwalker.dev
]]>Twilio provides the building blocks: voice calls, answering machine detection (AMD), task routing and Flex. It does not decide how many calls to place. This post explains how the Floor Walker dialer makes that decision, and what it means for the people running a campaign and the customers it calls.
Each mode is a choice about who waits: an agent listening to ringing, or a customer who answered.
| Mode | Rule | Who waits |
|---|---|---|
| Preview | The agent sees the lead, then dials | The agent |
| Progressive | One call per free agent | The agent |
| Power | Dials ahead for free agents, minus a safety margin | Sometimes the customer |
| Predictive | Like power, plus agents about to finish a call | Sometimes the customer |
Progressive is the default. Power and predictive raise agent utilization by dialing ahead, and accept that a customer occasionally answers when no agent is free.
The mode also decides who is put on the line first.
Agent first (preview, progressive, and callbacks an agent dials). The dialer reserves a free agent, puts them on the line, and only then dials the customer. The customer hears a person right after "hello": in our live test the silence was about 0.3 seconds, against about 3.2 seconds customer first. It also closes a gap: while a customer's phone rings, an agent who is only expected to take the call still looks free to Flex, and another call can take them. Agent first holds the agent from the start. The cost is agent time: the agent listens to every ring, and each dial uses two calls.
Customer first (power and predictive). The customer is dialed first; when a person answers, the call goes to the first free agent on the campaign. Because these modes open more lines than there are free agents, they cannot hold an agent for every line.
Every second, and right after an agent frees up, the dialer works out for each campaign how many new calls to place. Due callbacks take that budget first; regular leads get the rest. Three things go into it:
The dialer never dials for every agent it expects to be free. It keeps a safety margin, counted in agents, and adjusts it continuously.
We count it in agents rather than as an overdial ratio because the risk behaves that way: with 50 agents a few extra answers almost always find someone; with 12 they collide. It starts at about a quarter of the team (at least one agent, at most six):
| Situation | What the dialer does |
|---|---|
| Recent answered calls waited longer than the target allows | Raises the margin: dials less |
| Waits stay well under the target | Lowers the margin a little: dials more |
| Waits exceed four times the target | Safety breaker: raises the margin, runs the campaign as progressive for five minutes and alerts supervisors |
The margin steers by the campaign's missed-wait target, 3% by default: the share of answered calls that waited longer than normal for an agent, hung up while waiting, or reached the hold limit.
"Longer than normal" matters. Even with a free agent, connecting a customer to an agent working in a browser takes a few seconds, about 3.5 in our live measurements. That is not a sign of too few agents, so the dialer learns each campaign's normal connect time, adds two seconds of grace, and counts a miss only beyond that.
3% also appears in some regulators' rules for predictive dialing, but their definitions of an abandoned call differ from country to country and from ours. The target is a campaign setting; confirm the rules for your campaigns with counsel.
Some dialers hang up on a customer who answers when no agent is free. Ours does not: someone you called is better served by a short, explained wait.
| Time after "hello" | What the customer hears |
|---|---|
| Up to the normal connect time | Silence. Most customers are connected here |
| Plus two seconds | Still silence: a message cut off by the agent's "hello" sounds like a fault |
| After that | A message saying who is calling and that an agent is joining, then hold music. Without music the message repeats, so there is never dead air |
| 90 seconds | An apology and a promise to call back. The callback is booked automatically and the attempt is not counted |
The messages and the music are set per campaign.
Dialing ahead works because, across many agents, someone is almost always about to become free. Below 12 active agents, power and predictive fall back to progressive on their own: in our simulator, holding a 3% target with 10 agents needed a margin of about 40% of the team. The real benefit starts at around 15 agents.
AMD is set per campaign, and it trades agent time against the customer's first seconds:
AMD is off on agent-first calls: the agent hears the greeting and can leave a message.
Every number is checked when the dialer picks the lead and again at dial time. Two questions decide whether it may be called:
A lead is called only when both are open; otherwise it is postponed, not dropped, to the next moment when both are. A campaign whose calendar has never loaded does not dial at all. Do-not-call lists and attempt limits are checked in the same pass.
A customer who answers reaches the agent as an ordinary Flex voice task in the campaign's own queue, so hold, transfer and call recording work as usual. The task is accepted automatically, and the agent sees a lead card with the customer's name, number, campaign and the lead details your administrator chose to show.
After the call the agent picks a disposition: success, closed, try again later, callback (for themselves or anyone on the team), do not call, or invalid number. It decides what happens to the lead next. Calls that rang out or were busy never reach an agent; they are retried by the campaign's rules.
One detail matters for pacing: the dialer only dials for free agents, so an agent who leaves a task in wrap-up quietly drops out of the campaign. An optional automatic wrap-up closes the task a set number of seconds after the disposition is saved.
We test pacing in a simulator with virtual agents and phone lines: 120-minute runs, synchronous AMD, a 3% target, a connect time of 3.5 seconds give or take 0.7, and a 25% chance that a call reaches a person. Average agent utilization over two runs:
| Team | Progressive | Predictive |
|---|---|---|
| 20 agents | 73.9% | 79.1% |
| 50 agents | 73.0% | 89.1% |
In those runs predictive held the missed-wait rate between 2.9% and 3.2%, and no customer reached the 90-second limit. These are simulator results, not production traffic; the estimates settle over a campaign's first few hundred real calls.
No. Flex lets agents place outbound calls, but pacing, answering machine handling, retries and calling-hour rules have to be built on top of Twilio or added with a product such as Floor Walker.
It dials ahead from answer rates learned per campaign, keeps a safety margin of agents, and adjusts that margin by watching how many answered customers waited too long. If waits overshoot badly, it falls back to progressive for a few minutes.
With small teams (below about 12 to 15 agents), or when every customer must reach a person right after "hello". Predictive pays off for larger teams with low contact rates.
Floor Walker adds a predictive dialer, per-task screen recording, a CRM and live and historical reporting to Twilio Flex, hosted by us or installed in your own cloud or data center. Read the dialer docs at https://floorwalker.dev/docs/dialer.
Book a demo: hello@floorwalker.dev
]]>This post explains how Floor Walker's screen recording handles that, and what it means for the people who review recordings. The short version: we record each agent's screen once, in parts of about 30 seconds, label every part with the conversations that were open while it was recorded, and give each conversation its own recording made of the parts that carry its label.
Quality and compliance reviews start from a conversation, not from an agent's day. The usual questions are:
All of them need the recording of one conversation, from the moment the agent picked it up to the moment they closed it, found next to the conversation itself. A recording of "Tuesday, 14:00 to 15:00, agent 12" is not something anyone wants to scrub through.
The obvious design is to start a new video when a conversation starts and stop it when the conversation ends. It runs into three problems as soon as agents work in parallel:
Floor Walker records one session per agent, however many conversations are open:
The recording is cut into parts of about 30 seconds as it goes, and every part is labeled with all the conversations that were open at any time while it was recorded. A conversation's recording is simply the parts that carry its label. Nothing is copied or edited per conversation, so three overlapping chats take the same storage as one.
A conversation's recording covers its whole open period. That includes time the agent spent looking at another chat. We went back and forth on this and kept it, because it answers the question reviewers ask most: what was the agent doing while this customer waited? If two chats are handled side by side, both recordings show the same footage for that stretch, and each still plays on its own.
Edges are rounded to the part. A recording can start up to 30 seconds before the conversation was accepted and end up to 30 seconds after it was completed. For quality review we think that is the right trade: reviewers get a little context on either side, and nobody has to reason about frame-accurate cuts.
Long recordings start quickly. Recordings are streamed in the browser, so even an hour-long recording starts playing right away instead of after a download.
Recording follows the agent's work in Flex. There is nothing to start, name or upload, and the desktop app on the agent's computer has no settings for agents to fill in; it gets everything it needs from Flex. The Flex header shows Recording, Recording Paused or Not Recording, so the agent always knows the state.
Pausing for sensitive data. Agents pause recording from the Flex header or the task header before a card number or an ID document appears on screen, and resume when it is gone. Nothing is captured while paused, so the paused time does not exist in the recording; playback simply continues with the next part. Because the screen is shared by every open conversation, pause applies to all of them.
By default every accepted conversation is recorded, on every channel. Admins can narrow that in Flex:
Admins can also let agents opt out of recording their own sessions. Changes reach every agent within a minute.
Each part is uploaded as soon as it is finished, so at most about 30 seconds of recording waits on the agent's computer at any moment. A laptop closed mid-call loses seconds, not the call.
The edges are worth knowing before rollout:
For voice tasks, the call audio is also recorded on its own and sent for transcription. The transcript feeds the AI summary, sentiment, outcome and topics that appear on the customer's timeline in the Agent Workspace, so a reviewer can read what a call was about before deciding to watch it.
Recordings are found where reviewers already work:
While watching, supervisors and QA reviewers pin coaching notes to moments in the recording, with a category (General, Positive, Needs Improvement, Compliance, Technique, Communication) and an optional 1 to 5 star rating. Notes show as markers on the timeline, and the player has keyboard shortcuts for skipping back and forth. Coaching notes are kept after the recording itself expires.
Recordings are kept in private storage by the Floor Walker service, which we either host for you or install in your own cloud or data center. They are played only through short-lived links issued to a signed-in Flex user, and the agent's computer and the reviewer's browser only need to reach the Floor Walker service over HTTPS. Recordings are deleted automatically after a retention period, 90 days by default, which we can change for your installation.
Flex can record calls, but not the agent's desktop. Screen recording needs software on the agent's computer that captures the screen, plus somewhere private to keep and play the recordings. Floor Walker adds a desktop app for Windows and macOS that follows the agent's Flex tasks, with playback inside Flex.
The agent's screen is recorded once, in parts of about 30 seconds, and each part is labeled with every conversation that was open while it was recorded. A conversation's recording is made of the parts that carry its label, so overlapping chats share footage and each plays on its own.
They press Pause Recording in the Flex header or the task header before the sensitive data appears, and Resume when it is gone. Nothing is captured while paused, and the pause covers all of the agent's open conversations.
Floor Walker adds per-task screen recording, a predictive dialer, a CRM and live and historical reporting to Twilio Flex, hosted by us or installed in your own cloud or data center. Read more in the screen recorder docs at https://floorwalker.dev/docs/screen-recorder.
Book a demo: hello@floorwalker.dev
]]>