// docs

Your Brand Voice

Your business has a voice. The way you talk to customers, the way you handle complaints, the way you quote prices, the specific vocabulary for your products. Your AI should sound like your company — not like a generic chatbot trained on the whole internet.

This page explains how I build AI systems that represent your brand, know your products, follow your rules, and communicate the way you do. Step by step, with specifics.

Why generic AI isn't enough

Open ChatGPT right now. Ask it a question about your business. What you get back will be polite, grammatically correct, and completely useless for real customer interactions.

Generic AI doesn't know:

Your product names, specs, or prices
Your return policy, warranty terms, or support procedures
Your brand voice — whether you're casual or formal, technical or plain-spoken
Who your customers are — what they care about, what language they use, what frustrates them
Your boundaries — what you can promise and what you can't

Generic AI answers like a kind stranger who's never seen your company. It says something vaguely helpful, hedges every statement, and redirects to "please contact support" at the first sign of complexity. It's a polite wall between your customer and an actual answer.

The problem grows with scale. If ten customers ask about pricing in an hour, generic AI gives ten vague non-answers. Customers learn that your "AI assistant" is a waste of time and stop using it. Then you've invested in a system nobody trusts — which hurts the brand more than deploying nothing.

A custom AI knows your prices, knows your policies, talks the way your company talks. Customers get answers to their questions.

How I build your AI's personality

Building a custom AI assistant is a structured process with concrete, repeatable steps. Here's what it looks like.

The system prompt — the foundation

Every AI assistant starts with a system prompt. Think of it as the job description you'd hand a new hire on day one. It defines:

Tone and style — "You're friendly but professional. Use the customer's first name. Write short sentences. Never use jargon unless the customer used it first."
Role and boundaries — "You're a customer support agent for [Company]. You can answer questions about products, pricing, and shipping. You cannot authorize returns over 500 PLN — escalate those to a human."
Response patterns — "When they ask about delivery time, check the current shipping status first. If the order hasn't shipped yet, give the estimated ship date, not the delivery date."
Constraints — "Never discuss competitor products. Never share internal cost data. Never promise a specific delivery date — always give ranges."

The system prompt is the single most important piece of your AI's configuration. I spend a lot of time getting it right, because everything else builds on it.

The knowledge base — your documents, indexed and ready

The AI needs to know what your company knows. I load and index your actual business documents:

Product catalogs and price lists — current prices, product specs, feature comparisons
Policies and procedures — return policy, warranty terms, escalation procedures, SLAs
FAQs and support templates — common questions with approved answers
Training materials — how your team handles specific situations
Historical data — past interactions, resolved tickets, common issues and their fixes

This isn't a one-time data dump. I structure and index these documents so the AI can find the right information quickly and accurately. When a customer asks "what's the difference between your Standard and Pro plans?", the AI pulls from your actual product-comparison document — not a made-up guess.

The knowledge base updates as your business changes. New product? Update the catalog file. Price change? Update the price list. The AI reflects the new information immediately.

Brand voice calibration

This is where most AI deployments fail. The facts are right, but the tone is wrong. Your AI sounds like a robot reciting a manual instead of your company talking to a customer.

My calibration process:

Sample collection — I look at how your company actually communicates: emails, site copy, social posts, support call transcripts, quotes, marketing materials
Pattern identification — do you use "hey" or "good morning"? Do you say "we're sorry" or "we'll fix it"? Do you explain technical concepts or keep it plain? Short paragraphs or detailed explanations?
Voice profile — a documented description of your communication style that becomes part of the system prompt
Test and refine — I generate sample replies and compare them side by side with real replies from your staff. We adjust until the AI's voice is close to your brand's voice.

The result: customers interacting with your AI get the same impression they'd get talking to a well-trained employee. Consistent, competent, on-brand.

Guardrails — what the AI never says

This is the part people forget about until something goes wrong. Without guardrails the AI will:

Promise deadlines it can't verify
Quote made-up prices
Make commitments on your company's behalf
Share internal information when someone asks cleverly
Over-apologize in a way that could legally be read as an admission of fault

I define explicit guardrails for every system:

