MORTGAGE AND LENDING
Spanish-speaking applicants stopped getting a worse experience.
A lending business whose automation was quietly serving one half of its applicants better than the other, without anyone having decided that.
The problem
What was going wrong
A meaningful share of applicants preferred Spanish, but every automated message went out in English only.
Nobody chose this. It is what happens by default when a system is built in one language and the audience turns out to speak two. The loan officer could switch to Spanish on a call, but everything automated around that call stayed English.
What I built
The system, piece by piece
Language preference captured at intake
The preference is recorded at the first point of contact, as a field on the contact record, rather than inferred later or handled case by case. Capturing it at intake is what makes everything downstream possible.
Routing that holds for the whole lifecycle
That field routes the contact into the matching sequence and keeps them there for the rest of the lifecycle. English and Spanish contacts receive the same follow-up quality without the loan officer switching anything manually.
Two full sequences, not one with swapped text
Each language path is a complete sequence in its own right rather than a single sequence substituting translated strings. That keeps the two independent: the Spanish follow-up can be reworded, retimed, or extended without touching the English one, and a change to either cannot quietly break the other.
Reasoning
Why it was built this way
Why intake is the only place this works
Adding a second language later means deciding, for every contact already in the system, which language they should have been getting. Captured at intake it is one field and a branch. Added afterwards it is a migration.
Why manual switching does not scale
Relying on the loan officer to remember means the system is only bilingual when someone is paying attention. The automated messages are precisely the ones that fire when nobody is, which is where the gap shows up.
Why a Spanish sequence is not a translated English one
Several characters Spanish depends on, among them á, í, ó and ú, fall outside GSM-7, the alphabet SMS uses by default. One of them anywhere in a message switches the whole message to UCS-2, which drops the limit from 160 characters per segment to 70. A message that went out as one segment in English can arrive as three in Spanish, costing more and sometimes splitting mid-sentence. Length has to be checked per language rather than once.
Language belongs to the contact, not the message
Holding the preference on the contact record, rather than deciding it per send, is what lets every later workflow, reminder, and re-engagement branch read the same value. Decided once at intake, everything downstream inherits it. Decided per message, every new workflow has to solve the same problem again, and eventually one of them will not.
What changed
The result
Spanish-speaking applicants receive the same follow-up as English speakers, routed automatically from the language captured at intake, with nothing for the loan officer to switch manually.
Described in terms of what the system does. No performance figures are published here, because none have been independently verified.
Next Step
Recognise any of this in your setup?
Every project starts with an audit of what you already have, sent to you in writing before any building starts.