If interpreters appear online but aren't receiving On Demand calls, or a call only seems to reach one interpreter, this guide walks the LSC admin through how to diagnose it. Look at what the system actually did before you change any settings.
Step 1: Start with Routing Details
Before adjusting anything, look at how a specific problem call was routed. This is the most useful step and tells you which direction to investigate.
Navigate to Dashboard>Logs>On Demand.
Select the call in question, then open the "Routing Details" tab.
Review which interpreters were rung, how long it rang for each, and whether they declined.
Note: Routing Details shows internal interpreters who were rung, not crowd (BHub) interpreters. If an interpreter you expected isn't listed, check their online/offline times in the Interpreter Activity Logs.
For more on what this tab shows, see Call Routing Details.
This splits your troubleshooting into two paths:
The interpreters were never rung: continue to Step 2 (eligibility and routing lists).
The interpreters were rung but declined or timed out: skip to Step 5 (availability and behavior).
If the interpreters were NEVER rung
Work through Steps 2 to 4 in order.
Step 2: Confirm the interpreters were actually online
"Online and ready" is worth verifying rather than assuming. An interpreter can be signed in without their caller set to accept calls. If their caller wasn't online at the time of the call, they would not have been rung.
Navigate to Interpreters and select the interpreter.
In the interpreter's "Interpreter details" panel, open the "Logs" tab and select "Activity."
Confirm the interpreter had an active online session (caller accepting calls) at the time of the problem call.
Note: The Activity log reflects the time an interpreter had their caller set to accept calls, not total time logged in. If they were logged in but their caller wasn't online, that time won't appear here.
See Interpreter Activity Logs for more detail.
Step 3: Check the interpreter's permissions
An interpreter is only eligible for a call if their permissions match the call's language pair, communication type (OPI/VRI), and service type. If any of these don't match, they won't be rung for that call.
Navigate to Interpreters and select the interpreter.
Open the "Permissions" tab.
Verify the interpreter has the language pair, communication type, and service type that match the calls that aren't reaching them. Certain service types, such as Medical, must be added explicitly to the interpreter's permissions for them to be rung for those calls.
Important Note: Interpreters cannot accept calls until the LSC admin has set their permissions. Interpreters, even in "Enabled" status, will not be able to accept calls without permissions.
See LSC Quick Start Guide and Interpreter Onboarding Guide for more on setting permissions.
Step 4: Check the account's Priority, Call-Only, and Do Not Call lists
These account-level lists directly control who gets rung for that account's calls. They're the most common reason calls appear to reach only one (or a few) interpreters.
Navigate to Accounts and select the account placing the calls.
Open the Routing tab.
Review the lists: Interpreter Call List members are the first bucket rung for incoming On-Demand calls. If a call-only style restriction is in place, routing may be limited to just those interpreters. Do Not Call list interpreters are always excluded from that account's calls.
Step 5: Confirm with the requestor that the call was not initiated as a redial or with a gender preference
A call that was placed as a redial will only dial the specific interpreter who the previous call was with.
Calls that were placed with a gender preference will not dial interpreters with other genders.
If the interpreters WERE rung but declined or timed out
Step 6: This is not a routing configuration issue
If Routing Details shows the interpreters were rung but the call went unanswered, routing is working as designed. The interpreters simply did not pick up.
Use "Routing Details" to see how long the call rang each interpreter and whether they declined.
If the routing details show the interpreter was rung, but they claim they didn't get any notification, a few things could cause that:
Network or device delays: an older computer, many open browser tabs, or high CPU usage can delay the ring long enough that another interpreter answers before you hear it ring. This happens most often for languages with a very short response time, like Spanish, but it can happen in any language.
Many available interpreters: Boostlingo doesn't call every available interpreter immediately. If an interpreter answers right as more interpreters get rung, those added interpreters might only see a missed call badge and hear no ring at all.
A snoozed browser: browsers can suspend tabs with no recent activity. To prevent this, keep your account at the forefront of your screen and interact with it regularly. Our recommended browser is Chrome, where you can add your Boostlingo URL to the "Always keep active" section at chrome://settings/performance.
Have the interpreter go through Troubleshooting Boostlingo on a Computer Browser to improve their chances of being notified for a call.
Still not resolved? Contact Support
If you've worked through the steps above and calls still aren't routing as expected, submit a request and include:
The account or client company name and ID
One or two sample Call IDs that demonstrate the problem
The language pair, service type, and communication type (OPI/VRI) of those calls
The names or IDs of the interpreters you expected to be rung
What you found in Routing Details (were they rung, declined, or never rung)
This lets the support team quickly trace the exact calls.