Pricing guardrails — the AI quotes prices only from the approved price list. If a product isn't on the list, it says "let me connect you with the sales team for a quote" instead of guessing.
Commitment guardrails — the AI doesn't promise specific delivery dates, approval timelines, or outcomes. It gives ranges and estimates, clearly labeled as such.
Information guardrails — the AI doesn't share internal margins, cost structure, employee information, or competitive strategy.
Escalation guardrails — when a question exceeds the AI's scope or confidence, it routes to a human immediately. No stalling, no "let me try to figure it out."
Legal guardrails — the AI doesn't give legal, medical, or financial advice. It provides information and points to qualified professionals.

Guardrails protect your brand, your customers, and your business. Each one addresses a known failure mode.

Side by side: generic vs custom

The same scenario three times, the same customer question — first the generic AI's answer, then the one I built.

Scenario 1 — A customer asks about pricing

Generic AI:

"Pricing depends on several factors. Please contact our sales team for a detailed quote. You can reach them at sales@company.com or by phone during business hours."

Custom AI (built by me):

"Our Standard plan is 199 PLN/month and includes up to 5 user accounts, 10 GB of storage, and email support. Given your team size (you mentioned 12 people earlier), I'd actually recommend the Team plan at 149 PLN/person/month — it covers everything in Standard plus priority support, unlimited storage, and admin tools. Want me to put together a comparison of both, or connect you with Marta in sales to talk through annual pricing (there's a 15% discount)?"

The generic answer is a dead end. The custom one sells.

Scenario 2 — A customer complaint

Generic AI:

"We sincerely apologize for the inconvenience you've experienced. Your feedback is very important to us, and we'll do everything we can to resolve this issue. Please provide your order number so we can look into it."

Custom AI (built by me):

"I can see the issue, Tomek. Your order #8842 — the monitor with the cracked screen on delivery. I've logged it as case #4521 under our Priority Service policy. You qualify for a replacement because this is a shipping-damage report, and I've already started the process. You'll get a tracking number for the replacement within 24 hours, and a return label for the damaged unit in a separate email. Anything else I should flag while I have your profile open?"

The generic answer forces the customer to repeat themselves. The custom one solves the problem in one message.

Scenario 3 — An internal HR question from an employee

Generic AI:

"I don't have access to your company's specific policies. I'd recommend contacting your HR department or checking your internal company documentation portal."

Custom AI (built by me):

"Per the Q2 update (document: HR-Policy-2026-Q2, section 4.3): remote work is allowed up to 3 days a week for all full-time employees. You need manager approval through the HR portal — here's the direct link: [portal.company.com/remote-request]. The Q3 submission deadline is June 15. Note: if you're requesting more than 3 days, that needs VP approval and a separate form (section 4.5 of the same document)."

The generic answer is useless. The custom one is better than most actual HR departments.

The CLAUDE.md approach — one file defines everything

Here's something that surprises most clients: the entire behavior of your AI assistant can be defined in one human-readable configuration file. I call it the CLAUDE.md approach.

This file contains:

The system prompt (tone, role, boundaries)
Product information and pricing rules
Escalation procedures
Guardrails and constraints
Response templates for common situations
Links to knowledge base documents

This approach fits the custom install flavor especially well — where Claude Code or Codex CLI is wired directly into your stack along with its own skills, prompt system, and memory. The .claude/CLAUDE.md file and the custom skills are exactly that config. But the same configuration pattern applies to every install.

Why this approach works

Easy to update. Price change? Edit one line in the file. New product launch? Add a section. Policy update? Modify the relevant paragraph. No rebuilding the system, no redeploying, no developer needed for simple changes.

Versioned. Every change to the configuration is tracked in Git with full history. You see exactly what changed, when, and who changed it. If a new change causes problems, roll back to the previous version in seconds.

Human-readable. You don't need to be a developer to understand what your AI "knows" or how it behaves. The config file reads like a document, not like code. Your marketing team can review the tone. Your legal team can review the guardrails. Your product team can review the product information. Anyone can weigh in without technical skills.

Modular. Different sections handle different aspects of the AI's behavior. Tone is separate from products. Products from policies. Policies from escalation rules. You can update one area without touching the rest.

