Every scheduling product demos beautifully. A calendar appears, an appointment gets dragged onto a Tuesday, everyone nods. The problem is that interpreter scheduling fails in ways a demo never shows: at 4:50 PM when a client cancels tomorrow's 8 AM job, when two hospitals book the same Korean interpreter into overlapping slots across town, when the invoice goes out with weekday rates on a Saturday evening assignment. Evaluating software means evaluating it against those moments — the failure modes — not against the happy path.
Here's what to actually test, and how.
Conflict detection that understands travel
The baseline question: can the same interpreter be booked into two overlapping jobs? If the answer is yes, stop the evaluation — everything else is decoration on a system that will eventually strand a client in a waiting room.
But overlap is the easy case. The real test is travel time. An on-site job ending at 10:30 on one side of town and another starting at 10:45 on the other side don't overlap on a calendar, and they are absolutely a conflict in the real world. Good scheduling software lets you attach a buffer to on-site work so that back-to-back bookings account for the drive between them.
Ask the vendor to reproduce exactly this scenario in the demo: one interpreter, one morning job with a buffer, then attempt the 10:45 booking. If the system shrugs and accepts it, you've learned what you needed to know.
Recurring series as a real object
A huge share of interpreting work is recurring — a weekly therapy appointment, a semester of classes, a standing Tuesday clinic. The test isn't whether the software can create a repeating job; nearly anything can. The test is what happens to the rest of the series when reality intervenes:
- Cancel one instance — do the other nineteen survive untouched?
- Change the time from week twelve onward — does it fork cleanly, or does the whole series rewrite itself?
- Swap the interpreter for one week of a series — is that a two-click substitution or a delete-and-recreate?
Agencies that live with weak series handling end up creating every instance by hand "just to be safe," which means the software has failed at the exact thing it was bought for.
Broadcast when you want speed, assign when you want control
Filling a job has two legitimate modes. Sometimes the dispatcher knows exactly who should take it — the client asked for a familiar interpreter, or the assignment needs a specific certification — and direct assignment is right. Sometimes the job needs to fill fast, and the right move is to broadcast it to every qualified, available interpreter at once and let the first acceptance win.
Look for both, and look for what "qualified" means in the broadcast: it should filter on language, credentials, and availability automatically, so a broadcast never becomes a spam blast to interpreters who could never take the job. Bonus points if the system handles the awkward race gracefully — two interpreters tapping accept within seconds of each other should produce one assignment and one polite "already filled," not a double booking.
The rate engine is the product
This is the section vendors hope you skim. Interpreting billing is genuinely complicated, and the rate engine is where scheduling software either earns its subscription or quietly costs you money every month. At minimum it needs to model:
- Dual rates on every job — what the client is billed and what the interpreter is paid are different numbers with different rules, tracked together so every assignment knows its margin.
- Time-based adjustments — evening, weekend, and holiday rules that apply themselves from the job's actual date and time, not from a biller remembering to tick a box.
- Rush premiums — bookings made inside a short-notice window priced accordingly, automatically.
- Minimums — the two-hour minimum is an industry standard; a thirty-minute job should bill as two hours without human intervention.
- Mileage and travel — on-site work carries travel costs; they belong on the job, not on a sticky note.
- Per-client exceptions — that one contract with negotiated rates from 2023 has to be representable, or your team will be hand-editing its invoices forever.
Then confirm the engine's output flows straight into invoicing. A rate engine that computes the right number but makes you re-type it into an invoice has only done half the job.
The calendar is what you see in the demo. The rate engine is what you live with every month after.
Where to spend your evaluation time
The three-portals test
An interpreting agency has three audiences, and each needs its own door into the system. Admins need the full dispatch view. Interpreters need to see offers, accept work, and check their schedule and pay from a phone in a hospital hallway. Clients need to request services and see their invoices without emailing you for every question. If any of the three is missing, that audience's workload lands on your staff as phone calls and email — which is to say, the software has outsourced its missing features to your payroll.
Reporting you'll actually open
Finally, make sure the operational exhaust is usable: jobs by client, hours by interpreter, revenue by service type, fill rates, cancellation patterns. You don't need a data-science suite — you need reports that answer the Monday-morning questions without exporting to a spreadsheet first.
The evaluation checklist
- Double-booking is impossible, and travel buffers make near-overlaps visible.
- Recurring series survive single-instance edits, forks, and substitutions.
- Both broadcast and direct assignment exist, with real qualification filters.
- The rate engine models dual rates, time-based adjustments, rush, minimums, mileage, and per-client exceptions — and feeds invoicing directly.
- All three portals exist: admin, interpreter, client.
- Reports answer your Monday questions out of the box.
Run every vendor through the same list, using your own ugliest real-world scenarios rather than their demo script. The software that handles your worst Tuesday is the one that deserves your best years.