A chatbot that answers
from your own documentation.

AI chatbot development services for support and sales. Your assistant answers from the documents, policies and past tickets you already have. Every answer shows its source. Anything it's unsure of goes to a person instead of a guess. Built on your helpdesk.

Get a Proposal Get a Free AI Automation Review

Reply within four business hours (typical) · Human handover built in

Brands our teams have delivered for

What we do

PixelCrayons builds support and sales chatbots that answer from your own documentation, on the tools you already run. Answers show their sources. Questions it's unsure of go to a person. Safety limits and tests are in place before launch. The first pilot runs on your real documents. We work direct for brands and white-label for agencies.

Grounded in your documentationAnswers written only from your help centre, policies, manuals and past tickets, with the source linked.
Escalation to a human, by designRefunds outside policy, legal questions, angry customers and anything unclear go to your team.
Safety limits and testing before launchTests built from your real tickets run before launch, and you sign off on the scores.

Related work · SaaS · UK

B2B SaaS: from invisible to answer-engine cited.

Read the case study

Our work

See what we've built
and the results it brought.

Real projects for real clients, with results we can show.

All case studies →

2004

Established

500+

Agencies served

4,500+

Projects delivered

340%

Revenue growth · 7 months

eCommerce

+127%

Organic traffic · 5 months

SaaS

85%

Faster delivery · backlog cleared

via agency partner

Where the work happens

Answers grounded in your documentation
Sources shown on every answer
Human handover built into every assistant
Reply within four business hours (typical)
Clear IP & Ownership Terms
Evaluation before launch, logs after
Answers grounded in your documentation
Sources shown on every answer
Human handover built into every assistant
Reply within four business hours (typical)
Clear IP & Ownership Terms
Evaluation before launch, logs after

What it can really answer

The four levels of chatbot question,
from easy to hard.

Chatbot questions come in four levels, or tiers, and each costs something different to answer. Vendor demos show the easy level. It is rarely the one that decides whether your project was worth it. We use these levels to scope your chatbot before anyone writes a prompt.

01
Answerable from your documents
Assistant
“What is your refund window?”
Requires
An index of the docs you already have
No systems touched and no login to check. This is the tier in every demo, and it is useful. It is just not the hard part.
Big step up: everything below needs your systems
02
Needs this customer’s own record
Assistant
“When does my plan renew?”
Requires
A check of who the customer is, then read access to the system that holds their record
This is the big step up. The assistant must respect who is logged in. It also needs a rule for when it isn't sure who it's talking to.
03
Changes something
Assistant, on confirmation
“Cancel my renewal before it bills.”
Requires
Permission to make changes, a log of each change and a way to undo it
Every change needs the customer to confirm it, and it is logged: what changed, by whom and on whose instruction. A wrong change is worse than a bad answer. It is a support ticket with money attached.
04
Judgement, exception or an upset customer
Human
“This is the third time this has happened.”
Requires
A person, with the conversation already summarised
Handed over on purpose, not as a failure. What matters here is how much context arrives with the customer. Nobody should have to repeat themselves to a person after explaining it to a bot.

The big jump in difficulty is not between tiers three and four. It is between one and two: the moment the assistant needs to know who it is talking to.

Illustrative tiers: question examples are generic, not client data

In every build

What a chatbot build
actually includes.

Grounded in your documentation

The chatbot answers from your own help centre, policies, manuals and past tickets. It finds the relevant passages first and writes the answer only from them. This is called retrieval-augmented generation, or RAG, and our knowledge systems use it too. Every answer links its source. No source, no answer.

The foundation

Escalation to a human, by design

Set rules decide when the assistant stops, based on how sure it is. Refunds outside policy, legal questions, angry customers and anything unclear go to your team. The full conversation and the right document go with them. A chatbot that never hands over isn't confident. It's reckless.

Every build

Safety limits and testing before launch

Before any customer sees it, the assistant runs through tests built from your real tickets. We check its answers match your documents and its tone is right. We check users can't talk it out of its rules (prompt injection), and that it refuses the topics it must. You see the scores and sign off on launch. The tests run again whenever your documents change.

Before launch

On your stack, in your channels

The assistant plugs into the helpdesk, CRM and website you already run, and the channels your customers really use. You don't have to move platforms. We don't favour any one model either. We choose it on fit, cost and where your data must be stored. You can swap it later without rework.

Included

Handover, logs and ownership

Every conversation is logged, so you can see what was said, which source it used and why it handed over. At handover you get the runbook (a written guide) and admin training. Your materials remain yours. Bespoke deliverable rights, licences and handover are agreed before work starts. Your team updates the knowledge base itself, without asking us for a change.

At handover

The pilot

From your documentation
to a working assistant.

Start

Brief and a call

We sign an NDA and talk through the questions the chatbot will face and the documents it must answer from.

Once the brief is complete

