Financial
A first line can filter, but it cannot touch an account.
In a bank or a consumer lender most calls end at an operator, but not all of them should start there. A good share of first-line time goes on routing, on repeating the same public information, and on gathering the details the operator would have asked for anyway. That is the automatable part.
The assistant takes the call, establishes what the caller is ringing about, answers from the public information you publish, gathers the necessary details and transfers to the right queue with the context attached. It does not authenticate the caller and performs no operation on any account.
What a first line can take
The rule on this page is simple and not up for negotiation: anything touching an account, an amount or an identity goes to a person. What is left is useful, and there is a lot of it.
Intent routing
The caller says what they are ringing about and lands in the right queue, with no keypad menu.
Questions from public information
Hours, required documents, the steps of an application, published general terms. From your documents.
Taking a product enquiry
The interest, an indicative amount and the timing, as a lead, with no eligibility assessment at all.
Booking an appointment
Into the adviser calendar, from their real diary.
A lost card report
Recognised from the first words and transferred immediately, with priority and no further questions.
From the call to the right queue
The flow is deliberately short. An assistant that holds a caller for ten minutes on a bank first line has saved nothing; it has only moved the frustration earlier.
- 01 Establish intent in two sentences The caller says freely what they need. The assistant places it in your categories without asking clarifying questions indefinitely.
- 02 Check whether it is urgent Lost card, suspected fraud, blocked account. Those words short-circuit the rest of the flow and transfer at once.
- 03 Answer only from what is public A knowledge base query. When no suitable passage is found, the call receives the knowledge-insufficient event and the assistant hands over rather than improvising.
- 04 Gather what the operator would ask anyway The reason, the product, the city, the availability. Not identifying details and not account numbers.
- 05 Transfer with context To the right queue, with the call summary carried across, so the caller does not repeat everything from the start.
What is left after the call
In a financial institution the written trail is subject to requirements you set. The product produces it; where it lives and for how long is your choice.
| The routing outcome | The intent recognised and the queue it transferred to, as structured output. |
|---|---|
| The product lead | The contact and the interest in the CRM, with no eligibility assessment attached. |
| In the calendar | The adviser appointment, if that is where the call ended. |
| The recording and transcript | In your own storage, if you configure it that way, with the retention period you set. |
What it does not do for a financial institution
This is the most restrictive list on the site, and it is written before any commercial conversation rather than after one.
- It does not authenticate the caller There is no strong customer authentication in the product. It does not verify identity to the standard account operations require, and it should not be used as though it did.
- It performs no operations It moves no money, blocks no cards, changes no limits and confirms no transactions.
- It states no balances and reads no transactions It does not disclose account data over a channel that does not identify the person.
- It does not assess eligibility It does not say whether somebody qualifies for a loan, does not estimate a repayment and does no scoring.
- It is certified for nothing We hold no financial certifications, have not been through a banking client audit, and do not claim otherwise. The security page states exactly what exists and what does not.
What financial institutions ask us
Can it identify the customer from their phone number?
It can look a contact up by number, but that is not identification and must not be treated as such. A phone number is lost, lent and spoofed. For anything that depends on who the person is, the product transfers to an operator.
What do we gain if it ends up at an operator anyway?
Correct routing first time, and context gathered before the transfer. A call that reaches the right queue with the reason already noted is shorter for the operator and less frustrating for the customer. That is not nothing, but it is also not the full automation others promise.
Can it run inside our own infrastructure?
Recordings and transcripts can be written straight into your storage. The rest depends on a real architecture conversation, and the security page describes what is implemented today. We do not promise an install in your data centre without having done one.
Are you compliant with outsourcing requirements?
We have not been through that process with any institution. It is an uncomfortable answer, but it is the only one that can be verified, and a claim to the contrary would collapse at the compliance department first question.
Where to go next
Security
Isolation, roles, audit, redaction, your own storage. And an honest list of the gaps.
Operator handoff
Queue, operators, skills, transfer, and what the supervisor sees.
Integrations
25 business connectors, 18 selectable providers, eight storage destinations.
Pricing
Components at their published price, the platform on top, and what we cannot price yet.
Notes
-
1
The tools named on this page are the ones in
App\Services\Integrations\ConnectorRegistrycarryingimplemented. Anything that is only in the catalogue, without that flag, is not named here as though it worked. -
2
There is no strong caller-authentication mechanism anywhere in the product. Transfer to an operator uses the transfer modes in
App\Enums\TransferMode, and the context carried across is configured on the route.