Keep AI Answers Current When Hours and Prices Change
Use a knowledge source checklist to update hours, prices and policies, retire stale copies and retest AI answers before customers rely on them.
Changing your opening hours on the website does not finish the job if an old brochure still tells customers something different. The same problem appears when a service price changes, a booking link moves or a seasonal policy expires. Your team knows the update, but the AI front desk may still have conflicting material to work from.
A useful AI chatbot knowledge source checklist follows the change all the way from the business decision to the customer answer. It identifies the responsible owner, the approved wording, the sources that must change and the questions that prove the update worked. It also records what should happen when the answer is not yet approved.
This guide provides a practical change register and a retest method for small teams. It is a maintenance process you run, not a claim that sources synchronize themselves. The examples are fictional operating scenarios. Use your actual approved facts in place of the sample hours and policies, and keep private customer information out of the source library.
What a Knowledge Source Checklist Should Control
A source checklist controls which business information an AI front desk may use, who owns that information and when it must be reviewed. A folder containing every document the business has ever produced is not the same thing as an approved knowledge base.
The central unit is a claim, not a file. “Our service desk is open on Saturday” might appear on a contact page, in a PDF welcome pack and in a seasonal landing page. Updating only the contact page leaves the underlying claim unresolved. Track the claim across its copies so the answer does not depend on which wording happens to be retrieved.
Separate stable facts from changing conditions. A published address may remain useful for a long time. A temporary closure needs an effective period. A price guide may describe a starting scope but not authorize a final quotation. A customer's appointment status belongs to a transaction system, not a general knowledge document. The knowledge-base guide covers source structure; this checklist addresses what happens after those sources begin changing.
For a small business, a shared document can be enough. It needs an owner, an update record and evidence that the relevant answers were checked. It does not need elaborate terminology or a new committee. The person who can approve an exception should not be confused with the person who uploads a replacement PDF.
Hyperleap AI can ground replies in attached documents and website content. That does not establish automatic synchronization with every place your business keeps information. Treat a website edit, an uploaded replacement and an answer retest as separate activities unless you have directly verified otherwise for your configuration. The knowledge-base front desk is the answering surface; your business remains responsible for the truth and scope of its sources.
A newer file is not automatically the authority
An upload date tells you when a file arrived. It does not prove that the owner approved its policy, that its effective date has begun or that older conflicting copies were retired.
Where Ordinary Updates Become Customer Problems
The team updates the obvious page only
Customers do not necessarily arrive through the page the owner edited. A promotion, help article or attached guide may repeat the old fact. List the places where the claim appears before changing anything. Otherwise a polished new homepage can coexist with an old cancellation rule in a source document.
Future decisions are written as present facts
An owner may approve new hours before they take effect. If the source says only “our hours are changing,” the answering rule is incomplete. State the effective date and the current rule separately. Test questions about today, the transition day and a later visit. This is a content decision, not something to leave to the model's guess about what “soon” means.
Exceptions quietly become general policy
A team member may make an exception for a particular customer. That conversation should not become the source for a public promise. Mark the difference between a published rule and a decision that requires review. Do not upload private correspondence simply because it contains a helpful explanation.
A successful upload is mistaken for a successful answer
The replacement file can be present while the response still uses the wrong scope, location or qualification. An answer test checks what the customer actually receives. A source inspection checks what the system was given. Both matter, and neither substitutes for the other.

