Case Study · Web Development

Scaliam

Technoblick's own RAG-based support SaaS, built and operated in-house, with multi-tenant isolation enforced at the database layer and a confidence threshold that decides when the AI should hand off to a human instead of guessing.

ClientOurselves

IndustryAI / SaaS

ServicesProduct Design, AI Engineering, DevOps

StatusLive in production

Scaliam RAG support widget and client dashboard interface

Overview

Every agency says it understands the products it builds. Very few carry the pager for one, so we built Scaliam and operate it ourselves.

Scaliam started from a pattern we kept meeting in client conversations, businesses drowning in the same handful of questions, pricing, availability, process, policies, all of which their websites already answered. What most of them had seen were bots that either read from a rigid script or invented answers confidently enough to embarrass the business in front of a customer. We decided not to solve that repeatedly as a bespoke build for each client. We built the product ourselves, which meant owning every consequence, the hosting bill, the failure modes, the churn, the support ticket at 11 PM. Everything in this case study is a lesson we paid for.

Challenge

Retrieval-augmented generation is easy to demo and hard to run. Answers have to be grounded, and silence has to be an option, an AI that answers 100% of questions is a liability, not a feature, the hard part of a support bot is recognizing the boundary of what it actually knows and stopping there. Multi-tenancy cannot leak, a retrieval query for one client has to be structurally incapable of surfacing another client's material, not merely unlikely to. Knowledge also goes stale silently, a site changes its pricing and the bot keeps quoting last month's number unless freshness is built into the architecture itself. And cost per conversation has to make sense, embeddings, retrieval and generation all cost money on every message, and a design that's elegant but unprofitable dies quietly, with the business itself paying for that mistake.

Approach

The boundary of knowledge was treated as the primary design object, with answering treated as the easier part that follows. Content is crawled, cleaned and chunked on ingestion, with chunk boundaries handled carefully since a chunk that splits a pricing table in half produces a confident half-answer, each chunk embedded and stored as a vector alongside its source so every answer can be traced back to the exact material it came from. Incoming questions are matched semantically against that tenant's vectors, which is what lets how much do you charge find a page titled Our Pricing in a way keyword search never could. The model receives only the retrieved chunks and an instruction set that forbids going beyond them, and if the retrieved material doesn't contain the answer, the correct output is a handover, not a graceful guess. That handover is engineered deliberately, retrieval confidence is scored, and below the threshold the conversation routes to a human with full context attached, built as a designed exit rather than a hope that the model behaves.

Result

Scaliam runs at a 95% answer success rate in production, with the remaining 5% reaching a human by design, not by failure. It's live and operated entirely in-house, uptime, billing and roadmap all carried by the same team that built it. Specific figures for active workspaces and conversation volume are available on request.

Scaliam ingestion pipeline and knowledge base preview

Inside the Admin Panel

Variant Control

Size & colour combinations tracked at the data layer.

Live Stock

Inventory levels update in real time across the catalogue.

Order Flow

Status transitions trigger automatic customer notifications.

Promotions

Promo codes created, applied, and retired without a developer.

Overview

Challenge

Approach

Result

Inside the Admin Panel

Explore Other Case Studies

QrVertex

Intertricks

Hoshna Realty