Setting up customer knowledge with OrelFlow

Explore AI customer assistant business knowledge setup with OrelFlow: customer journeys, connected records, team handoffs and practical launch steps.

By OrelFlow Editorial

A practical guide to governing source documents, testing retrieval, handling uncertain answers and launching an AI customer assistant with clear human handoff. With OrelFlow, your customer assistant starts with business knowledge your team owns and a handoff when an answer needs human judgment. This guide explains how to connect that design to your OrelFlow solution and the work your customers need to complete.

Decide what the assistant is allowed to know

An assistant should not treat a folder of files as unquestioned authority. Decide which business questions belong in scope: opening hours, service areas, eligibility rules, product descriptions, appointment preparation or an existing order process, for example. For each topic, name the system or person that can approve its answer.

Keep three categories separate:

• Approved reference knowledge: Published policies, reviewed FAQs and maintained service descriptions that the assistant may use to answer.
• Customer-specific facts: Order status, account details or booking information that require an authorized lookup, if an integration is confirmed. A general knowledge document cannot prove these facts.
• Restricted decisions: Refund exceptions, clinical or financial advice, contract interpretations and other matters requiring a qualified person or a separate approved process.

This boundary matters because a plausible answer can still be wrong for the customer's situation. Write an explicit scope statement before configuring retrieval: which topics are answerable, which require verification and which always go to a human. Involve the relevant business owner, not just the team maintaining the assistant.

Give every source an owner and an update path

Choose authoritative documents before importing anything. A public FAQ may explain a policy, but an approved internal policy record should determine its wording and effective date. If two sources disagree, the assistant needs a rule for stopping or escalating, not a way to blend them into a compromise.

A practical source register records title, owner, approval status, effective date, review date, audience, version and replacement path. Owners should identify documents that must never be exposed to customers, including internal negotiation notes or draft prices. A source without an owner or review date is a maintenance risk: nobody is accountable when it becomes stale.

Use a controlled update sequence: the owner proposes a change, an authorized reviewer approves it, the previous version is withdrawn, and the new version enters the searchable collection. Test affected questions before making the change available to customers. If the update fails, retain or restore the last approved version and route affected questions to a person. Record who approved the change and which tests were rerun.

For time-sensitive terms, such as prices or promotional eligibility, consider a shorter review interval or require live verification instead of storing a static answer. Confirm that any proposed lookup is both available and authorized before promising it.

Map inputs to an answer record

A proposed implementation can separate conversation input, retrieved evidence and the final decision. This is an architecture pattern to evaluate, not a claim that every OrelFlow deployment already works this way. The field map gives business and technical reviewers a shared specification.

Collect only information needed for the task. Define access, retention and deletion rules with the business's responsible team before storing conversation records. If WhatsApp is a proposed channel, confirm current account, messaging, consent and billing requirements against Meta's WhatsApp Cloud API documentation. That documentation describes an API; it does not establish an OrelFlow integration or approve a specific use case.

Design retrieval around evidence, not fluent wording

A knowledge-based response flow commonly has five decisions: identify the intent, retrieve candidate passages, check source eligibility, decide whether the evidence answers the question, and compose a bounded response. The assistant should identify an applicable policy and its conditions, not merely find a passage containing similar words.

Structure source material so individual passages carry enough context to stand alone. A paragraph saying “changes are allowed within 24 hours” is ambiguous without the service, timezone, exceptions and effective date. Keep those qualifiers with the rule. Avoid mixing current and superseded terms in one searchable file. Review how tables, attachments and headings are extracted; a broken table can reverse the meaning of a fee or condition.

Set a decision rule for missing or conflicting evidence. A high similarity score alone does not demonstrate that a policy applies. If the assistant cannot establish the correct location, plan or date, it should ask a focused clarification question or transfer the case. If a proposed design uses a hosted model, its deployment, authentication and regional availability must be checked for that provider; Azure's Responses API guidance describes such prerequisites for Azure, but does not establish which model or provider OrelFlow uses.

Build responses and handoffs that fail safely

Write response rules in business language. For an approved general answer, give the answer, the conditions that matter and a practical next step. For an account-specific request, state what must be verified and use an authorized process rather than inventing a status. When evidence conflicts or is absent, say so plainly; do not cite an irrelevant source to create an impression of certainty.

