Roughly 40% of a retail bank’s contact centre volume comes down to the same handful of questions. What’s my balance? Where is my card? Why was I charged this fee? How do I change my PIN? A Kore.ai virtual assistant can absorb most of that traffic, but only if you build it deliberately instead of dumping 200 intents into the bot builder and hoping the NLP engine sorts it out.
What follows is a practical walkthrough of that build, using a bank as the running example. The same steps work for insurance claims, telco billing or retail order tracking. If you want the wider context on why enterprises keep landing on this platform, our piece on how Kore.ai is rewiring the way enterprises talk to customers covers the strategy side. Here we’re getting our hands dirty.
Map the Intents Before You Touch the Builder
Open a spreadsheet before you open the platform. Write down every question the assistant should handle, then cut the list hard. For our bank, version one covers ten intents:
- Check account balance
- Report a lost or stolen card
- Freeze or unfreeze a card
- Dispute a transaction
- Reset an online banking password
- Change a card PIN
- Order a replacement card
- Request a statement
- Find a branch or ATM, including opening hours
- Talk to a human
Ten is deliberate. Every intent needs utterances, entities, a dialog flow and someone accountable for its accuracy. A bot with eighty half-finished intents frustrates users more than one with ten finished ones, and the analytics will show that within a fortnight.
Beside each intent, add two columns: what information the bot needs from the customer, and where that information comes from. Balance checks need an account identifier and a backend call. Branch lookups need a postcode. Lost card reports need card type and roughly when it went missing. That column quietly becomes your entity list.
Configure the Bot and Tune the NLP First
Create the bot in Kore.ai’s builder, pick a standard bot type rather than a small-talk bot, and set your primary language and region. Then stop. Before building a single dialog, spend twenty minutes in the NLP settings, because two of them decide how forgiving or brittle the whole assistant feels.
The first is the confidence threshold, the score below which an utterance gets treated as unrecognised. Defaults sit near 0.5. For anything touching money or cards, push it to 0.6: a fallback prompt is a far better outcome than the bot freezing the wrong card. Run thirty sample utterances through and watch which ones land close to the line.
The second is interruption handling, which controls whether someone can switch topics mid-task. Say a user is halfway through a PIN change and blurts out “actually, what’s my balance?”. On a support bot, let them. Real people do this constantly, and forcing them to finish the original task reads as obtuse.
Writing Utterances That Survive Real Users
Go for fifteen to twenty utterances per intent, written the way people actually type. Pull them from chat transcripts and call notes if you have them. “Check balance” and “view account balance” are lazy examples that teach the model almost nothing. A better set for the freeze-card intent looks like this:
- freeze my card
- my debit card got stolen, block it now
- can you lock card ending 4521
- i think someone has my credit card please stop it
- temporary block on my card until i find it
Include typos, lowercase text, missing punctuation and a couple of irritated variations. The engine generalises from these, so variety beats volume every time.
Build One Dialog Task End to End
Start with the lost card flow, because it exercises every node type you’ll reuse later. The sequence in the dialog builder runs roughly like this:
1. Intent node. Triggers on the lost card utterances you already trained.
2. Entity node. Captures card type (debit or credit) and the last four digits, the latter as a custom entity using a simple four-digit pattern. If the user hasn’t mentioned a card, prompt for it.
3. Message node. “I can freeze the card ending 4521 right now. Shall I go ahead?” Confirmation matters on anything irreversible.
4. Service node. Fires a POST request to the card management API and stores the response in a context variable such as cardStatus, so later nodes can read it.
5. Message node. Confirms success and sets expectations: a replacement arrives in five to seven working days, here’s how to track it.
6. Failure branch. If the API times out or errors, route straight to a human handoff instead of looping an apology.
That structure repeats everywhere. Intent in, entities captured, action taken, outcome confirmed, escape hatch available. If you’ve built on other platforms the logic translates almost one-for-one; our step-by-step guide to building a customer support bot in Yellow.ai uses the same intent-node and service-node pattern under different names.
Session Variables and the Details People Skip
Three things separate a demo from something that survives production. Session variables let you carry context across turns, so a user who already said “debit card” isn’t asked again two steps later. Hold and resume lets the bot step away for a slow API call and pick the thread back up. And the training tab quietly collects every utterance the bot failed to match, which is the most useful data you’ll get all month.
Connect Channels, Then Test Like You Mean It
One Kore.ai bot can deploy to many surfaces: web widget, mobile SDK, Slack, Microsoft Teams, WhatsApp Business, and voice through an IVR gateway. Configure them after the web channel is stable, not before, and check that long answers still sound natural when spoken aloud.
Testing is where most projects get lazy. Use the batch testing module: upload a file of a few hundred utterances with their expected intents and you get an accuracy score per intent within minutes. Anything under 85% needs more utterances, not more dialogs. Then walk the conversation in the simulator, deliberately typing typos, switching topics mid-task and answering questions out of order. The rigour we applied when building a working IBM watsonx Assistant in a week applies here too: script the awkward paths, not just the happy one.
Guardrails: Fallbacks, Escalation and Handoff
Design the failure paths as carefully as the happy ones. A fallback dialog should catch unmatched utterances with a helpful reframe, something like “I can help with cards, balances, PINs or branches, which one?”, rather than a flat “I didn’t understand”.
After two consecutive fallbacks, offer a human. Wire escalation into whichever system your agents already live in, Zendesk, Salesforce or ServiceNow, and pass the full transcript plus any context variables so the customer never repeats themselves. Sentiment analysis can trigger the same handoff earlier when frustration spikes. Always keep “talk to a human” as a trained intent, too. Hiding it damages trust more than it protects your containment numbers.
The First 30 Days: What to Measure and Fix
Four numbers tell you whether the assistant is working. Containment rate shows how many conversations finish without an agent. Task completion tracks whether users actually achieved what they came for, which is the honest metric. Fallback rate per intent flags where training data is thin. Escalation reasons reveal the workflows your backend simply can’t support yet.
Then set a rhythm: review unmatched utterances weekly, promote the good ones into training sets, retire intents nobody uses, and re-run batch tests after every dialog change. Most teams see containment climb noticeably between weeks four and twelve purely from that loop. The bot doesn’t get smarter on its own. Someone has to feed it.