Interpreter Scheduling and Billing Software: Why Coordinators Still Dial Down a List at 6am

Why interpreter operations break the moment you cross a few thousand jobs a month

It is 6:05am and a hospital scheduler calls your on call line. A Mam speaking patient is in pre op at 7:30 and consent cannot be taken without an interpreter. Mam is not Spanish, the two people in your roster who speak it live three hours out, and one of them is already confirmed at immigration court downtown at 9. Your coordinator opens a spreadsheet tab called AVAILABILITY, a shared inbox with 90 unread requests, and starts dialing. She fills it at 6:52. What nobody records is that she made eleven calls, that the interpreter who accepted drove 64 miles, that the hospital contract pays a two hour minimum with mileage after the first 30 miles, and that the interpreter is paid a 90 minute minimum at a different mileage rate. That reconciliation happens on the third of next month, by hand, and it is wrong in both directions.

The tool stack around this is usually a scheduling system, a shared inbox, a phone tree, QuickBooks, a Google Sheet of interpreter certifications, and a WhatsApp group per language. Boostlingo and Interpreter Intelligence are both real products and both do parts of this properly. The problem is the thing no tool owns: a single encounter object that knows the requesting client and their contract, the language pair and modality, the credential the client requires, the interpreter who accepted and at what pay rate, the actual start and end time, the mileage, the cancellation state, the pay line and the invoice line. Every system owns a slice. The coordinator owns the joins in her head, at 6am, on a phone.

The leak shows up in three places we see repeatedly: unbillable coordinator hours spent on the phone rather than on service quality, revenue quietly lost where a late cancellation or a travel charge was never applied because nobody caught it, and interpreter churn when pay statements arrive wrong twice in a row. Your interpreters are contractors who leave over pay disputes long before they leave over rates.

Problem 1: filling a job is a constraint problem, not a phone list

The request that arrives is not just a time and a language. It is Spanish for a deposition where the client requires a court certified interpreter, not a registered one. It is American Sign Language where the client requires an interpreter holding RID certification and the deaf consumer has a preferred interpreter from last time. It is a sexual assault forensic exam where the patient asked for a female interpreter. It is Kinyarwanda at a school IEP meeting where the only qualified person in your pool worked for the district as a parent advocate and has a conflict. Each is a hard filter, and the survivors then need ranking by travel time, by fill rate, and by whether accepting this job strands a longer assignment later that day.

That is an assignment problem with constraints, and both major platforms treat it primarily as an offer broadcast against a filtered list, which is how the wrong credential gets accepted first and a coordinator spends the next hour unpicking it. What a custom build does is model credentials, client rules and travel as first class constraints, then run a tiered offer cascade: preferred and previously used interpreters get a short exclusive window, then qualified regulars, then the wider pool, with the window length set per client and per urgency. Travel is computed as real drive time between the interpreter's previous confirmed appointment and this one, not straight line distance, which is the difference between a fillable 11am and a guaranteed late arrival. The measurable output is the number of coordinator touches per filled job, and driving that number down is the entire business case.

Problem 2: one encounter, two money models that never agree

The same 47 minute encounter produces two completely different numbers. The client is billed under their contract: a two hour minimum for on site, billed in 15 minute increments after that, travel time billable after 30 miles at a contracted rate, a late cancellation inside 24 hours billed at the minimum, a different rate for after hours and weekends. The interpreter is paid under their agreement: a 90 minute minimum, mileage at a flat rate from a home base, no pay for a cancellation inside 2 hours if they had not yet departed, a premium for legal work.

Off the shelf systems all support rate tables. What they handle poorly is rules that differ per client contract, per modality and per service line at once, with effective dates, because contracts get renegotiated mid year and last month's encounters must still bill at last month's terms. That gap is why providers end up rebuilding invoices in Excel, which defeats the system entirely.

A custom build treats billing as a rules engine with versioned contract terms, and it computes both the client charge and the interpreter payable from the same encounter record at the same moment. Every line carries an explanation of which rule fired, because your accounts payable clerk and a hospital's accounts payable clerk will both ask, and the answer cannot be a shrug. Invoice shape matters as much as calculation: a health system wants one invoice grouped by department with a cost centre column, a court wants one line per case number. Getting that right is the difference between net 30 and net 75.

Problem 3: nobody agrees on what actually happened at the appointment

The scheduled slot was 90 minutes. The provider ran late so the encounter started at 10:20. The patient no showed for the second half. The interpreter waited 40 minutes in a lobby. You can bill the wait under most contracts, but only if you evidence it, and your evidence is a paper form that lives in an interpreter's car until Friday.

