BotSpark: Multi-Tenant AI Chatbot SaaS with Emotional Intelligence Prompting

The Problem

Most small businesses can't afford round the clock support, so the same handful of questions sit unanswered overnight or get answered late. Existing chatbot tools either lock businesses into rigid scripted flows or hand them a generic AI that doesn't actually know their product. I wanted to own that whole layer myself, a bot that's actually trained on a business's own data and still feels like talking to that business, not a templated widget bolted onto a website.

Customers ask the same questions at all hours. Teams either hire for 24/7 coverage or customers wait. Some BotSpark customers went from 20 manual replies a day to zero.

What I Built

A platform where multiple businesses (tenants) each run their own branded AI chatbot, isolated from each other but on shared infrastructure. Each tenant gets:

• A bot trained on its own data
• Custom branding
• An embeddable website widget tenants drop into their own site to go live, no separate app for their customers to install

Live: bot-spark.tech

Architecture

• Frontend: Next.js + TypeScript
• Backend: NestJS
• Database: MongoDB
• AI layer: Multi-provider

Multi-tenancy approach

Tenants share the same MongoDB instance and the same application code, isolated by a tenant ID scoped into every query and every document, rather than spinning up a separate database per tenant. That keeps infrastructure simple to operate and cheap to scale as new tenants sign up, while every read and write path enforces the tenant boundary at the data layer instead of trusting the frontend to only ever ask for its own data.

Hybrid LLM Strategy

High-speed inference is the default because response speed matters more than anything else in a live chat, nobody wants to watch a typing indicator for three seconds. The fallback to a high-capacity model kicks in on provider errors or rate limiting, so a tenant's bot keeps answering instead of going silent if the primary provider has a bad moment. Running two providers instead of one also means BotSpark isn't fully dependent on a single vendor's uptime for every tenant on the platform.

Emotional intelligence prompting

The system prompt layer doesn't just answer the question, it reads the tone of what the customer wrote first. A frustrated or repeated message gets a calmer, more acknowledging response before the actual answer, instead of the bot just plowing ahead with information. A neutral question gets a direct, efficient answer. The goal was making the bot feel like it's actually listening rather than pattern matching keywords and firing back a script.

Hard Parts / What I Learned

Keeping prompt behavior consistent across tenants with very different brand voices was harder than expected, a system prompt tuned to sound right for one tenant's tone could sound off for another's. The fix was separating the core behavior logic (tone detection, fallback handling) from a per-tenant voice layer, so the emotional intelligence logic stays consistent while the actual personality on top of it is configurable per tenant.

Handling provider fallback gracefully was the other real challenge, the switch between providers needed to be invisible to the end customer, no dropped message, no visible delay spike, no broken conversation context. That meant carrying conversation state independently of which provider answered a given message, so a mid-conversation fallback doesn't lose the thread.

Results

Multiple tenants live on the platform, each running independently with no cross-tenant data leakage. The multi-provider fallback has kept tenant bots answering through provider-side rate limits and outages that would otherwise have taken a single-provider setup offline.

Try It / Links

• Live: bot-spark.tech
• Stack: Next.js, NestJS, TypeScript, MongoDB, AI, LLMs