AI development
In-product AI assistant on your own data
A retrieval assistant that answers from your help centre, PDFs, tickets, and policies — on the website, in the app, or on WhatsApp — with citations and a human fallback.
Support, operations, professional services, and any team that answers the same questions every day
This is the AI work CycloneWebz ships most often. It is not a generic chatbot widget dropped on a homepage. It is a retrieval assistant that can only speak from material you already own, placed in the channel your customers already use, with a person taking over when the system is unsure.
We write it as a capability study because the shape of the work repeats: the same ten questions burn staff time, a public model invents policy, after-hours enquiries die, and nobody can see what the bot said last Tuesday. The documents, the channel, and the brand voice change. The job does not.
The problem in detail
Most teams do not have an “AI problem”. They have a repeat-answer problem and a trust problem. Staff know the policies. The website already has a help centre. Tickets already contain the real phrasing customers use. What they lack is a system that retrieves those answers, cites them, and hands off when the question is new or sensitive.
A public model with a clever prompt will sound fluent and still be wrong on return windows, GST, eligibility, or internal process. That is worse than no bot: it trains customers to distrust the brand. Fine-tuning on a messy dump of PDFs is usually slower and less safe than retrieval over a cleaned corpus.
The other failure is placement. An assistant that lives only in a vendor dashboard is a demo. The work only counts when it sits on the site, in the iOS or Android app, or on WhatsApp — next to the same product CycloneWebz can also build and maintain.
What we usually hear
- ▸ Support and sales paste the same answers into chat, email, and WhatsApp every day.
- ▸ A theme chatbot or a vendor widget invents refund, pricing, or compliance answers.
- ▸ After-hours and weekend enquiries sit unanswered until Monday.
- ▸ Help-centre articles exist, but nobody searches them — they just open a ticket.
- ▸ There is no log of what the assistant said, so you cannot improve the corpus.
- ▸ The AI vendor is separate from the team that owns the website or the app.
What we build
A mapped question set, not a model looking for a job
We sit with support and ops and write down the ten to thirty questions that actually cost time. We match each one to the document, CMS page, or ticket thread that already answers it. If the answer is not written down, we say so before anyone talks about models.
Retrieval over your corpus
Help-centre articles, PDFs, FAQs, and approved ticket macros are chunked, stored, and retrieved. The assistant answers from those passages. It does not invent a policy that is not in the files. Citations are shown to the agent or, when you want, to the customer.
The assistant in the product
Web widget, in-app help, or WhatsApp — sometimes all three with one brain. Tone, language (English and Hindi when needed), and what the bot is allowed to do are set with you. Booking, order status, or ticket creation can be wired when the data is clean enough.
Handoff, logs, and a weekly loop
Low confidence, angry language, or a topic you marked as human-only opens a person. Every turn is logged. Each week we add missing documents, fix prompts, and retire answers that drifted. That loop is the product, not a one-off launch.
How we ship it
-
01
Use-case and data reality check
We read a sample of tickets, the live help centre, and any PDFs you treat as source of truth. We mark gaps, contradictions, and questions that must never be automated. You leave this step knowing whether retrieval is enough or whether a smaller trained model is even on the table.
-
02
Corpus, retrieval, and guardrails
We clean and version the documents. We build retrieval (RAG) with the store we agreed — often private. System prompts, topic blocks, and a human fallback are written as rules, not vibes. An eval set of real questions is scored before anything public sees the bot.
-
03
Product integration
The assistant is placed on the existing Next.js site, a new page, the mobile app, or WhatsApp Business. Auth, session, and brand chrome match the product. If the site or app is also ours, the assistant is not a sidecar iframe that breaks on the next redesign.
-
04
Staff console and launch
Agents see transcripts, citations, and a one-click take-over. You get a short runbook: how to add a document, how to block a topic, who gets the after-hours handoff. We watch the first weeks of live traffic with you and tighten the eval set.
What you leave with
- ▸ Question map and corpus inventory (what you have, what is missing)
- ▸ Retrieval pipeline over approved documents, with versioning
- ▸ Assistant UI on web, in-app, and/or WhatsApp
- ▸ Citation display and confidence-based human handoff
- ▸ Staff transcript console and export
- ▸ Eval set of real questions, scored before and after launch
- ▸ Topic block-list and brand-voice rules
- ▸ Runbook for adding documents and reviewing failed turns
Customers and staff get answers from your own material, with a citation an agent can check.
After-hours questions are either answered or handed to a person — they are not invented.
You can see every turn, improve the corpus every week, and keep the brand in control of what the system may say.
The same Gurugram studio can own the website or app around it, so the assistant does not become a second vendor’s widget.
Fit
For you if
- Support and sales teams drowning in repeat questions that already have written answers
- Service businesses that want WhatsApp or web help after hours without inventing policy
- Product teams adding a first AI feature to an existing site or app
- Operators who need a log of every answer for training and compliance
Not for you if
- A company that wants a public model trained on their private data with no retrieval and no review
- A brief that is only “add ChatGPT to the site” with no documents and no owner
- A use case that is really a full CRM rebuild dressed up as a chatbot
Questions on this work
Will our documents be used to train a public model?
Not unless you ask for that in writing. We agree the store, the vendor, and retention before production traffic. Private retrieval is the default when the corpus is sensitive. NDAs are standard.
Do you fine-tune, or is this only RAG?
Most first releases are retrieval plus a hosted model. Fine-tuning is on the table when the job needs it and the data is clean enough. We will say which, and why, after we see the corpus.
What do you need from us to start?
A sample of tickets, the live help centre or PDF pack, the channel you care about first (web, app, WhatsApp), and who will own the weekly review. That is enough for a scoped estimate.
Can this sit on a site you did not build?
Yes. We integrate with an existing website or app. If you later want the site or app rebuilt, that work stays in the same studio.
The other studies
-
IoT + apps
Live fleet and campus visibility
Device-to-cloud tracking for vehicles and campuses — ingest, maps, geofence alerts, operator web, and parent or driver apps the morning shift will actually open.
-
Ecommerce
Conversion-focused ecommerce storefront
A store that can take a sale-day spike: catalogue, search, checkout, wallets, COD, GST, and ops wired so fulfilment is a system — on Shopify, Magento, or a custom storefront.