Browser-only call team setup: numbers, routing, extensions

You can run your whole inbound team in a browser by buying numbers on demand, routing calls to browser agents, and checking a few home-network basics. A clean browser-only call team setup takes about an hour to build and test. You’ll end with a US local or toll-free entry number, a fair ring order, a short queue, voicemail after limits, and per-agent extensions in the browser.

Browser-only call team setup: what you’ll build

In this example, a five-agent support team in Mumbai and Cebu answers a US local number from 9:00–17:00 ET. After hours, calls go to voicemail. If no one picks up after two ring legs, calls overflow to a short queue, then to voicemail on a time limit. The manager receives scheduled email reports to watch answer rates.

Here’s a quick plan you can follow now:

1. Buy one or two numbers and point them to a simple greeting, then to your team. This gives callers a clean entry point and a place to add hours and overflow.
2. Create five agent logins with extensions and have each log into the web phone. Use a USB headset and grant mic permissions so the browser can ring and carry audio.
3. Add routing: round-robin (cycle through agents in order) for 20–25 seconds per agent, then overflow to a short queue (hold the caller until an agent is free), then voicemail. This handles small spikes without waking phones after hours.
4. Do a 10-minute home-network check with each agent. Test on Chrome or Edge, confirm audio devices, and try a second network if audio sounds choppy.
5. Place one test call during hours and one after hours. Watch live logs to confirm the ring order, queue step, voicemail path, and that the recording shows up.

If those two calls match your plan, you’re ready to move traffic.

Provision numbers and a clean entry path

Start with the number type your customers expect. For US audiences, a local number in the metro they’re calling from feels familiar; toll-free can look national and reduce dial hesitation. If you also serve the UK, Australia, or other regions, provision local or national numbers there as a second step. You can then point country-specific ads to the right entry point. On CallFlow, numbers provision instantly from your prepaid wallet balance, so you can test in minutes and scale up as your team grows.

Pick area codes close to your buyers. If your customers sit in Chicago, a 312 or 773 often gets more first picks than a far-off code. Avoid placing a distant code unless you need it for a niche campaign or vanity number.

Keep the entry flow simple. A good starting path is: greeting (5–10 seconds), then route to agents. If you need an IVR (an automated menu where callers press keys) to steer sales vs. support, keep it to one short menu with clear options. Long trees lose callers and add handoff delays that sound like dead air.

If you record calls for QA or compliance, turn on call recording at the number or campaign level. Recording rules differ by country and even by state in the US. Some require both parties to consent. Ask your counsel how to label the greeting (“This call may be recorded…”) for your markets.

If you plan to use daily or per-agent call windows, set the number’s business hours now. A number-level window prevents after-hours ringing and sends callers to voicemail with a working-hours message. For ideas on how to design your entry and overflow paths, see the patterns in call center routing.

Add agent extensions in the browser

Create five sub-accounts (agents) and assign each an extension. An extension is a short internal number. Use it to label teams and for per-agent reporting. Each agent then logs into the browser softphone (the web phone that runs in the tab) with their credentials.

Have agents use a wired USB headset. It cuts echo and picks a single mic and speaker. In the browser, when the web phone prompts for mic access, click Allow. Then open audio settings and choose the headset for both input and output. Agents should do a short echo test if your tool offers one, or place a quick internal test to another agent to hear both ways.

Explain how agents answer in the browser. When a call comes in, the tab rings and shows the caller’s number. Agents click Answer and talk on the headset. If you want to stop after-hours rings for a given agent, set per-agent business hours. Their line then rings only in their window. The system moves on to the next agent outside it. For details on setting per-agent windows, see per-target call windows.

Teach login hygiene. One active tab per agent is enough; more can split notifications. Keep the tab pinned or in focus during shifts so the browser can play the ringtone. If audio fails or the mic won’t start, use the troubleshooting guide in the next section.

As your team grows, use extensions to mark teams (Sales, Support, Billing) and reach the right group fast using those internal numbers. This also keeps per-agent and per-team reporting clean.

Route calls to browser agents: a clean starting config

A good starter rule set looks like this. Ring agents round-robin (cycle through agents in order) for 20–25 seconds per leg so each person gets a fair shot. If no one picks up after two legs, overflow to a short queue (hold the caller until an agent is free) with hold music. If it still isn’t answered after 60–90 seconds in the queue, send the caller to voicemail. This protects hold times, keeps missed calls in one place, and avoids sending callers to a random personal voicemail.

If you see small spikes at open or lunch, try a variation. Ring the top two or three agents at once for 20 seconds. Then send the rest into the same queue. Simultaneous ring cuts first-response times during bursts. Don’t target more than three agents at once or it gets noisy.

