How Immigration Firms Should Test an AI Receptionist in Every Working Language

By Michael Brunman, Co-Founder and CEO of Clerx

The direct answer

Test an immigration AI receptionist separately in every language the firm intends to use. Check whether callers understand the questions, names and dates survive the conversation accurately, fees and appointment instructions remain clear, and uncertain exchanges reach the firm's designated staff. A vendor's supported-language list does not establish that a particular workflow is ready for your clients.

For a small immigration practice, the most consequential errors may be ordinary administrative ones: the wrong callback number, an appointment understood as free when it is paid, or a time-sensitive statement missing from the summary. These can happen even when the voice sounds fluent.

This guide concerns intake operations. It does not treat an AI receptionist as a legal interpreter, attorney, or decision-maker about immigration eligibility. Begin with the broader multilingual immigration intake workflow, then test the exact interactions your office expects to handle.

Define the service in each working language

Write down the languages and regional usage your actual callers need, along with which channels and hours must support them. Avoid treating a broad label such as Spanish or Portuguese as a complete service specification.

For each language, identify the permitted tasks: greeting, broad matter classification, contact collection, explanation of consultation terms, booking, and handoff. Decide which questions must stop for review. The service can be ready for one task and unready for another.

The Clerx AI Receptionist describes multilingual inbound coverage and customized intake. Verify the specific language and configuration directly. Public language lists can change, and availability says less than a reviewed conversation about your own consultation process.

Use plain language in the source script before translating or adapting it. A complicated English instruction can remain confusing in every other language. If the firm cannot explain its own consultation policy in two clear sentences, resolve that first.

Test comprehension rather than a polished accent

A fluent-sounding voice can still collect the wrong information. Ask a qualified bilingual reviewer to evaluate whether questions mean what the firm intended, whether answers are interpreted consistently, and whether the caller receives an understandable next step.

Have the reviewer distinguish pronunciation preferences from errors that change meaning. A nonlocal accent may be acceptable if communication is clear. A smooth sentence that reverses a payment condition is a failure.

Use the general pre-launch testing guide for the basic test structure. Add a language-specific outcome for each scenario, such as "caller can accurately repeat the meeting time and fee" or "summary preserves the caller's stated concern without inventing a legal conclusion."

A small review panel is more useful than one enthusiastic internal listener. Include a reviewer familiar with your community's language usage and someone responsible for the downstream intake record.

Make names, numbers, and dates separate tests

Names may have multiple surnames, unfamiliar spellings, or sounds that are difficult over a phone connection. Test whether the workflow asks for clarification and preserves the spelling supplied by the caller rather than normalizing it without permission.

Phone numbers and email addresses deserve their own checks. Ask the system to repeat them, correct one digit, and confirm the result. If a callback number is wrong, an otherwise excellent conversation may be unusable.

Dates can be ambiguous across language conventions. Test appointment dates spoken in different formats and have the confirmation use an unambiguous month, day, year, time, and time zone where relevant. Do not treat an intake system as a calculator of legal filing deadlines.

Where a caller reports a date from a notice, label it as caller-supplied and preserve uncertainty. The attorney should review the relevant document and determine any legal timing requirement.

Include code switching and imperfect audio

Callers may move between languages, use an English agency name inside a Spanish sentence, or ask a relative to help. Test these ordinary situations rather than only a scripted conversation between fluent speakers in a quiet room.

Introduce a correction midway through the call. Pause. Ask the receptionist to repeat the last instruction. Use background noise that resembles a realistic mobile call without turning the exercise into an artificial stress contest.

Look for whether the conversation recovers. A useful receptionist can ask a concise clarifying question and preserve an unresolved point for staff. It should not fill gaps with plausible facts just to finish the script.

The intake quality scorecard can hold these findings, but score language outcomes separately. A high overall result can hide a serious weakness if almost all reviewed calls were in English.

Test consultation terms in the caller's language

Use the real appointment types, fees, duration, meeting format, and payment requirements approved by the firm. Ask the test caller to explain back what they believe will happen next. This is a comprehension check, not a test of the caller's sophistication.

Verify that "consultation" is not presented as acceptance of representation. Test questions such as "Does paying mean you have taken my case?" and "Will the lawyer tell me whether I qualify?" The response should remain within the approved administrative boundary.

Where the workflow uses the LawPay connection, check the transition to the payment step. Confirm that the caller understands who receives payment, what the fee covers, and what staff will do if payment or booking does not complete.

Do not assume that a translated confirmation is accurate because the spoken conversation passed. Review the messages as separate assets, including calendar wording and any payment-related instructions.

Follow the information into the legal software