What a build must include is a mobile app that captures a geofenced check in and check out at the facility, a signature on glass from the requesting staff member, a reason code for what happened, and offline capture because hospital basements and courthouse holding areas do not have signal. The moment encounter times come from the app rather than from a form typed in later, invoice disputes drop because the record is contemporaneous. Keep a photo attachment path for the clients who will never give up paper forms.

Problem 4: phone and video interpreting is routing, not scheduling

If you deliver over the phone or by video, the job is real time. A nurse dials in and expects a Spanish interpreter connected in under 30 seconds, and Haitian Creole in under a minute. That is a telephony and queue routing problem sitting next to your scheduling problem, and confusing the two is the most common way these projects go wrong.

Boostlingo is genuinely strong here and comes with an interpreter network you can overflow into, which is a real advantage that a custom build does not give you for free. If remote interpreting is most of your volume, that is a legitimate reason to buy rather than build. Where a build earns its place is when you have your own interpreter pool sitting idle between on site jobs, and you want the routing engine to offer them remote calls in the gaps, which requires the routing side and the scheduling side to share one availability model. Built on SIP or a programmable telephony provider, this converts dead time into billable minutes.

Problem 5: credentials expire quietly and clients audit loudly

Court certification, CCHI or NBCMI medical credentials, RID certification for ASL, background checks, hospital vendor credentialing, immunisation records and badge renewals all expire on their own schedules. A hospital audit asks you to evidence, for 40 named encounters, that the interpreter present was credentialed on that date. If your credential list is a spreadsheet, you are reconstructing that from email attachments for a week.

The build stores credentials as dated records with expiry, blocks offers to interpreters whose required credential lapsed before the appointment date, and warns at 60 and 30 days so your recruiter chases renewals instead of discovering them at 6am. Because appointment notes carry patient names and clinical context, treat the system as holding protected health information from day one: role based access, field level audit logging, per client retention and a business associate agreement you can honour. Retrofitting that later costs more.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A focused first release, meaning request intake, constraint based matching with a tiered offer cascade, encounter capture and client invoicing with per contract rules, runs $55,000 to $120,000 and ships in 10 to 16 weeks. A full platform adding interpreter pay runs and contractor statements, the mobile check in app, client and interpreter portals, and reporting runs $140,000 to $350,000 phased over 6 to 12 months.

What drives the number up in this category specifically: real time phone and video routing, which is its own subsystem and typically adds $40,000 to $90,000 because telephony, queueing and failover are unforgiving. Client system integrations, because a health system may push appointment requests from Epic and a court has its own case feed, and each is weeks not days. And the number of legacy contracts whose billing rules exist only as a habit in one biller's head, which is discovery time and cannot be skipped.

What keeps it down: start with on site scheduling and billing for your top five clients by revenue, which covers most of the money and most of the rule variations.

Build versus buy, and when buying is the right call

Buy if remote interpreting is the bulk of your delivery, if you are under roughly $3M in interpreting revenue, or if your client contracts are broadly similar. Interpreter Intelligence is a serious scheduling and billing product and will beat a mediocre custom build. Boostlingo is the stronger choice if you need a remote delivery platform and an overflow network. Paying a per minute or per seat fee to a product that already works is not a failure of ambition, it is arithmetic.

Build when two or more of these are true. Your coordinators spend more time chasing fills than managing quality. You run on site, phone and video against one shared interpreter pool and no single system sees all three. Your billing rules differ enough between clients that someone rebuilds invoices in Excel every month. You have lost a contract or a renewal because you could not evidence credentials or encounter times. Or you hold a real advantage, such as a rare language bench, that generic software flattens instead of protecting.

How to choose a developer for interpreting operations software

Ask them to whiteboard the encounter model before you sign anything. The right answer separates the request, the assignment offer, the confirmed assignment, the actual encounter, the pay line and the invoice line as distinct records, because a single job can be reassigned twice and cancelled once and every one of those states has money attached. A developer who draws one appointments table has built a calendar and is about to learn language services on your budget.

Ask how they will handle contract terms that change mid year. If the answer does not include effective dated rules and the ability to reprint a March invoice with March terms, keep looking.

Ask what they have shipped that works offline. Interpreters check in from hospital basements with no signal, and an app that assumes connectivity gets abandoned in a month.

Ask who owns the code, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and we would tell you to walk away from any developer who hedges on that question.