Network basics for stable workshops

This guide helps you prevent and handle network-driven transcript issues in RoomRadar workshops. Use it when sessions involve many phones, unfamiliar venues, or mixed Wi-Fi quality. In a hurry: validate coverage at table level, separate local vs room-wide failures, and keep a fallback routine so workshop flow continues during short dips.

Fast path

1. Confirm network details with venue before workshop day.
2. Run a table-by-table walk test, not a single front-desk speed test.
3. Keep facilitator and participant devices on the same intended network.
4. Distinguish one-table failures from room-wide failures quickly.
5. During brief drops, keep discussion running and recover capture without panic.

What to confirm before session day

Ask venue or IT support concrete questions:

• expected device density in the room
• captive portal or login requirements
• known weak zones
• on-site contact during workshop opening window

RoomRadar reliability depends more on stable connectivity than peak bandwidth numbers. A "fast" network with frequent handoff drops is worse than a moderate but consistent one.

Pre-flight network check that matches real use

Run checks at every planned table zone:

1. connect a phone to the actual workshop network
2. open RoomRadar join page
3. speak one short test line
4. verify transcript appears promptly
5. note weak zones in your table map

This catches localized dead spots that a single generic speed test will miss.

If weak zones appear, either adjust seating layout or mark those tables for early monitoring.

Live diagnosis: local issue or room-wide issue?

Signs of local issue

• one table drops while others remain healthy
• one corner shows repeated instability
• swap/reposition at one table improves behavior

Action: local fix first (placement, reconnect, spare device).

Signs of room-wide issue

• many tables degrade at once
• transcript latency spikes across groups
• failures cluster right after all tables start speaking

Action: communicate briefly, keep discussions going, stabilize network path, then verify groups systematically.

For repeated local drops, use [Reconnecting a device without losing the discussion](/guides/setup/reconnecting-a-disconnected-device). For repeated room-wide behavior, involve venue support early.

Practical fallback behavior during short outages

When capture pauses for a short period:

1. tell tables to continue discussing
2. ask them to keep local notes
3. restore connection and verify with one-line checks
4. continue facilitation without replaying the whole round

Short outages become damaging only when facilitator reaction is chaotic.

Common network failure modes and fixes

Facilitator on one network, tables on another

Fix: standardize network path before session starts. Mixed paths slow diagnosis.

Guest network changes behavior as room fills

Fix: run a second quick check after participants sit down.

Phones roam near doors/corridors

Fix: reposition table phone slightly inward and retest.

Latency bursts right after prompts

Fix: treat as possible congestion. Avoid unnecessary reconnect loops on every phone at once; prioritize critical tables and communicate clearly.

This guide is for...

Use this guide when your main risk is connectivity stability and latency under multi-table load.

If your main risk is permission or local phone behavior, use [Fixing microphone permission problems](/guides/setup/microphone-permissions-ios-android) and [Replacing a participant phone during a session](/guides/setup/replacing-a-phone-mid-session).

Related guides

• [Preparing the room before a workshop starts](/guides/setup/preparing-a-room-for-a-multi-table-workshop)
• [Starting a RoomRadar session](/guides/setup/start-a-roomradar-session)
• [Reconnecting a device without losing the discussion](/guides/setup/reconnecting-a-disconnected-device)
• [Replacing a participant phone during a session](/guides/setup/replacing-a-phone-mid-session)
• [Troubleshooting transcription latency under load](/guides/advanced/troubleshooting-transcription-latency)