kakinang INSIGHTS · 2026-09-22
Setting up a brand AI assistant for the first time: what information do you need?
The most useful preparation for a brand AI List the facts needed for my first brand AI assistant assistant is not ornate prompt wording. It is public information the owner can stand behind and keep current.
Prepare a fact sheet and five real questions
Write the formal brand name, site, main service, audience, area, opening and reply hours, and public contact. For each offer record what is included, excluded, current, and last checked; mark variable prices for individual confirmation. Take five questions in customers' own words from email, messages, or in-person discussions. Without a history, draft plausible first-visit questions and replace them from actual inquiries later. For high-impact medical, legal, or financial questions, explain an approved service route and ask a qualified person rather than guessing a conclusion.
Separate public knowledge from internal material. Approved FAQ, site copy, and service descriptions can ground an answer. Unpublished contracts, private phone numbers, customer data, and future prices must not be treated as public answers. Make a clean public copy before importing a PDF; do not assume automatic personal-data masking inside file text. If the site still describes an older package, correct it or mark the effective version before syncing contradictory facts.
A first-version fact sheet can use one row per publishable claim: question, approved answer, source, owner, last checked date, and cases requiring a person. A weekday-only service must not also claim round-the-clock availability. A starting price should name the variables that change a quote rather than inventing a final amount. Use an official site the business maintains. Review third-party copy for stale packages or another company's facts. Feeding a large disordered folder into an assistant can make it choose between contradictory policies; a smaller verified source is often a better beginning. Write actionable handoff triggers rather than 'ask a human when needed.' Special discounts, individual allergens, urgent slots, signatures, complaints, and refunds can each require a named owner and a summary of what the visitor already said. Accept email as a reply route if a phone is unnecessary. A visitor seeking public information should not be forced into a lead. If multiple employees are involved, assign categories and review times so 'passed to the team' corresponds to a real person.
Preview changes and permissions before applying
After login, kakinang onboarding can use a brand website, reply mailbox, and chosen options to preview changes such as a draft Soul role, knowledge source, notifications, and quota risks. A preview is a plan, not an active public assistant. An authorized administrator reviews the diff, checks the website URL and inbox, confirms, applies, and inspects the operation status. Missing facts, unavailable features, or insufficient quota need resolution first. Applying for the product itself still involves team review and contact; the console wizard is not instant self-service enrollment for any visitor.
Soul can shape voice, audience, and response length, but cannot override permissions, information boundaries, or formal transaction confirmation. A first version needs three rules: use approved facts for policy answers, acknowledge uncertainty and collect only needed context, and leave price exceptions, dates, and formal bookings to a person or confirmation flow. Ask two colleagues to read the preview for wording that could sound like an order or payment was already accepted.
At preview, ask what each change does. Does a new role's voice fit the brand? Is the site URL correct and limited to public pages? Does the notification address reach someone who actually reads it? If a feature is unavailable, decide to omit it or revisit the plan rather than writing copy that pretends it is active. Estimate actual inquiry volume when a quota risk appears. After applying, wait for a clear operation status and test the public entry; pressing Apply is not proof that every resource is ready. A sound Soul direction is 'answer service scope concisely and ask a person to confirm uncertain dates.' A harmful one is 'always answer and close the sale even without facts.' Warmth does not remove the boundary between describing an offer and accepting a transaction. Booking, order, or payment states require the granted formal flow and explicit confirmation. Without that feature, an assistant can only collect a brief and explain the human next action. Test those limits with negative cases instead of trusting a generic caution sentence.
Test positive and negative cases, then maintain
Try opening hours, service exclusions, a custom request requiring a brief, and a question beyond the knowledge. A dessert-shop visitor asking for an eight-inch cake Saturday may receive the published lead time and pickup method, but not an unverified Saturday slot. An allergen question without verified ingredients should be sent to the owner, not answered by guesswork. An address question should get an address without forcing a phone number. Check answer accuracy, honest uncertainty, and the context handed to a person.
Name an update owner and sample real questions each week. Turn repeated gaps into approved public FAQ. When policy changes, update its source and test again; a failed site sync means new facts may not be active, so check the success time and error. Track clear answers, useful handoffs, and errors rather than claiming quality or return on investment from chat count alone. English research supports general methods; the business remains responsible for its actual terms.
A roughly twenty-question acceptance sheet is more repeatable than random chat: five direct FAQ items, five paraphrases, five out-of-scope requests, and five prompts that might induce an unsupported promise. Ask equivalent questions in several languages or everyday phrases and check facts before tone. Record the expected answer, actual result, and repair owner. If 'inquire about availability' becomes 'booked,' inspect the source and role guidance before changing the flow. Do not rewrite every source weekly. Name high-change facts such as rates, opening hours, staff schedules, stock, and collaboration conditions, and assign same-day updates when they change. Review steadier brand facts less often. For recurring unanswered questions, let the owner write a publishable verified answer before adding it to knowledge; a one-customer exception is not general policy. High-stakes health, financial, or legal claims need appropriate professional review. The result is a repeatable operating process rather than prompt magic.
Questions teams ask
Can I start without a website?
Prepare public service text and FAQ; website syncing needs a valid source URL.
Can a detailed Soul replace a knowledge base?
No. Soul shapes role and tone; changing service facts need maintained approved sources.
What if AI does not know?
Say so, collect the minimum context, and use the configured human route.
Is a preview immediately active?
No. An authorized person confirms, applies, and checks the status and feature gates.
Sources and further reading
- Self Customer Service: What It Is and How It Works — Shopify
- AI Risk Management Framework — NIST
- Creating Helpful, Reliable, People-First Content — Google Search Central