Audit and itemised proposal

We review your documents and confirm the date your proposal arrives. It covers the questions in scope, the sources, the hand-over rules and the price.

Your decision

You sign off

You confirm the scope, the payment and the access we need. Nothing starts before this.

Typically 2 to 3 business days later

The team starts

We agree in writing what a correct answer looks like and what must always go to a person. Then we build the pilot on your own documents.

On the date in your proposal

First deliverable

A working pilot that answers, shows sources and hands over by your rules. Next it runs against real tickets, the helpdesk connection goes live, and it meets customers.

Inside Prism

Your engagement, week to week,
in one workspace.

Prism is the client workspace where your requests, approvals, tasks and weekly reviews live.

Where the engagement includes it, your AI build runs in a Prism workspace you log into: requests, approvals, the task list and the weekly review, with each decision and its expected result written down.

See how Prism runs an engagement

01
Requests and approvals
One queue, one owner, one due date.
02
Weekly review
Each decision recorded with its expected result.
03
Actions checked against outcome
What we did and what happened, side by side.

How we report it, in Prism

The eval scorecard,
before the pilot goes near a customer.

What you receive in month one

AI work is reported against an evaluation set built before any model is chosen. In the first month you receive the task definition with the inputs and acceptable outputs written down, the eval set of real cases with expected answers, and the scorecard showing accuracy, refusal behaviour and cost per run. The go/no-go checklist names what must hold before the pilot touches live traffic.

01Task definition: inputs, acceptable outputs, and the cases the system must decline
02Eval set: real cases with expected answers, reviewed by your team
03Scorecard: accuracy, refusal behaviour, latency and cost per run
04Go/no-go checklist: the thresholds the pilot must meet before launch
05Failure log: each wrong answer, its cause, and the fix applied

Related workB2B SaaS: from invisible to answer-engine cited.SaaS · UK · A different discipline, so it is linked here rather than presented as proof of this one.

Our other AI services

Other AI services that work with a chatbot

The part of a chatbot that finds answers is a knowledge system. The hand-over rules are workflow automation. Start where the problem is, or start at the AI page. To add chatbot developers to your own team instead, hire them by the month.

Knowledge / RAG Hire chatbot developers Workflow Automation All AI solutions

Who is accountable

The people responsible
for your work.

Leadership and how we’re built →

Parvessh Agarwal

Founder & CEO

An entrepreneur at heart. He links business analysis, strategy, clear goals and ROI to practical technology.

LinkedIn →

Saundaraya Gupta

Technical Manager

Brings technical work, client updates and project management together, so work moves smoothly from brief to launch.

LinkedIn →

Every engagement

A named coordinator and escalation contact

Know who coordinates your engagement, who owns the work and how to escalate an issue.

All engagements. Roles may be combined and vary with your engagement.

Full terms →

Before you sign

Our commitments

Each one says where it applies and links to its full terms.

Response and start times

We typically respond within four business hours. Eligible engagements can typically start within two to three business days after scope, payment and required access are confirmed.

Business hours are Monday to Friday, 9:00 am to 6:00 pm IST, excluding published company holidays. Typical expectations, not guaranteed service levels.

Full terms

Clear IP & Ownership Terms

Your materials remain yours. Bespoke deliverable rights, licences and handover are agreed before work starts.

All engagements.

Full terms

Clear Delivery & Escalation Ownership

Know who coordinates your engagement, who owns the work and how to escalate an issue.

All engagements. Roles may be combined and vary with your engagement.

Full terms

How we handle claims, credentials and your data: group credentials, dated ratings, how case figures are signed off, client permissions and data handling.

The document review

What we check first
on a chatbot project.

Before we scope a pilot, we review the questions the assistant will face and the documents it must answer from. These are the checks, in the order we run them. Each one is written into the scope.

01The questions your customers really askWe map the questions the chatbot will face. That way the pilot is built around what your customers send, not what a demo would pick.
02Whether your documents answer themWe review the help centre, policies, manuals and past tickets it must answer from. The rule is no source, no answer. A question your documents don't cover goes to a person.
03Which tier each question sits inA question your documents answer needs a searchable index. One that needs the customer's own record needs a check of who they are first. One that changes something needs permission to change it, a confirmation step and a log.
04What must always reach a personRefunds outside policy, legal questions, angry customers and anything unclear. We agree in writing what must go to a person, and which conversation and document go with it.
05What the tests will checkThe tests are built from your real tickets. They check answers match your documents and the tone is right. They also test attempts to break its rules and the topics it must refuse. You see the scores and sign off before launch.
06Where it will liveThe helpdesk, CRM, website and channels you already run. We choose the model on fit, cost and where your data must be stored, and it can be swapped later.

Each tier costs something different to answer. So the pilot is scoped to one queue and the tier its questions sit in.

Questions

Frequently
asked.

