AI Maintenance and Support

Updated September 15, 2026 · AI-assisted guide. Sources and illustrative examples are identified below.

AI maintenance needs an owner for the software, the business information, and the work the system performs. Define support hours, review routines, update tests, spending limits, and a recovery path before relying on an assistant in daily operations.

---

A website assistant can display a working chat window while giving an outdated answer. An intake workflow can generate a convincing summary while failing to create the staff task. Maintenance needs to check these business outcomes as well as whether the website loads.

This guide provides a practical operating plan for a small business. It does not describe a support package already included with every AI Curdy or DOYJO project. Agree on the actual responsibilities, availability, and charges in your proposal.

Make a short inventory of what you depend on

List the website, AI plugin, selected model, approved knowledge sources, connected services, and the person who owns each account. Record what each part contributes. For example, the website displays the form, the model drafts a summary, and the CRM stores the inquiry.

Include dependencies that are easy to forget: a calendar connection belonging to a former employee, a paid plugin license, a knowledge document maintained outside WordPress, or a usage account charged to an old card. A diagram is optional. A clear list with a responsible person is essential.

Keep account access in an appropriate password manager. The operating document should describe how authorized staff obtain access without exposing passwords or API keys in a shared checklist.

Separate the kinds of maintenance

One person may cover several roles in a small team. The purpose is to prevent a gap where the developer assumes the owner updates policies and the owner assumes the assistant discovers every change automatically.

Treat plugin updates and model changes separately

WordPress documents automatic-update controls for individual plugins and themes, update notifications, and the need for a recovery option. These controls concern WordPress software. See the WordPress auto-update documentation.

Model availability and model selection are separate questions. AI Engine documents how its model list can be extended when a newly available model has not yet appeared in a plugin release. That does not establish that an existing assistant has switched models or passed your business tests. See AI Engine’s model-list documentation.

For a proposed change, record its purpose: address a supported-software requirement, fix a failure, improve a demonstrated weak answer, or evaluate a different cost and quality balance. Avoid changing several unrelated components together when that would make a regression difficult to trace.

Review security updates promptly through the responsible maintainer. For planned behavior changes, test on an appropriate staging setup or controlled pilot, keep the previous configuration available, and decide what evidence permits release.

Keep a small set of repeatable business checks

Create test questions and tasks from the system’s actual scope. Include ordinary requests, incomplete information, conflicting source material, out-of-scope questions, and a failed connection. Write the acceptable outcome beside each case.

For example, an assistant should link to the current service page when asked what the business offers. It should ask for clarification when two services fit. It should direct an exception request to staff. If it is allowed to schedule, the test needs a confirmed booking record, including the correct time zone.

Keep test records separate from real inquiries and use a designated test destination for messages. Check the public visitor experience as well as the administrator view. A logged-in editor successfully using a tool does not establish that an ordinary visitor can complete the same task.

Repeat the relevant checks after a model, prompt, source, plugin, or integration change. Save a short result and the configuration version. That gives future troubleshooting a useful reference.

Use an example to define a real review

Consider a hypothetical Sheboygan repair business whose assistant explains preparation steps and collects requests. Its seasonal hours change. Updating the footer alone is insufficient if a separate knowledge document still lists the old hours.

The business owner updates the approved hours source and tells the maintainer where it changed. The maintainer checks how the assistant receives that source, refreshes it where required, and runs questions about weekday hours, weekend access, and an unavailable appointment.

The reviewer checks the reply and its destination link. They also confirm that the assistant says a request was received only when the intake record exists. The review is complete when the whole path works and the result is recorded. This example describes a proposed process, not a client result.

Make incidents easy to report and contain

Give staff one place to report problems. Ask for the page or workflow, the time, the expected result, the observed result, and a reference number where available. Include only the conversation details necessary to reproduce the issue.

Distinguish an unavailable tool from a wrong answer, a failed downstream action, and a request for a new feature. They may require different responses. Define who can pause an affected action or temporarily direct visitors to an ordinary contact form.

After containment, identify which records need reconciliation. If an integration failed halfway through, inspect what already completed before replaying anything. Restoring a website configuration does not retract an email or remove an appointment created in an external calendar.

Close the incident with the cause when known, the repair, the affected work, and a test that would reveal a recurrence. An unresolved cause should stay marked unresolved.

Review usage without collecting everything

Set a realistic operating budget and decide who investigates unusual usage. AI Engine documents query, token, and dollar-based limits with separate user, guest, and system settings. Review what is actually enabled and how a visitor is informed when a limit is reached. See its Insights and limits documentation.

Use the minimum records needed to investigate problems and measure the service. Decide who can read them and how long they remain useful. A complete conversation archive should not become the default answer to every measurement question.

Compare usage with completed useful work. More conversations may reflect increased demand, repeated failures, or abuse. Sample outcomes before increasing capacity or celebrating growth.

Agree on the support boundary

A support agreement should identify the covered components, contact method, working hours, response target, and escalation path. Clarify whether the target concerns an initial response, investigation, or restoration. Those are different commitments.

Ask how routine source edits, software updates, new features, third-party outages, and after-hours requests are handled. Confirm the costs of model usage and third-party subscriptions. Document who owns accounts, configuration exports, and source materials if the support arrangement ends.

Choose a review rhythm that matches actual change and demand. A seasonal service business may need checks before its hours or offerings change. A workflow handling frequent inquiries may need more regular outcome sampling. Keep the plan small enough that someone will perform it.

For help defining that plan, discuss your AI workflow with AI Curdy. Brian at DOYJO works from Sheboygan, Wisconsin, with businesses nationwide. Bring your current tools, the work the assistant handles, and the person who will own it after launch.

Keep exploring

• Prepare and maintain business knowledge
• Plan AI development costs
• Measure chatbot outcomes

Which maintenance responsibility needs a clearer owner? Send AI Curdy your question, or share this guide with the person supporting your website.