Starting a RoomRadar session

This guide helps you launch a RoomRadar workshop cleanly so the first activity starts with working capture, not emergency troubleshooting. Use it for every session opening, especially with multiple tables. In a hurry: run the 15-10-5 minute sequence, verify one line per table, and do not start content until mapping and stream checks are complete.

Fast path

1. 15 min out: open session, set groups, confirm spare phone readiness.
2. 10 min out: connect one phone per table and assign groups.
3. 5 min out: test each table and resolve weak spots.
4. First 2 min with participants: do one live confirmation round.
5. Start content only after all active tables show fresh lines.

What a successful launch looks like

A strong launch is not "most tables connected." It means all of these are true:

• table labels and group labels match
• one active phone per table
• transcript flow visible from each active table
• known fallback path for failures

If one is missing, first-round facilitation quality drops quickly.

15-10-5 minute launch routine

15 minutes before participants enter

• open RoomRadar session
• match group count to real table count
• name groups exactly as physical labels
• confirm spare phone and fallback host device

10 minutes before participants enter

• connect one phone per table
• place phone near conversation center
• run one test sentence at each table

5 minutes before participants enter

• retest weak tables
• remove duplicate phones
• confirm facilitator view can scan all groups quickly

If any table remains unstable, mark it for first-round local support.

First two minutes with participants

Use one short script:

"Each table, say your table label once. I’ll confirm you are live."

Go table by table. Do not assume silence means readiness.

If one table fails, fix locally while others stay in flow. For table-level dropouts, use [Reconnecting a device without losing the discussion](/guides/setup/reconnecting-a-disconnected-device).

Common launch failures and immediate fixes

Launching before mapping is verified

Fix: pause first content prompt and run quick mapping check.

Permission denied at one table

Fix: resolve with [Fixing microphone permission problems](/guides/setup/microphone-permissions-ios-android), then rerun one-line test.

Text in wrong group

Fix: reassign immediately before conversation advances.

Duplicate phones on one table

Fix: keep one active device and disconnect extras.

First-10-minute launch log

Keep a tiny launch log while participants begin:

Time | Table | Issue | Action | Resolved (yes/no)

This does two things in practice:

• it stops repeated troubleshooting at already-fixed tables
• it gives clean evidence for improving your next startup routine

You can keep this log on paper. What matters is visibility under pressure.

This guide is for...

Use this guide when your risk is startup chaos in the first 10 minutes.

If launch is stable but ongoing table quality degrades, continue with [Testing microphones before participants arrive](/guides/setup/test-audio-before-workshop) and [Network basics for stable workshops](/guides/setup/network-basics-for-workshops).

Related guides

• [Assigning tables to groups in RoomRadar](/guides/setup/assign-tables-to-groups)
• [Connect phones as microphones for multi-table workshops](/guides/setup/connect-phones-as-microphones)
• [Fixing microphone permission problems](/guides/setup/microphone-permissions-ios-android)
• [Reconnecting a device without losing the discussion](/guides/setup/reconnecting-a-disconnected-device)
• [Monitoring discussions across groups without losing context](/guides/workflows/monitoring-discussions-across-groups)