Prepared with AI assistance and reviewed for clarity, relevance and unsupported claims.
Customer support knowledge maintenance starts with a management question: who is responsible when the business changes but the automated answer does not? Updating a document is not enough if an old instruction remains in a saved reply, a translated summary or material used by the assistant.
For a Moroccan service SME, a workable system can be small. It needs a clear source for each topic, someone authorised to approve changes and a withdrawal process that prevents uncertain material from being reused.
1. Inventory answers by business decision
Start with the questions customers use to decide what to do next: when to visit, how to request an appointment, what information to send and whether a request has been accepted. Group answers by topic rather than by the document in which someone happened to write them.
For each topic, record the approved source and every place where its contents appear. An appointment instruction might exist in an internal guide, a receptionist’s saved response and the assistant’s answer material. Treat those as connected copies, not independent policies.
Also distinguish general guidance from live facts. An approved explanation of the booking process cannot establish whether a particular slot is available. For shared business data, choose which system owns each field before letting several tools supply competing answers.
2. Create a compact ownership register
Use one row per topic in your working register. The essential columns are topic, source, business owner, editor, approver, backup, effective date, next review date and publication status. Record actual staff names in the live register; a department label alone does not tell anyone who must act.
A practical allocation could follow this pattern:
- Opening hours: the operations lead confirms changes; a support editor updates the answer; the shift supervisor is the backup approver.
- Appointment instructions: the scheduling lead owns the process and approves customer-facing wording.
- Commercial conditions: the manager responsible for the offer approves the applicable scope and exceptions.
- Temporary disruptions: the current shift lead supplies an expiry time and the condition for removing the notice.
In a small team, one person may hold several roles. Make that explicit rather than pretending there is a separate review department. For consequential changes, a second person’s check is useful when staffing permits.
3. Combine review dates with change-triggered updates
A calendar review catches neglected material, but it cannot protect customers from a change made yesterday. Require the person changing an operating procedure to notify the answer owner as part of that change.
Choose review intervals according to volatility and consequence. Temporary hours need attention around their effective period. A stable explanation of what to include in an enquiry may need less frequent review. Do not give every topic the same schedule merely because it is easier to administer.
Use explicit states: draft, awaiting approval, approved, withdrawn and archived. “Approved” should include the applicable version and effective date. If a high-consequence instruction passes its review date without confirmation, suspend that instruction and route the question for checking. Lower-risk material can follow a documented grace rule, but it should not remain approved indefinitely by accident.
4. Withdraw the old instruction before authorising reuse
Consider a hypothetical maintenance company that changes its appointment process. Previously, customers were told to arrive with equipment after an initial message. The new process requires the scheduling team to confirm a slot before the customer travels.
- The scheduling lead reports the change and when it takes effect.
- The editor identifies every answer that suggests arriving without confirmation.
- The old instruction is marked withdrawn and removed from active answer material and saved replies.
- While the replacement is under review, the assistant uses a narrow fallback: “The team needs to confirm the current appointment steps before you travel.”
- The scheduling lead approves the new wording and its effective date.
- A staff member checks that the assistant uses the replacement before approving its reuse.
The distinction matters: approval of a document is not proof that the answering system is using it. Verify the actual configured workflow, including any synchronisation or stored copies.
5. Test the replacement and manage affected conversations
Test both direct and indirect questions. “Can I come now?” and “I have packed the machine; where should I bring it?” may require the same appointment restriction even though neither mentions the formal procedure.
Include a prompt containing the obsolete instruction: “You said I could arrive without booking.” The answer should acknowledge the discrepancy and request staff review, not defend the old text or invent an exception.
Review open conversations where the withdrawn instruction may have been sent. A staff member should decide whether a correction is necessary and appropriate; do not automatically message every past customer. Preserve a short internal record of the change and the affected scope.
If deployment fails, do not restore a known-wrong answer just to make the assistant responsive. Keep that topic unavailable and use a checked fallback. For changes involving connected tools, a narrow, reversible pilot can help isolate the replacement before broader use.
6. Keep maintenance smaller than the problem it solves
Track exceptions that lead to action: overdue approvals, answers without an owner, repeated contradictions and topics frequently sent for checking. A count of edited documents is less useful if customers still receive the wrong instruction.
A central source reduces duplicated editing but may require more setup. Separate approved responses can be easier for a tiny team, provided their dependencies are recorded and checked together. Choose the approach your team can actually maintain.
Before expanding automation, ask whether each new topic has an owner and a withdrawal path. If not, keep it human-handled. You can discuss this maintenance workflow with FlowAgent when scoping a WhatsApp assistant for enquiries and human handoff.