Define escalation triggers before launch: disputed policy terms, repeated misunderstanding, identity-sensitive changes, an upset customer, an explicit request for a person or a system outage. A handoff should include the customer's question, relevant context, evidence status, actions already attempted and the destination queue. The human should be able to correct the record and send a response without asking the customer to start again.

Also design for failure after escalation. If a queue has no owner, the conversation can disappear despite a technically successful transfer. Assign coverage hours, an overdue-work view and a fallback owner. Do not promise an immediate response unless the operating team can meet it. For an unavailable lookup, tell the customer verification is pending; never convert an API timeout into a guessed answer.

Illustrative scenario: a disputed appointment rule

Illustrative only; not an OrelFlow customer case or a deployed feature. A customer asks, “Can I move tomorrow's appointment without a fee?” The assistant finds an approved general rescheduling rule but no verified booking details. A separate draft document mentions a different fee. The correct next step is not to choose the cheaper rule or claim the customer is exempt.

The assistant could respond: “I can explain the general rescheduling policy, but I can't confirm whether a fee applies to your booking from the information available. I can send this to the appointments team for verification.” If the customer agrees and the approved workflow permits it, the handoff record might be:

`{question: "Fee for changing tomorrow's appointment", source_id: "rescheduling-policy", source_version: 4, evidence_status: "customer-specific detail missing; draft source excluded", decision: "handoff", owner_queue: "appointments", resolution_status: "pending verification"}`

The owner checks the booking in an authorized system, applies the current rule and records the final outcome. This distinction protects the customer from a fabricated exception and gives the business a traceable reason for the transfer. Whether booking-system access or a particular transfer method is available must be verified during scoping.

Test the knowledge boundary before launch

Create an evaluation set from real question types, with sensitive details removed as appropriate. Include routine FAQs, questions requiring clarification, conflicting policy versions, changed prices, customer-specific requests, unsupported claims and deliberate attempts to make the assistant ignore its instructions. Have a policy owner specify the acceptable answer or decision for each case before testing.

Review both retrieval and final behavior. Did the assistant select the current approved source? Did it retain a crucial exception? Did it decline an unsupported claim? Did it route an identity-dependent request to verification? A helpful tone cannot compensate for a wrong policy, and a correct document cannot compensate for an answer that omits its conditions.

Use explicit launch gates chosen by the business. For example, require every critical test—such as an unauthorized account disclosure or an invented fee—to produce the approved safe decision; set a separate agreed threshold for routine-answer accuracy. These are proposed acceptance rules, not reported results. Retest after source changes, prompt changes or workflow changes, and keep a small set of previously failed cases to catch regressions.

Operate the assistant as a maintained service

Assign a knowledge owner, an operations owner and an escalation owner. The knowledge owner approves source changes; operations monitors missing evidence, failed lookups and queue backlogs; the escalation owner ensures transferred conversations receive attention. A single person may hold more than one role, but each responsibility needs a named backup.

Log changes to source versions and answer rules so an incident can be reconstructed. Set a review cadence for documents, plus event-driven reviews when prices, hours, eligibility or legal terms change. Sample answers by topic and failure type, not only by the conversations that received a reply. Investigate complaints and corrections as evidence that a source, retrieval rule or handoff path may need repair.

Prepare a rollback plan: disable an affected topic, restore the last approved source version, or switch questions to human handling while the problem is investigated. Tell the team how to report a wrong answer and who can authorize a return to service. This is particularly important when a stale policy could keep producing consistent but incorrect responses.

Measure decisions, not just message volume

Define measurement terms before building a dashboard. Supported-answer rate is the share of eligible questions answered using an approved, applicable source. Escalation rate is the share routed to a person, reported by reason; a high rate may indicate safe behavior, missing knowledge or poor routing. Correction rate is the share of sampled answers requiring a policy or factual correction. Handoff completion rate is the share of transfers that reach a recorded human outcome within the team's agreed timeframe.

Track these alongside unanswered questions, source age and repeat contacts where records permit. Separate automated replies from verified resolutions. Use a consistent observation window and document missing outcomes; otherwise a transferred case may look resolved simply because the assistant stopped responding. Review metrics by topic to find actionable gaps, not to pressure the system into answering questions it cannot support.

