From a month to a day: self-serve onboarding
Building the configuration platform that lets a bank set up its own voice bot, chatbot, and knowledge sources — without an implementation team.
30×
faster platform onboarding
Role
Built from scratch, sole frontend owner
Timeframe
2024 – 2025
Stack
React · TypeScript · Config Platform · REST
The problem
Onboarding a new bank or credit union onto the Interface.ai platform took more than a month. Every deployment was a hand-rolled implementation project: solutions engineers configured the voice bot, the chatbot, and the knowledge sources by hand, and every customer-specific quirk became a ticket queue.
That timeline capped how fast the company could grow. Sales could close a deal in days, and then the customer waited a month to go live.
The constraints
- The audience was bank operations staff, not developers — the product had to make conversational AI configuration approachable without dumbing it down.
- Configurations had to be safe by construction: a bank misconfiguring its own voice bot in production is a support incident at best and a compliance problem at worst.
- Greenfield build — no existing codebase, no patterns to inherit. Every architectural decision was mine to make and live with.
Decisions & trade-offs
Configuration as a guided product, not a settings page
Rather than exposing raw config, the app models onboarding as a sequence of validated, previewable steps — set up the voice bot, connect knowledge sources, test the conversation. Progress is inspectable and each step can be revisited safely.
Trade-off: Guided flows are much more design and state-management work than a form dump. The payoff is that non-technical bank staff can genuinely complete the process alone.
Validation and preview before anything goes live
Every configuration change is validated against the platform contract and previewable in a sandboxed conversation before publishing. The system treats 'publish' as a deliberate, reviewable act.
Trade-off: Building preview infrastructure took time that could have shipped more config surface area. It was the right call: trust is the entire product when a customer configures a banking bot themselves.
Owning defaults for customers we'd never meet
With 100+ tenants, most users would never talk to us. Defaults, empty states, and error recovery were designed for the customer we'd never meet — every edge case handled in the product rather than in a support channel.
Trade-off: Defensive product design front-loads work that a hands-on implementation team would otherwise absorb over months. It converts support cost into engineering cost — once.
The outcome
Platform onboarding for a new bank or credit union dropped from more than a month to about a day — roughly a 30× reduction in time-to-live.
Onboarding stopped being a bottleneck on growth. Implementation engineers moved from doing every setup by hand to handling only genuine edge cases.
Time to onboard a bank
Internal product for banking customers — no public demo. A short annotated walkthrough recording is available on request.
What I'd do differently
I'd instrument funnel analytics from the first release. We added step-level drop-off tracking later and immediately found two steps where users stalled — data we could have had months earlier.
I'd also define the configuration schema contract with the backend team more formally up front; a couple of breaking API changes mid-build cost us rework that a versioned contract would have prevented.