Customer Onboarding
The simulator does not finish the sale. Once a simulation is saved, the rest of the application (confirming the customer's identity, collecting documents, signing) happens in a conversation between the customer and one of your organization's conversational flows. The onboarding is the hand-off: from the summary, the seller sends the customer to that bot, and the bot starts out already knowing who the customer is and what was simulated for them.
Three people touch this, and each one decides a different part. The operator picks the bot and the channel in the Hub. The seller types the customer's email or phone and presses a button. The author of the conversational flow decides what the bot does with the simulation it receives.
What the Hand-off Does
There are two channels, and the operator picks one for the whole organization.
| Channel | What the seller types | What happens |
|---|---|---|
| Web | The customer's email | AltScore emails the customer a short link to a web chat with the bot. The email goes out from the organization's email channel, in its branded email template if it has one. |
| The customer's phone | The customer's WhatsApp conversation with the organization's number is pointed at the bot. The seller gets a QR code to show the customer on the spot, plus the WhatsApp link. |
The web chat is the same one described in Customer Portal, and it looks the way the bot's Web Settings say. The email and WhatsApp channels are the organization's channel connectors.
The WhatsApp option suits a customer standing at the counter: they scan the code, their WhatsApp opens a chat with your number with a short greeting already typed, and the bot answers as soon as they send it. The email option suits a customer who will continue later, from wherever they read their mail.
How It Is Set Up
Everything about the hand-off is decided in the Hub, in Settings > Configuration > Seller portal, inside the Build an operation capability. The full walkthrough is in Configuring the Portal. In short:
| Setting | What it decides |
|---|---|
| Send the bot to the customer | Whether the portal offers the onboarding at all. On by default. |
| Bot that greets the customer | The bot the customer is sent to. It must be a published conversational flow of the organization. |
| How it is sent | By email, with a link (the web chat) or By WhatsApp, with a QR. |
The seller never chooses any of this. The card in the portal shows the bot and the channel as plain text, and when either one is missing it says so instead of offering a list to guess from. There is no automatic pick either: a single published bot is not sent unless the operator chose it.
With Send the bot to the customer on and Build an operation on, the Hub does not save the settings until both a bot and a channel are chosen. With Send the bot to the customer off, the operation ends at the summary: the summary shows no onboarding card, the step list in the simulator drops its Customer onboarding entry, and the Hub stops requiring a bot and a channel.
The bots the portal accepts are the organization's published flows that are not hidden, up to 50. A bot that was chosen and later unpublished, archived or hidden counts as gone, and the seller sees the message described below. The Hub's list of bots goes up to 100. In an organization with more than 50 published bots, a bot picked in the Hub may not be among the 50 the portal reads, and the seller then sees the message for a bot that is no longer published. The prequalification evaluation has a similar limit: the portal works from the 50 most recently updated evaluations, and a chosen one outside that set reads as The configured check is no longer published. (see Prequalification).
The bot is chosen as a flow, not as a version. Publishing a new version of the same bot needs no change in the Hub: the send always uses the bot's latest published version.
The channel also has to exist on the organization's account. WhatsApp needs a WhatsApp connector, and the web option needs an email connector that can send: one with its inbox set up, or one that sends through your own mail server (SMTP), which needs no inbox. That is how the link is mailed. The web chat the link opens also needs the organization's Web connector. The send does not check that one, so set it up before choosing the web option.
Sending It
The onboarding card sits on the summary, after the simulation is saved, below the contract and the simulation actions. It is headed Customer onboarding, with the title Send the onboarding to the customer and the line The bot and the channel are already set. The customer starts out already knowing who they are and what you simulated.
Under it, the card shows two read-only facts: Bot, with the name of the bot, and How they get it, with either Web chat by email or WhatsApp. Then comes a single contact field, which depends on the channel:
| Channel | Field | Placeholder | Check before sending |
|---|---|---|---|
| Web | Customer's email | customer@example.com | It has to look like an email address with no spaces: something, an at sign, and a domain with a dot followed by at least two characters, like name@example.com. Otherwise: Enter a valid customer email. |
| Customer's phone | +54 9 11 5555 5555 | It has to carry 8 to 15 digits. Only the digits count, so spaces, dashes, parentheses and a leading plus sign do not matter. Otherwise: Enter a valid phone number, with country code. |
For WhatsApp, the field carries the hint With country code, as it is on WhatsApp. That hint matters more than it looks: the WhatsApp conversation is identified by the number, so the number has to be the one the customer actually uses on WhatsApp, written in full.
The button is Send the onboarding. It stays disabled while the field is empty. The checks above only catch typos; whether the address is deliverable is up to the email provider.
The Phone Check
On WhatsApp, AltScore makes one more check before sending. The number is refused when it already belongs to another customer's conversation with your organization, because sending would take that conversation over and show this customer's simulation to someone else. The seller sees That phone is already in another customer's conversation. Check it before sending.
There is one exception: if the number is also registered as one of this customer's phones, it is not refused. The send goes ahead and the conversation is moved to the onboarding bot, but the simulation's values are not written into it, because the conversation belongs to another customer. The bot then starts without the simulation.
Numbers are compared by their digits only, so the same number written with or without spaces, dashes or a plus sign is the same number. A new number that nobody has is accepted: the customer does not need to have the phone registered beforehand.
When Sending Is Not Possible
While the card loads, it shows Loading the available bots.... Then, instead of the form, it can show why there is nothing to send. Apart from the one case noted in the first row, none of these can be fixed from the counter; each one is for the administrator, in the Hub.
| What the seller sees | What it means |
|---|---|
| No published bots on this account. Ask your administrator to publish one before sending the onboarding. | The organization has no published, visible conversational flow. The same message appears if the list of bots could not be read. That case is not a configuration problem, so before calling the administrator, have the seller reload the page. |
| Nobody has configured which bot starts the onboarding yet. Ask your administrator to pick one in the Hub. | Bot that greets the customer is empty. |
| The configured bot is no longer published. Tell your administrator to publish it again, or to configure another one. | The chosen bot was unpublished, archived or hidden after it was chosen. |
| Nobody has configured how the customer gets the onboarding yet. Ask your administrator to pick one in the Hub. | How it is sent is empty. |
| WhatsApp is not connected on this account, so the onboarding cannot go out. Tell your administrator. | The channel is WhatsApp and the organization has no WhatsApp connector. |
| Email is not connected on this account, so the onboarding cannot go out. Tell your administrator. | The channel is web and the organization has no email connector, or the connector the onboarding uses cannot send yet (its inbox is not set up). |
The first four are known before the seller types anything. The last two only show up after the first attempt to send: the card then replaces the form with the message, since every further attempt would fail the same way.
After Sending
When the send goes through, the card turns into a green confirmation that says who it went to and when, for example The chat was sent to customer@example.com. on the web channel, or The WhatsApp conversation was opened with +54 9 11 5555 5555. on WhatsApp, followed by Sent on and the date and time.
On WhatsApp, the card shows the QR code with Show the code to the customer to scan, or send them the link. and the WhatsApp link under it. The customer scans it at the counter, or the seller forwards the link. On web, the card shows the chat link that went out by email, with This is the link that was emailed to them., so the seller can open it or pass it along if the email does not arrive.
Send again reopens the form with the same contact already filled in. Sending again really sends again: a second email on web, and on WhatsApp the conversation is pointed at the bot once more, starting over.
The confirmation survives moving back and forth between the simulator's steps, so walking back to the payment plan and returning does not lose it or invite a second send. It is lost on a page reload, and also when the seller starts over: Back to start or View simulation on the summary, New consultation in the simulator or in the history, New simulation or Back to the simulator on a simulation's detail, or Pre-qualify a customer in the customer list. Pressing Send again clears it too, even if nothing is resent. It is not saved anywhere the seller can see later. See Things to Know.
When the Send Fails
If AltScore refuses the send, the card keeps the form and shows the reason under the field.
| Message | What it means |
|---|---|
| Enter the customer's email. | The web channel received no email. The card's own check usually catches this first. |
| Enter the customer's phone number. | The WhatsApp channel received no phone, or nothing in it is a number. |
| That phone is already in another customer's conversation. Check it before sending. | See The Phone Check. |
| The chosen bot is no longer published. Tell your administrator. | The bot was unpublished between loading the card and pressing the button. |
| That channel is not available. | The channel is not one AltScore can send through. |
| The web chat is not configured yet. Tell your administrator; WhatsApp does work. | The web chat address is missing on AltScore's side, so the chat link cannot be built. It is not a setting in the Hub, so the administrator should contact AltScore support. WhatsApp sends are not affected: while it is fixed, the administrator can switch How it is sent to WhatsApp in the Hub. The seller cannot switch channels from the card. |
| WhatsApp is not connected on this account, so the onboarding cannot go out. Tell your administrator. | No WhatsApp connector (see the previous section). |
| Email is not connected on this account, so the onboarding cannot go out. Tell your administrator. | No usable email connector (see the previous section). |
When AltScore rejects the request for a reason the portal has no message of its own for, the card shows AltScore's own validation message, which is in English whatever the portal's language. Any other failure shows the portal's generic error message, We could not complete the operation. Please try again. The full catalog of portal messages, with their codes, is in Errors, Warnings and Limits.
What the Bot Receives
This section is for whoever builds the bot. The bot is handed the simulation, not asked to rebuild it: it can greet the customer by their file and skip asking for what the seller already typed in Operation Data and Payment Plan. The variables have the same names on both channels.
| Variable | When | Content |
|---|---|---|
borrowerId | Always | The customer the simulation belongs to |
simulationId | Always | The saved simulation |
montoTotal | Always | The amount financed, as text |
currency | Always | The currency of the simulation |
boletoNro | Only when filled | The Operation number the seller typed |
fechaBoleto | Only when filled | The Operation date |
sucursal | Only when filled | The Branch number |
prequalificationApproved | Only when the simulation carries a prequalification | true or false, as text |
prequalificationDecision | Only when the simulation carries a prequalification and the evaluation returned a decision | The evaluation's own decision word, exactly as it returned it |
prequalificationExecutionId | Only when the simulation carries a prequalification and its run has an identifier | The identifier of the prequalification run |
Every value is text, prequalificationApproved included, so compare it against the text true, not a true/false value. Empty values are left out, never sent blank: a flow should treat a missing boletoNro as "the seller did not type one" (on WhatsApp, see the note on existing conversations in Things to Know). Two things are never sent, on purpose: the link to the prequalification report, because the bot's variables can end up where the customer reads them, and the approved limit, which the simulation does not store.
On web, the variables arrive as URL parameters
The names are the same on both channels, but they reach the bot differently. On WhatsApp they are already conversation variables when the customer writes the first message, so the flow can use them directly. On web they arrive as URL parameters of the conversation, and the flow has to read each one into a variable with a Set Variable node, using the URL param value type with the variable's name as the Query param key. A flow meant to serve both channels should do that reading at the start, so the rest of the flow works the same way on either one.
On web, the link itself carries only the customer and the simulation identifiers. The other values are filled in from the saved simulation when the customer opens the chat and the conversation starts, which is why the amount never travels in the email.
Things to Know
Nothing records the send on the simulation. AltScore keeps it in an internal audit log, but neither the portal nor the Hub shows it. That is why the Onboarding badge in the seller's history comes only from the send just made from the summary, and goes away together with the confirmation: on a page reload, or when the seller starts over (see After Sending). A seller who comes back later cannot tell from the screen that the onboarding already went out. See Saved Simulations and History.
The QR code is the organization's number, not the customer's. It opens a chat with your WhatsApp number with a greeting already typed, the same for every customer. What ties that chat to the onboarding is the phone the seller typed. If the customer scans it with a different phone, or writes from another number, they reach your number in a conversation that has neither the onboarding bot nor the simulation.
On WhatsApp, an existing conversation is taken over. If the customer already has a conversation with your number, the onboarding moves it to the onboarding bot, from the beginning, and hands it back to the bot if a human agent had it. Whatever that conversation was doing stops. The onboarding writes this simulation's values over the variables with the same names and leaves the others as they were, so a value from an earlier onboarding that this simulation does not carry, such as a boletoNro, can still be there.
On web, a remembered conversation wins. The web chat can remember the conversation in the customer's browser, one per bot, and does so by default (see Customer Portal). The simulation is loaded only when a conversation starts, so a customer who already talked to the same bot in the same browser lands back in that conversation, with the simulation it started with. For a customer who may finance more than once, have the flow end in a Close Conversation node with Restart the web conversation on close turned on.
On web, the conversation is not tied to the customer. On WhatsApp, a conversation the onboarding creates belongs to the customer from the start. If the number already had a conversation with your organization that was not tied to any customer, the onboarding takes it over but does not tie it to the customer, so there too the flow knows who the customer is only through the borrowerId value. On web it starts anonymous, like any web chat, and the flow knows who the customer is only through the borrowerId value.
The email says almost nothing, on purpose. Its text is fixed and in Spanish: a greeting, one line asking the customer to continue their application, the link, and a line telling them to ignore the email if they do not recognize it. It never mentions amounts. Its subject is fixed too: Continua tu solicitud. The organization controls how it looks, through the branded template of its email connector, but not its words. If the link shortener is unavailable, the email still goes out, carrying the full-length link.
Where the email comes from affects whether it is read. When the email connector sends from the email provider's domain instead of the organization's own verified domain, the email is more likely to land in spam. Verify the connector's custom domain, or use your own mail server, before relying on the web channel.
One number, one inbox. If the organization has more than one WhatsApp or email connector, the onboarding always goes out through the same one, and it cannot be chosen. If the connector it always uses is not ready to send, the onboarding fails even when another email connector is.
The seller cannot fix a blocked card. Apart from a bot list that failed to load, which a reload can clear, every reason the card gives for not sending points at the Hub: publishing a bot, choosing the bot or the channel, or connecting the channel. Check the card yourself after changing any of these settings, since the seller only sees the result.
Operation Data and Payment Plan
How the seller enters the operation's terms, builds and edits the payment plan, and saves the simulation, plus how rates, interest and VAT are calculated.
Saved Simulations and History
What happens to a simulation after it is saved: its printable document, its detail page and statuses, editing, discarding and reactivating, and the seller's history.