7 Checks for Every Source Change
1. Name the customer-facing claim that changed
Write the change in a sentence that a customer could understand. “Saturday enquiries now go to the main reception team” is clearer than “update operations content.” The sentence should identify the service or location involved and the boundary of the change.
Then record what did not change. If reception hours changed but the service timetable did not, keep those facts separate. A customer asking when they can call is asking a different question from someone asking when work can be performed. Combining both into a general “hours” field makes review harder.
Use this small claim record:
| Field | Illustrative entry |
|---|---|
| Claim | Main reception opening hours |
| Scope | General enquiries for the central location |
| Change | Saturday enquiries use the weekday contact route |
| Not changed | Existing appointment arrangements |
| Approver | Operations owner |
Avoid storing a vague instruction such as “use the latest hours.” That transfers the difficult decision to the answering system. Identify the approved source by title or location and explain which claim it governs. The reviewer should be able to find the rule without reconstructing an internal conversation.
2. Find every approved source that repeats the fact
Search the attached source set for the old wording and likely variations. A cancellation policy may appear under “changes,” “refunds” or “booking conditions.” A price may be shown as a package name rather than a number. Search by meaning as well as the obvious phrase.
Create a source inventory with an action for each copy. Keep, replace, retire and investigate are more useful than a single checkbox saying “reviewed.” A retired source should no longer be part of the approved answering set. Keeping it in a private business archive is a separate records decision.
| Source | Role | Action | Reason |
|---|---|---|---|
| Contact page | Public hours reference | Replace | Changed reception coverage |
| Welcome guide | Repeats contact details | Replace | Old wording still present |
| Event brochure | Historic promotion | Retire from answering set | Not current policy |
| Staff draft | Unapproved proposal | Do not attach | Decision not signed off |
Do not assume a search found everything. Ask the person who handles customer questions where they usually look for the answer. Their operational knowledge often identifies the overlooked attachment. This is also a good moment to remove duplicated explanations that no longer need to exist in several places.
3. Assign approval and maintenance separately
The policy owner decides what the business is promising. The maintainer updates the sources and configuration. The reviewer checks the resulting answer. One person may hold several roles in a small team, but the record should still distinguish the decisions.
For example, an owner approves a changed service area. An administrator replaces the public coverage document. A colleague then asks about an address inside the area, one outside it and a location that is ambiguous. A successful upload is evidence of maintenance; the owner approval and answer tests are different evidence.
Write a fallback owner for absences. If nobody can approve a disputed price, the safe operational next step is a quotation request, not an inferred figure. A short holding answer can say that the team needs to confirm the current price for the requested scope. It should not imply that a particular person has already reviewed the enquiry.
This separation helps when an update fails. The maintainer should not have to invent policy to resolve a contradictory brochure, and the policy owner should not need to understand every technical detail before approving a plain-language rule. Use the implementation checklist for broader responsibilities around launch.
4. Write the effective rule and its exceptions
A good source explains when the rule applies, not merely what the rule says. Include the location, service, effective period and any approved exception path. Use explicit dates where a temporary arrangement would otherwise become ambiguous.
Compare these fictional versions:
Weak source: “Holiday hours apply. Contact us if needed.”
Clearer source: “During the published holiday closure, general enquiries use the contact form. Existing appointment holders should follow the instructions in their confirmation. The front desk must not promise that a new appointment is available.”
The second version separates general enquiries from existing arrangements and defines an answer boundary. Your real source still needs the business's approved dates and contact destination. Do not copy the example as if it were your policy.
For prices, identify whether the number is a starting price, a published fixed package or an individually approved quotation. Keep inclusions and exclusions alongside it. A figure without scope is not a complete answer. For service areas, distinguish ordinary coverage from exceptions requiring review. For booking links, state what the linked page lets the customer do without claiming the conversation completed the booking.