It depends on the questions it faces and the systems it touches. So every project starts with a pilot: one queue, your own documents and a working assistant. The proposal itemises the questions in scope, the connections, and the safety limits and tests included. More channels or queues are priced only after the pilot has proved its value.

It can, and no vendor can promise zero errors. Our job is to make them rare, visible and safe. The assistant answers only from your documents, shows the source and hands over to a person when unsure. Tests built from your real tickets run before launch, and every conversation is logged afterwards.

No. A chatbot clears the repeated questions: the ones your documents already answer, asked hundreds of times. Anything that needs judgement, such as exceptions, complaints and negotiations, goes back to your team with full context. What changes is where your people spend their time, and we won't put an invented percentage on it.

It answers from your help centre, policies, manuals and past tickets. Your data is used to answer your customers and nothing else. We work under NDA and on enterprise API terms where providers don't train on your data. We can work inside your own cloud if needed. Before work starts, we agree how long data is kept, where it is stored and who can access it. Deliverable rights, licences and handover are agreed before work starts too.

The ones you already run. We connect it to your helpdesk, CRM, website and the messaging channels your customers use. We choose the model on fit, cost and where your data must be stored, and you can swap it without rework. If an off-the-shelf tool would serve you better than a custom chatbot, discovery ends with us saying so in writing.

Yes, with the same care. A sales assistant answers product and pricing questions from your documents. It checks visitors are a good fit with questions you approve, then books meetings or passes hot leads to a person. It won't make up discounts, invent competitor comparisons or promise features that don't exist. Its limits apply to sales as strictly as to support.

The range

What it costs,
at the direct rate.

Priced as a build for one support queue, answering from your own documents. A monthly support retainer keeps its answers accurate as your documents change.

ProjectChatbot build$625–$10Kfixed quote, one-time
RetainerMonthly tuning and hosting support$250–$1,250per month

Indicative: every figure is refined into an itemised proposal.INR figures shown excl. GST.

Cost guideHow much does an AI chatbot cost in 2026?The options, the drivers and the range →Rate cardAI chatbots beside every other serviceDirect rate, in ₹ and $ →

Practitioner notes
on this work.

All articles

29 August 2026 · 5 min read

AI agent vs automation vs a chatbot: the questions we ask before building an agent

A chatbot answers, an automation follows a path drawn in advance, and an agent chooses its own next step.

25 August 2026 · 5 min read

Why governed delivery says no to some AI automation, and where the approval step goes

Most AI automation requests are good ideas. Some tasks should not run unsupervised however capable the model is. How governed delivery tells the two apart.

Put a grounded chatbot
on your busiest queue.

Scope a pilot: one queue, your own documentation, a working assistant with sources shown, escalation built in, and guardrails tested before a customer ever sees it. Tell us which tier your questions sit in; the pilot is scoped to that tier.

Get a Proposal Get a Free AI Automation Review

Reply within four business hours (typical) · NDA standard · Clear IP & Ownership Terms

Last updated 26 October 2026

A chatbot that answersfrom your own documentation.

See what we've builtand the results it brought.

The four levels of chatbot question,from easy to hard.

Answerable from your documents

Needs this customer’s own record

Changes something

Judgement, exception or an upset customer

What a chatbot buildactually includes.

Grounded in your documentation

Escalation to a human, by design

Safety limits and testing before launch

On your stack, in your channels

Handover, logs and ownership

From your documentationto a working assistant.

Brief and a call

Audit and itemised proposal

You sign off

The team starts

First deliverable

Your engagement, week to week,in one workspace.

Requests and approvals

Weekly review

Actions checked against outcome

The eval scorecard,before the pilot goes near a customer.

Other AI services that work with a chatbot

The people responsiblefor your work.

Parvessh Agarwal

Saundaraya Gupta

A named coordinator and escalation contact

Our commitments

Response and start times

Clear IP & Ownership Terms

Clear Delivery & Escalation Ownership

How do we know the work will be good?

Who owns the ad accounts, the data and the work?

What if we want to stop?

How will we know what you are doing?

What we check firston a chatbot project.

Frequentlyasked.

What it costs,at the direct rate.

Practitioner noteson this work.

AI agent vs automation vs a chatbot: the questions we ask before building an agent

Why governed delivery says no to some AI automation, and where the approval step goes

Put a grounded chatboton your busiest queue.

A chatbot that answers
from your own documentation.

See what we've built
and the results it brought.

The four levels of chatbot question,
from easy to hard.

What a chatbot build
actually includes.

From your documentation
to a working assistant.

Your engagement, week to week,
in one workspace.

The eval scorecard,
before the pilot goes near a customer.

The people responsible
for your work.

What we check first
on a chatbot project.

Frequently
asked.

What it costs,
at the direct rate.

Practitioner notes
on this work.

Put a grounded chatbot
on your busiest queue.