Set call windows (business hours) both at the number and for each agent. The number window enforces open/closed. Per-agent windows stop rings for people outside their shift while keeping the queue moving.

Here’s the route for our running example.

To confirm it’s working, place a call and watch the live call log. You should see each leg with a timer: who rang, how long it rang, and where it overflowed. When a call hits the queue, the log shows how long it held and whether an agent pulled it out or it went to voicemail. If a step doesn’t appear, fix the rule before you scale traffic. For deeper ideas on building failover (a fallback path when a step doesn’t answer), see failover call forwarding.

Network and device checklist for WFH teams

Your agents will use WebRTC (the browser voice tech that carries audio in the tab). The browser, the headset, and the home network all matter. Run this checklist during onboarding, then again if quality slips.

• Supported browsers: Use the latest Chrome or Edge. Safari works but prompts for mic permissions more often. Keep just one audio device active in your OS sound panel so the browser picks the right one.
• Connectivity: Wired Ethernet is best. If Wi-Fi, sit close to the router and favor 5 GHz. Latency under about 150 ms and low jitter (variation in packet delay) give clean audio. If calls sound choppy, test the same call path from a phone hotspot or a neighbor’s Wi-Fi to isolate the issue.
• Firewalls/VPN: Allow WebRTC traffic. Some corporate VPNs block or throttle UDP (the real-time transport WebRTC uses). If VPN is required, test call quality and try split tunneling so voice goes outside the VPN. If your firewall has a “strict” mode, relax it for the agent’s browser or add the browser as an allowed app.
• Home routers: Avoid crowded 2.4 GHz bands that also feed TVs and smart devices. Prefer 5 GHz. Turn off aggressive QoS (traffic rules that limit or prioritize bandwidth) if it throttles uploads too low. If your ISP blocks UDP or uses CGNAT (ISP-side NAT that can affect call setup), try a mobile hotspot as a quick check and contact the ISP.
• Device tips: Close heavy tabs and background apps during shifts. In the browser, set the headset as the default mic and speaker. In Windows/macOS, disable audio “enhancements” that add noise reduction or spatial effects; these can distort voice.

If you hit mic errors, one-way audio, or rings that never pop, walk through the steps in browser softphone fixes. That guide also includes deeper firewall notes you can hand to IT.

QA and go-live checks

Do two end-to-end tests before you point ads or publish the number. First, call during business hours. You should hear the greeting, then a ring on Agent 1 for about 20–25 seconds, then Agent 2, then the queue’s hold music. Let it sit long enough to hit voicemail. Leave a short message. In your logs, confirm each step shows with realistic timers and that a recording exists for the whole call.

Second, call after hours. You should hear the closed message and land in voicemail without any agent rings. Leave a message. In the log, confirm it used the after-hours branch and that the timestamp aligns to your window.

Check caller ID on the agent side. Agents should see the customer’s number. If they see the business number instead, adjust caller ID presentation if your system allows it so agents can call back faster.

Watch for common failure modes during the first day. One-way audio at answer often means a blocked mic in the browser or a VPN/firewall that won’t pass UDP (the real-time transport WebRTC uses). Re-grant mic permissions and retest off VPN. Calls that drop at 20–30 seconds can point to NAT (address sharing in the router that can break calls) or SIP ALG (a router feature that rewrites call traffic). Switch Wi-Fi bands, turn off SIP ALG, or test on a hotspot to confirm. If a personal mobile voicemail “wins” the race because an agent forwards from the device side, keep ring timers at 20–25 seconds. Turn off device-side forwarding and let the queue handle overflow.

Turn on scheduled email reports for the manager so they can watch answer rates, missed calls, and very short calls during the first week. Real-time logs help in the moment; daily summaries show staffing gaps by hour.

SIP app vs browser phone: which should your agents use?

Small, mixed WFH teams should start on the browser phone. It needs no install, onboards fast, and you can control devices and hours from the center. Keep everyone in one tool until a clear need appears.

Move heavy users to a SIP softphone (a dedicated VoIP app [internet calling] that registers to your system) when they need background ringing even if the browser tab isn’t active. Do the same if they handle very high volume and want hotkeys or power-user layouts. If that’s you, follow the steps in SIP softphone registration.

Here’s a short comparison to help you decide:

The trade-off is focus vs. flexibility. Keep one tool if you can. Mix only when a clear need appears so training and support stay simple.

Move from pilot to steady state

Flip traffic on for one region or one ad set once your tests match the plan. Watch live logs hourly for the first day, then rely on scheduled reports. If your team grows or your hours change, update call windows and the queue limit before volume spikes. If you want to try weighted routing (send a set share to each agent) or priority routing (try higher-priority targets first), add it later. Wait for a week of baseline data so changes are clear.

Ready to build your browser-only team? Create an account at CallFlow or contact us.