The broader ownership of inquiries and follow-up belongs in a customer conversation growth operating model. If WhatsApp is part of the plan, map the question and escalation points within a WhatsApp customer journey rather than treating the assistant as the whole journey.

Evaluate OrelFlow against the operating requirements

Use OrelFlow's retrieval-oriented chatbot page as the starting point for a scoping discussion, not as proof of a specific configuration. Bring a sample of approved sources, excluded documents, ten representative questions, handoff destinations and required record fields to an OrelFlow demo discussion. Ask the team to show how the proposed setup would handle a stale policy, conflicting passages, an unknown account status and a failed handoff.

Confirm channel availability, model and retrieval choices, access controls, integrations, onboarding work, ongoing maintenance responsibilities and pricing with the team. OrelFlow describes setup and customization quoted by scope; the cost of preparing knowledge, operating queues and reviewing answers should also be budgeted. The OrelFlow shop can be reviewed for relevant offerings, but confirm what any listed item includes before treating it as a complete knowledge-assistant launch.

Implementation acceptance checklist

Use this as a sign-off discussion, adjusting thresholds and responsibilities to the business's risk level:

• [ ] A business owner has approved the assistant's topic scope and restricted decisions.
• [ ] Every searchable source has an owner, audience, version, effective date and review date.
• [ ] Draft, expired and customer-inappropriate material is excluded from answer retrieval.
• [ ] Sensitive data access, retention and channel requirements have responsible-team approval.
• [ ] Test questions cover current rules, exceptions, conflicts, missing evidence and customer-specific requests.
• [ ] Critical safety tests meet the agreed pass rule; routine accuracy meets a separately defined threshold.
• [ ] Each escalation trigger has a destination, coverage owner, fallback and recorded outcome.
• [ ] The team has demonstrated outage handling, source rollback and a correction process.
• [ ] Costs, integration feasibility, ownership and launch availability have been confirmed in writing.
• [ ] A review date and post-launch sampling plan have been scheduled.

FAQ

Can we upload our existing FAQ and launch immediately?

An FAQ is a useful starting inventory, not automatic approval. Check whether each answer is current, complete, written for customers and consistent with the governing policy. Add owners and effective dates, test how the assistant handles exceptions, and keep unsupported questions on a human path. Launch only the topics that pass the agreed evaluation.

Should the assistant answer every question it receives?

No. A question may require a booking lookup, identity verification, a qualified judgment or information the business has not approved for customer use. Clarification, verification and human escalation are valid outcomes. The acceptance criterion should be a correct decision about whether to answer, not simply a high automation rate.

What should we do when a policy changes after launch?

The source owner should approve a replacement, remove the superseded version from active retrieval and rerun tests for affected questions. Review recent responses if the old rule could have misled customers, then correct cases through the appropriate service process. If the updated rule cannot be verified promptly, route that topic to a person until the source and tests are ready.

Continue your implementation journey

Continue with Design a WhatsApp Customer Journey from First Question to Next Action. A practical guide to mapping WhatsApp inquiries, qualification, booking, service requests, human handoffs and opt-outs into an accountable customer journey. Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.

Continue with Measure Conversation-to-Sales Attribution with Your Own Business Data. A practical guide to connecting campaign IDs, consent, WhatsApp conversations, qualified leads, appointments and verified orders without mistaking missing or– Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.

Continue with Maintain an AI Assistant: Knowledge Reviews, Exceptions and Change Control. A practical operating model for keeping an AI customer assistant accurate: assign fact owners, review failed answers, version approved knowledge, test changes Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.

Build this journey around your business

Start your OrelFlow setup with one specific customer request. Bring the current conversation, the records the team checks and the action that should follow. Define what the assistant can answer, what a connected workflow can change and which decisions stay with your people. Your customer assistant starts with business knowledge your team owns and a handoff when an answer needs human judgment.

Use the steps in this guide as acceptance criteria for your own configuration. Walk through a successful request, missing information, an unavailable connected system and a request that needs a person. Agree how your team will measure completion and review exceptions before expanding to another customer journey.

Explore the relevant OrelFlow workflow, browse ready-to-customize templates, or plan the setup with our team. Template purchases and any separately scoped setup work should match the actual requirements of your business.

Sources and further reading

• https://developers.facebook.com/docs/whatsapp/cloud-api/overview/
• https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/responses