A business changes its prices in March. The website is updated the same week, which everybody considers done.
The assistant was trained two months earlier and continues quoting the old figures. Nobody notices until a customer arrives expecting a price that no longer exists and is understandably annoyed.
The change was made properly. What was missing was any routine connecting a change in the business to the thing answering questions about it.
Step 1: list what actually changes
Prices, hours, services, coverage, staff, policies and lead times. A short list, and the complete scope of the maintenance.
Step 2: name one owner
Not a team. One person responsible for the answers, with everybody else knowing to tell them, which is the only arrangement that survives.
Step 3: attach the update to the existing change process
Whoever changes a price updates the answers at the same time, so it becomes part of the task rather than a separate one.
Step 4: keep the answers in one place
Rather than scattered across a site, so a change is one edit and not an archaeology exercise, which is the structure in how to write answers your saas assistant can use.
Step 5: check the price answers specifically after any change
The most damaging category to get wrong, and the one worth testing directly rather than assuming.
Step 6: review the unanswered questions monthly
Ten minutes, which produces both the new answers to write and an early signal that something has changed and nothing was updated.
Step 7: read a sample of conversations
The only reliable way to catch a confidently wrong answer, which no metric will surface on its own.
Step 8: check the seasonal content
Holiday hours, seasonal services and anything time bound, which is wrong for a portion of every year unless somebody actively removes it.
Step 9: remove rather than add where possible
An old page retired is one fewer source of a wrong answer, and tidying beats supplementing.
Step 10: handle the product and stock content separately
Which changes far more often and is the ground in training an assistant on an existing wordpress site.
Step 11: re-check after any site redesign
A rebuild changes structure, urls and content, and an assistant trained before it is frequently answering from things that no longer exist.
Step 12: keep a note of what was changed and when
So a wrong answer can be traced to a change rather than investigated from the beginning.
Step 13: test it as a customer occasionally
Ten minutes asking the questions a customer would, which catches more than any review of the content itself.
Step 14: tell the assistant when something is discontinued
Removing a page is not the same as recording that a service no longer exists. Stating the retirement explicitly is what stops a confident answer being assembled from whatever else still mentions it.
Step 15: make it a routine rather than a project
An assistant maintained by a ten minute monthly routine and an update habit attached to existing changes stays accurate indefinitely, and one maintained by nobody is confidently wrong within a season. Set it up through install the widget and train your bot, connect the store through integrations, the installation concerns sit in adding an assistant without breaking the theme, and the specific case in updating assistant for new service. The sector view sits under small business.