Inspect the resulting contact, summary, and appointment. Verify that the record distinguishes what the caller said from any operational classification applied by the intake workflow. A polished English summary should not erase ambiguity in the original conversation.

If the firm already uses MyCase, test the Clerx and MyCase handoff. If it uses immigration-specific 8am DocketWise, test the DocketWise intake connection. Some firms use both. Identify the destination and responsible reviewer for each output instead of assuming every immigration practice uses one platform.

Public partner documentation describes DocketWise integrations, but that does not prove the configuration of your receptionist. Ask the implementer to demonstrate the exact field mapping and exception behavior your firm will rely on.

For website chat and SMS intake, test written comprehension separately. Spoken proficiency, spelling, message length, and a client's ability to use a booking link are different dimensions of usability.

Define an honest fallback

Decide what happens when the system cannot establish a working language, repeatedly misunderstands an answer, or receives a request to speak to a person. Specify who receives the request and what the caller is told about availability.

Use the warm-transfer workflow to test both a successful handoff and an unanswered destination. Do not describe staff as available around the clock unless the firm has actually staffed that route. Receiving an inquiry continuously and resolving every exception immediately are different services.

The ABA's AI ethics guidance reinforces lawyers' continuing responsibilities for technology use. Your review should therefore cover professional boundaries as well as conversational fluency.

Set a launch decision the team can explain

Create a short approval record for each language: approved tasks, scenarios tested, reviewer, unresolved limitations, fallback, and date. Hold launch for material errors involving identity, fees, unauthorized advice, or lost urgency information. These are proposed acceptance principles, not an industry certification.

After launch, review a limited, appropriately accessed sample from each working language. Add new scenarios when real misunderstandings appear. If a script changes, retest the affected language rather than assuming the English edit transferred correctly.

There is no universal pass percentage that makes every multilingual deployment safe. A sample with no observed errors is still a sample. Start with a manageable scope and make limitations visible to the people supervising intake.

Use a small acceptance worksheet

For each scenario, record the language, task, expected result, actual result, reviewer, and correction needed. One row might concern a corrected phone number. Another might concern the difference between an appointment request and a confirmed paid consultation. Keep the outcome concrete enough that a second reviewer can reproduce the check.

Separate serious errors from minor wording preferences. A missing digit, changed date, or promise of representation requires a different response from a greeting that sounds overly formal. The firm should decide which defects prevent launch and which can be corrected during a limited pilot.

For a fictional Texas immigration practice, the first reviewed set could cover a new Spanish-language inquiry, a returning English-speaking prospect, and a caller who switches languages while supplying a surname. That sample is a starting point, not proof of population-wide performance or a statistically reliable accuracy rate.

Retest corrections using the original scenario and one variation. If the system now handles the rehearsed wording but fails an ordinary paraphrase, the problem remains. Save the approved result so future changes can be checked against a known example rather than someone's memory of an earlier demo.

A disciplined worksheet also makes a vendor discussion easier: the team can point to the exact lost meaning, requested behavior, and downstream consequence.

Frequently asked questions

How many languages should a small firm test?

Every language it plans to offer through the workflow. Prioritize the languages used most often by real callers, but do not advertise an unreviewed intake journey merely because the underlying platform lists that language.

Is one successful Spanish call enough?

No. Test different tasks and realistic variations: names, numbers, corrections, fees, appointments, and requests for a person. A successful greeting demonstrates less than a completed and accurately recorded consultation workflow.

Who should review language quality?

Use a reviewer with sufficient proficiency to judge meaning and caller comprehension, supported by the person who owns intake operations. Legal terminology and professional boundaries should receive attorney review where relevant.

Should every accent sound local?

Clear understanding is the operational requirement. Ask community-informed reviewers about usability, but distinguish aesthetic preferences from errors that affect identity, instructions, or the next step. Record both without conflating them.

Can the AI explain immigration eligibility?

The intake workflow should not provide legal advice or decide eligibility. It can collect approved background information and arrange attorney review. Test direct requests for advice to confirm that the boundary holds in each language.

What if the caller switches languages?

Test the actual behavior before launch. Confirm whether the configured workflow can continue reliably, needs clarification, or should route to staff. Never assume that broad multilingual support guarantees seamless switching in every conversation.

Does accurate speech guarantee an accurate CRM summary?

No. Review the downstream summary and structured fields independently. Names, dates, uncertainty, and caller preferences must survive the handoff. A fluent conversation with a misleading record is still an operational failure.

What should the vendor demonstration include?

Your firm's own fictional scenarios, bilingual review, an interrupted exchange, a fee question, and an unanswered transfer. Inspect the resulting records and messages. This makes the demonstration about your clients' experience rather than a generic language showcase.

Book a demo with Clerx today.