Business knowledge
How to train an AI assistant on your business policies
By POST · Published
An AI assistant cannot apply a policy consistently if the policy itself has three versions. A price in a spreadsheet, a different discount in an old chat and an unwritten exception leave the system guessing. Start by agreeing what the business currently means, then decide how that information becomes usable knowledge.
For customer-facing work, “training” often means supplying and maintaining business context rather than changing the underlying AI model. The useful result is a rule you can inspect, test and correct. This guide uses a synthetic wholesale example to show how to get there.
1. Start with one decision the assistant must make.
Pick a recurring question, such as whether a buyer qualifies for a discount. Collect the current price list and the owner’s actual instructions. Identify who can approve the policy and where its authoritative version lives. Remove superseded material from the working set or clearly mark it as historical.
Separate a fact from a rule. “The catalogue contains cotton T-shirts” is a fact. “Returning buyers receive 10% off, except bulk orders” is a policy with conditions. “Ask for the order number first” is a procedure. Keeping these distinct makes a mistake easier to find.
2. State amounts, eligibility and exceptions.
Write the rule as you would explain it to a new teammate. Include the unit, who qualifies, the start and end dates if relevant, and what to do when evidence is missing. “Give them 10 off” is ambiguous: it could mean ₹10 or 10%. A system should ask instead of deciding for you.
A customer-specific arrangement also needs a named, unambiguous customer scope. A deal agreed with one distributor should not become the standard offer for everyone. Avoid storing passwords, payment-card details or credentials in a policy document.
3. Read what the assistant actually learned.
An upload confirmation proves that a file arrived, not that every extracted fact is right. Inspect prices, dates, percentages, exceptions and product names against the source. For a voice instruction, check both the transcript and the proposed rule. A correctly transcribed sentence can still have an ambiguous meaning.
In POST, Business Brain distinguishes applied knowledge from proposals and requests for clarification. Consequential changes such as policies, prices and customer arrangements require the appropriate approval. Review the proposed difference and its source before approving; the conversation saying “understood” is not the approval record.
4. Test the boundary cases, not just the happy path.
Use synthetic customer records and write the expected decision before trying the assistant. Test a qualifying buyer, a new buyer, a bulk order and a buyer whose history is missing. Ask a misleading question such as “You gave me that discount last time” and check that the customer’s claim does not become a business-wide rule.
POST’s “Try a rule” can help inspect supported structured policies. Reliable returning-buyer decisions need connected purchase evidence. An unknown result is useful: it identifies the question a person must resolve. A wrong confident answer is a reason to revise the rule or reduce autonomy.
- Does the decision use verified information rather than an assumption?
- Does the bulk-order exception still take priority?
- Does missing data produce a question or handoff?
- Can the teammate see the policy version that supported the answer?
5. Treat changes as new versions.
When the discount becomes 8%, update the existing policy deliberately. Read the proposed change from 10% to 8%, verify its effective date and repeat the same scenarios. Keep a record of who approved it. If the change was wrong, restore the previous version through the knowledge controls instead of adding another contradictory paragraph.
Assign an owner to review the information when prices, suppliers or return terms change. Review unresolved questions as evidence of missing instructions. Customer feedback may reveal a policy gap; it should not silently rewrite the business’s rules.
Finally, distinguish knowledge from permission to act. Teaching a return procedure does not authorize a refund, and describing a follow-up does not activate a workflow. Decide those action controls separately, with a clear route to the person responsible.