5. Update the answering set and remove contradictions
Make the approved change in the sources your front desk actually uses. Replacing a file on a shared drive does not prove that an attached copy changed. Editing the website does not prove that every existing imported source now contains the new wording. Verify the relevant source in the configured answering set.
Keep a short record of what was replaced and what was removed from use. Do not record secret URLs, customer identifiers or credentials in a public editorial checklist. A human-readable source title and internal reference are usually enough for your team's review.
If two approved sources disagree, stop using the disputed statement until the owner resolves it. Adding another paragraph that says “follow the current policy” leaves the conflict intact. Choose one governing statement, update the dependent copies and use a bounded answer while the work is incomplete.
For a home-services front desk, that bounded answer might invite a scope review instead of promising a price. For a hotel front desk, it might direct a booking-specific question to the property team instead of applying a general policy to an individual reservation. The useful behavior is preserving uncertainty, not concealing it behind fluent wording.
6. Retest the changed answer and its neighbors
Test more than the exact sentence the owner wrote. Ask the customer question plainly, ask a variation and ask a nearby question that should not have changed. The last check catches accidental expansion of the new rule.
For a fictional reception-hours change, the test pack could be:
| Prompt | Expected behavior |
|---|---|
| “Can I call the office on Saturday?” | State the approved reception rule |
| “Are you available this weekend?” | Clarify whether the customer means reception or a service appointment |
| “Does this change my existing booking?” | Avoid changing an individual arrangement; point to the appropriate team |
| “Your old brochure says something else.” | Acknowledge the conflict and use the approved source or review path |
| “Can you make an exception?” | Explain the request route without granting the exception |
Record the answer you observed, not just “passed.” In Hyperleap AI, source citations in conversation logs can help you inspect which attached material an answer drew on. They are an audit aid for your team, not a promise that customers see citations in the chat. A cited source can still be outdated, so check its content and authority.
7. Close the change with evidence and a review trigger
Close the record only when the approved sources and tested answers agree within the intended scope. Include the reviewer, the test reference and any unresolved question. “Published” is too broad if the old booking link still appears in another approved document.
Define what reopens the record. A supplier change, new location, changed price, broken destination or recurring customer question may all be triggers. A review date can be useful, but it should not be the only way a known problem gets attention.
Use a status that tells the next person what is safe: awaiting owner decision, source updated, retest needed or approved for use. These are suggested labels for your team's register, not native workflow states promised inside Hyperleap AI.
Keep the last approved answer available to the reviewer, alongside the changed answer, so they can see the difference. Do not blindly restore an old source if the new answer fails; the old policy may now be wrong too. Choose a temporary bounded response and have the owner decide the repair. The human-handoff guide explains how to keep that next step understandable to customers.
Give your front desk an approved source set
Use Hyperleap AI to answer from your business information while your team owns policy changes and exceptions.
Start for freeA Change Register You Can Actually Review
Keep the working register short enough that the person approving a change will use it. The following example is an editorial worksheet, not a product screenshot or a claim of built-in approval automation.
| Record field | What to write |
|---|---|
| Customer question | The enquiry affected by the change |
| Governing claim | The specific fact or policy being updated |
| Business owner | Who can approve the wording |
| Effective scope | Location, service and relevant period |
| Source actions | Which copies were replaced or retired |
| Prohibited inference | What the answer must not imply |
| Test evidence | Conversation references and observed outcomes |
| Open issue | Any remaining uncertainty and responsible person |
| Next trigger | What would require another review |
Imagine a price guide changes from an old package to a scope-based quotation process. The important result is not that the AI mentions a newer document. It is that it stops quoting the old package as the current offer, explains what information the team needs and does not present an enquiry as an accepted job.
Review both successful and unsuccessful questions. If a customer asks for something your source does not cover, a useful answer can explain that limit and offer the correct human path. Do not count every handoff as a knowledge failure. Some decisions deliberately belong to the business owner.
To judge whether maintenance is helping, record recurring corrections, repeat enquiries caused by stale facts and the time staff spend locating the right source. Compare like-for-like periods using your own records. There is no universal savings figure in this worksheet, and an approved source set does not establish perfect accuracy. The benefit you are looking for is a clearer, inspectable chain from business decision to customer answer.

