Conversational lead qualification

A conversational qualifier is useful only when it asks the same questions the bank already requires for that product. Do not design a parallel intake. Load the live application field list for the product the applicant opened, then ask those items in natural language. Residency, employment status, intended use, existing-customer status, and every other field legal and credit already approved belong in the chat. A question that is not on that list does not belong in qualification, even if it would make a richer profile.

Digital acquisition already owns this list. It is the application on the current-account, loan, or card journey, and it is usually the same object CRM and origination platforms keep for that customer. Platforms in the class of Salesforce and Temenos are often that system of record. The chat is another surface for those questions, not a second policy.

When someone arrives from a current-account campaign and types that they want to switch their salary in, the agent asks the eligibility and salary-switch items that page already shows, in the order operations expect. It does not add lending affordability probes. Extra questions look diligent in a transcript review and create a collection the bank never authorised for this flow.

Keep meaning stable when you paraphrase. If the form asks for employment status, the agent asks for employment status. Wording can be conversational. The coded outcome must still match what downstream scoring, tax residency, and disclosure expect. If the form uses a closed list, the agent maps the answer onto that list or leaves the field blank rather than inventing a new category.

Product scope is part of the same rule. The qualifier follows the journey the applicant started. A current-account start does not become a loan interview because the applicant mentioned a car. Bind the agent to the product code on the landing page, load that product's required and optional fields, and freeze the question set in the same release as the form.

Pre-fill is valid only for values the applicant gave in this conversation or already confirmed on the form. Map each accepted answer to the application field, write it once, and show the applicant what was stored. Do not keep a private chat-insights record that never reaches origination.

The same rule applies as in form pre-population from ID extraction: take data from a source the applicant provided, write it into the field, and let them see it before it travels. A line such as "I work full time and I live in the UK" can fill employment status and residency if those are the form's coded values. It cannot fill annual income, because no amount was stated.

Keep chat-sourced fields and document-sourced fields apart. If identity extraction later writes name or address, do not let the chat overwrite those values without an explicit precedence rule. The conversion screen should show provenance for each pre-filled cell: from this chat, from a document, or still empty.

Write only fields the application schema accepts. Free-text asides, such as hoping to buy a house next year, can sit in a notes attribute if the bank already has one. They must not be coerced into income, product type, or eligibility flags.

Unknowns stay blank. If the applicant declines, gives a range, or changes the subject, record the field as unanswered and continue with questions that still have answers. Do not round a range into a point value. Do not copy last year's declared income from a CRM row and treat it as this application's income.

Inventing a salary is the failure that looks helpful in a demo and fails when a customer complains. Consider an applicant who opens a current-account chat and writes that they get paid monthly, similar to last year. The agent must not write a round number into annual income because a warehouse once stored a figure, because a job title implies a band, or because the model produced a typical salary. The income field stays empty. The conversion flow asks it if the product requires it, or leaves it for a later step that is allowed to collect it.

Stopping also prevents qualifying a product the applicant did not ask for. If they opened a current-account journey, do not score a personal loan because they mentioned a car. Capture the mention only if you have a consented notes field. Stay on the account application. Cross-sell belongs in a later, explicit offer step.

If the applicant contradicts an earlier answer, freeze the field and ask them to confirm in the form. The agent does not pick the more likely version.

Warm handoff means the conversion flow opens with the fields that were actually filled, the fields that remain required, and a cite back to the chat turns that justify each filled value. The cite is a transcript pointer your audit log already stores, such as turn IDs, timestamps, or message hashes. It is not a summary paragraph the model wrote after the fact. Pass the cite as a reference the conversion page can resolve, not as pasted prose in a hidden field that nobody can audit.

The applicant should land in the application with those fields visible and editable. A quality reviewer should open the same cite and see the applicant's words, not the agent's paraphrase. If the agent mapped "I rent" to homeowner because a taxonomy defaulted, the cite will show the mismatch before the account is booked.

Attach intent, not a credit decision. Real-time pre-approval at point of intent may later consume some of the same answers. This conversation's job is qualification and a clean field write. Do not display an approval or a limit in the chat unless that journey is separately authorised.

Incomplete fields are a reason to keep the remaining form short, not a reason to guess. Onboarding abandonment prediction can flag sessions that stall on a blank required field. It does not authorise filling that field from the model.

The handoff payload should include the product identifier, a field map with provenance, the unanswered required list, and the transcript cite. Sentiment scores and high-intent labels stay out of the application object unless credit and legal already defined them.

Conversation is not identity verification. A name, date of birth, and address collected in chat do not complete KYC. Those answers may pre-fill the application so the applicant does not retype them. Verification still runs in the KYC steps the bank already operates.

Treating the chat as KYC complete is a distinct failure mode. It appears as a closing line such as claiming the applicant is verified and the account can be opened, after a friendly exchange. That sentence will be screenshotted. The correct close is that answers are saved, the application is ready, and identity and screening still follow.

Hand the same application object to agentic KYC orchestration with chat-sourced fields marked unverified. Risk can then apply risk-tiered onboarding routing on verified data, not on a transcript.

If the origination workflow cannot store a transcript cite against a pre-filled field, do not go live with unsupervised writes. Keep the chat as a guided walkthrough of the form until audit can follow each value back to the applicant's words. CRM and core origination systems remain the record. The agent is a client of those records, not a replacement for KYC, credit, or the application itself.