Knowledge maintenance
Chatbot Policy Updates: A Version and Expiry Workflow
Update chatbot policy sources with an owner, effective window, change register and negative tests. Work through a fictional policy release and safe rollback decision.
By HostDesk · Updated · 6 min read
Update a business policy by recording what changed, who approved it, when it becomes effective and which answers depend on it. Correct the authoritative public information, refresh the relevant knowledge and test both the new rule and the old rule's removal.
The important outcome is an answer that reflects the current approved policy. A fresh crawl timestamp alone cannot establish that. This workflow is a manual operating method for content owners, not a claim that HostDesk provides every version, expiry or rollback control described here.
Separate approval, publication and retrieval
A policy decision belongs to the business. Publishing a page communicates that decision; refreshing a chatbot's knowledge makes information available to the answering system. These are related steps with different evidence, and none should silently stand in for the others.
Record a version identifier that a colleague can distinguish from the previous one. Keep approval date, effective date and review date separate. A policy can be approved today, take effect later and need review again before a seasonal exception expires.
GOV.UK's content-maintenance guidance illustrates the distinction between checking whether content works for users and changing or retiring it. Its publishing systems can also identify overdue reviews. The worksheet here adapts that general maintenance discipline; it does not imply that your business uses those systems.
Copy the policy change register
Create one row for the rule being changed, not one vague row saying 'website updated.' Include the exceptions and pages that repeat the rule. A prominent service page and a hidden PDF can otherwise give different instructions after the edit.
Where the system exposes a source hash or refresh receipt, preserve it. Where it does not, record the actual source version and the observed check without inventing a technical receipt. A spreadsheet is acceptable if it captures who made the decision and what still needs verification.
| Field | Purpose |
|---|---|
| Policy and owner | Which business rule is changing and who may approve it. |
| Old and new versions | Exact identifiers and the changed clause. |
| Effective window | Start, end if any, and the timezone used for the boundary. |
| Affected surfaces | Authoritative page, repeated copy, translated pages and relevant answers. |
| Allowed facts | What the current rule authorizes the assistant to say. |
| Retired facts | What must stop appearing after the change. |
| Refresh evidence | Actual knowledge update or source-check result, if available. |
| Retest and release decision | Observed cases, unresolved conflicts and the person accepting the change. |
Worked change: a collection window
The next example is fictional. At https://cedar-hire.example/collection, policy Example-v1 gives customers three calendar days to collect an item after a collection notice. The owner approves Example-v2: notices issued from 2026-11-01 at 09:00 America/Toronto use five calendar days; earlier notices retain the three-day window.
That scope matters. The new policy does not automatically rewrite an earlier customer's notice, prove that an item is currently reserved or establish live stock. The exact notice and any individual exception need their own evidence.
Record the business's chosen timezone and effective boundary in the fixture before testing. Do not rely on a reviewer's machine timezone. If the effective-time wording is ambiguous, stop and have the policy owner settle it before asking the assistant to interpret the rule.
| Record item | Example entry |
|---|---|
| Change | Example-v1: three calendar days. Example-v2: five calendar days. |
| Applicability | Notices before 2026-11-01 09:00 America/Toronto retain three days; notices at or after it use five days. |
| Published source | Reserved example collection-policy URL and approved Example-v2 text. |
| Retired statement | An unqualified claim that every notice always uses three days. |
| Earlier notices | The fictional rule explicitly preserves their three-day window; a real business must approve its own transition rule. |
| Release state | Illustrative preparation only; no real publication, ingestion or answer test occurred. |
Test the new answer and the old answer's absence
Write the expected result for at least three cases: clearly before the effective boundary, clearly after it and missing the information needed to decide. Add the important exception. This makes the change testable without relying on a reviewer remembering how last week's demo sounded.
Use a negative test that mentions the retired rule. A visitor saying 'I thought it was three days' must not become a new authority source. The assistant should explain the applicable approved rule or ask for the missing date, depending on the evidence available.
Also inspect conflicting copies. If the collection page has Example-v2 but an older FAQ repeats an unqualified three-day rule, fix the contradiction. Merely adding more text can leave the system retrieving both. Record the actual answer and cited source after each controlled retest.
| Case | Expected behavior | Failure to catch |
|---|---|---|
| Notice before effective boundary | Use the fixture's three-day window for an earlier notice. | Automatically applying the new window to every old notice. |
| Notice after boundary | Use the five-day rule with its scope. | Reviving an old three-day answer. |
| Notice date absent | Clarify or route to a person where the date changes the answer. | Guessing which version applies. |
| Visitor repeats old rule | Treat it as the visitor's claim; consult approved policy. | Promoting conversational context into authority. |
| Old FAQ remains online | Flag the conflict and correct the public sources. | Choosing a version simply because its wording is more confident. |
Give temporary facts an end condition
Temporary closures, seasonal arrangements and limited exceptions need an explicit end condition. Write what becomes true afterwards: the normal rule resumes, staff must review, or no approved replacement exists. An expiry date without a replacement plan can still leave a misleading answer.
Check the actual system's supported behavior. If it has a verified expiry mechanism, test its boundary in the intended timezone. If it requires a manual edit and refresh, assign that specific action. Do not assume that a source date, a reminder or a planned feature removes expired facts automatically.
When a policy is withdrawn, remove or clearly retire authoritative copies and the relevant knowledge. Retain the business's required history through its actual record process, while preventing historical text from being treated as the current answer.
Recover safely when the update fails
A technical rollback and a business-policy rollback are different decisions. If the business has already made the five-day policy effective, restoring an old application version must not make the three-day policy true again. Preserve the current authoritative policy while the technical problem is repaired.
If the knowledge update is uncertain, restrict the affected answer or use the real human route until it can be verified. Keep unaffected answers available where the actual system permits. Recovery should not require inventing a confident rule to fill the gap.
Close the register only when the public surfaces, source state and observed retests agree. Link to the initial knowledge-base guide for source preparation and the acceptance checklist for broader testing; this workflow specifically governs a change after the initial setup.