Put the Checklist Into Your Normal Update Routine
Start with the facts that generate the most interruptions: hours, location, service scope, price explanations and booking destinations. Do not begin by cataloguing every historical document the business owns. Identify the approved answering set and the claims customers use to make decisions.
Choose an update owner and an independent reviewer where your staffing allows it. Give each a concrete job. The owner resolves the policy; the reviewer asks realistic questions without being coached toward the preferred answer. If the same person must do both, separate the activities and keep the observed answer in the record.
Attach the checklist to the moment the business changes a fact. When a service price is approved, the task is not merely “update pricing page.” It includes finding repeated copies, checking the source set and retesting the affected conversation. When a seasonal arrangement ends, removal from the source set should be part of closing the campaign.
Hyperleap AI's quick-start path can get a front desk live in under five minutes by reading a website and generating a starting configuration. Detailed source approval and ongoing retesting are tuning and operating work afterwards. They are not a reason to describe a simple setup as a long implementation project, and a quick setup is not a reason to skip them.
If your team cannot resolve a source conflict immediately, narrow the answer temporarily. Use a review request for the disputed detail while continuing to answer unaffected general questions. Explain the limit in plain language. “The team needs to confirm the current price for that scope” is more useful than an apologetic paragraph that leaves the customer unsure what happens next.
Finally, give the receiving team a usable record when a question is routed. The lead-summary guide explains how an unresolved question and a clear next action can travel with the enquiry. A good maintenance process reduces avoidable interruptions without hiding the cases that genuinely need a person.
Frequently Asked Questions
Does changing my website automatically update every AI source?
Do not assume so. Check how your configured source was imported and whether its current content includes the change. An attached document, a website page and an answer test are separate things to verify. Retest the customer question after updating the source rather than relying only on an upload or crawl status.
Should I keep old brochures attached for reference?
Keep historical material out of the approved answering set when it conflicts with current policy. Your business may retain an archive separately, according to its own records process. If a historical document must remain relevant, label its period and scope clearly and test that the agent does not present it as today's offer.
Who should approve a changed price or policy?
The person authorized to make that business decision should approve it. The person maintaining the knowledge sources can implement the change but should not invent missing terms. Small teams can combine roles, provided the record still distinguishes the policy decision, source update and answer review.
Can this checklist make every answer correct?
No. It creates a practical way to identify stale information, resolve conflicts and inspect important answers. You still need bounded responses for unsupported questions and a route to a person. Keep testing with real enquiry patterns using appropriately sanitized examples, and investigate failures instead of treating a passed sample as complete coverage.
Do I need a special approval feature to use the register?
No. A shared document or other team-controlled record can hold the checklist. The suggested owners, statuses and sign-off steps are a human operating process, not a claim that Hyperleap AI includes native approval workflows. Choose a location your team can maintain consistently and limit access according to your own information-handling rules.
How often should the source checklist be reviewed?
Review it whenever an important business fact changes, a source conflict appears or a customer question exposes a gap. A recurring review can catch overlooked material, but waiting for that date should not delay a known correction. Set the routine around how often your own offers, locations, hours and policies change.
Keep the Decision and the Answer Connected
The purpose of a knowledge source checklist is not to create another document nobody reads. It is to keep a customer's answer connected to a business decision that someone can explain and defend.
Start with one recent change. Identify the claim, find its copies, name the approving owner and ask the customer questions that should now produce a different answer. Check neighboring questions that should remain unchanged. Record the result and leave a clear route for unresolved cases.
An AI front desk is most useful when it handles routine explanations without creating new promises for your team to unwind. Current sources, explicit boundaries and a small retest habit help you work toward that outcome. They let the owner spend less time reconstructing where an answer came from and more time resolving the decisions that genuinely need their judgment.
Build on information your team can stand behind
Create a Hyperleap AI front desk, attach your approved sources and test the answers customers need most.
Start for freeIndustry Solutions
See how AI chatbots work for these industries:
Related Articles

AI Front Desk Welcome Messages: Examples That Help
Write useful AI front desk welcome messages with practical examples, clear capability boundaries and a checklist for your website greeting.

Unified Inbox Rules for Small Customer-Facing Teams
Give shared customer conversations clear ownership with practical unified inbox rules, handoff notes and a review checklist for small teams.

Hotel Group Enquiry Scripts: From Question to Handoff
Use practical hotel group enquiry scripts to gather dates, room needs and event context, then hand a clear brief to your reservations team.

AI Front Desk Test Plan: 25 Customer Questions
Test your AI front desk before launch with 25 customer questions, clear pass criteria, booking boundaries and a practical review record.