Testable. When you change the configuration, you can test the new behavior immediately. Clear cause and effect.

This approach means your AI system isn't a black box. It's a well-organized, documented, versioned configuration you can understand and propose changes to.

Building assistants that understand YOUR users

A common mistake when deploying AI: building an assistant to impress technical people instead of serving actual users.

If your customers are hotel managers, the AI needs to talk about:

Occupancy rates and booking channels
Housekeeping schedules and room turnover
Guest satisfaction scores and review management
Seasonal pricing strategies

Not "machine learning pipelines," "neural network architectures," or "transformer models." Nobody checking in guests cares how the AI works internally. They care that it helps fill rooms and run operations.

I tune the AI's vocabulary to the user's world. That goes beyond avoiding jargon — it means:

Using industry terminology correctly — if your users say "ADR" (Average Daily Rate), the AI says "ADR," not "average rate per room sold"
Understanding context — when a restaurant manager says "we're down two covers tonight," the AI knows that means two fewer reservations, not a shortage of physical place settings
Matching communication depth — the CEO wants a summary. The operations manager wants details. The technician wants specs. The AI adapts depending on who's asking.
Respecting the workflow — the AI doesn't suggest a complex process when the user is clearly in a hurry. It gives a quick answer first and offers the details as a follow-up.

I learn this by talking to your actual users (or your employee who knows them), reviewing real interactions, and iterating on how people actually communicate in your industry.

Iterating on real data

I don't test on demo data. I don't make up scenarios that make the AI look good. I test on real questions from your actual customers.

My testing process:

Collect real questions — from your tickets, inbox, chat logs, phone transcripts. Actual questions real people asked.
Run them through the system — I check how the AI responds to each one.
Compare to the ideal answer — what would your best employee say? How does the AI's answer measure up?
Identify gaps — where does the AI fall short? Missing information? Wrong tone? Wrong facts? Unnecessary escalation?
Refine and re-test — I adjust the system prompt, knowledge base, or guardrails and run the same questions again.
Edge cases — I deliberately test with unusual, ambiguous, or adversarial questions. "What if someone asks in another language?" "What if someone asks about a discontinued product?" "What if someone tries to get the AI to say something inappropriate?"

This repeats until the system consistently handles the real-world questions your customers actually ask. Not a curated demo set — the messy, unpredictable reality of actual interactions.

After launch the refinement continues. I monitor real interactions, identify new patterns, and adjust the system. Your customers' questions evolve. Your products change. The AI has to keep up.

Feedback loops

Once the system is live, I set up feedback channels:

Human review sampling — a random sample of AI interactions is reviewed by your team weekly. They flag problems, I address them.
User feedback buttons — where it fits, end users can flag unhelpful answers. Those flags go straight into the improvement queue.
Drift detection — over time the AI's performance can shift as your product changes or new question patterns emerge. I monitor for it and adjust proactively before it becomes a problem.

The result: your AI assistant gets better over time, not worse. It adapts to your growing business.

What you get at the end

Everything, specifically:

All configuration files — system prompts, guardrails, response templates, the complete CLAUDE.md. Yours.
The knowledge base — every document I indexed, every product description I structured, every FAQ I formatted. Yours.
The code — every line of backend, frontend, integration, and deployment configuration. Yours. On GitHub, with your account as owner.
Documentation — how the system works, how to update it, how to maintain it, how to modify it. Inside the repository.

More on code ownership and GitHub delivery: the integration guide.

You're not locked in. If you want to:

Modify the system yourself — go ahead, you have the code and documentation
Hire another developer to work on it — they'll have full context in the repository
Switch to another AI provider — the architecture is modular, the model can be swapped
Stop using my services entirely — you take everything, no catches

I build systems you own, not systems that own you. You come back because the work was good, not because you have no choice.

How to get started

Building a custom AI assistant is a project, not a product off a shelf. It takes time, collaboration, and iteration. But the result is AI that represents your business and helps your customers.

The general process — from the discovery call to handoff — is in the process documentation. Ready to start? Book a free discovery call and we'll work out together which approach fits your specific situation.

last updated: 2026-05-11