What a care plan should cost, and what it should include

Software maintenance cost is usually budgeted at 15–25% of the build cost per year, or bought as a monthly tier with a fixed hour allowance and a response time. Systems with a language model in them need more than that: prompts drift, providers change models and prices, and the evaluation suite has to be re-run every time either happens. This article sets out what a care plan should include, what the tiers cost, what an AI maintenance retainer adds, and how to tell a plan that protects you from one that only bills you.

What maintenance is, and what it is not

Maintenance keeps a working system working: security patches, dependency updates, certificate renewals, backups tested, monitoring watched, small fixes when something breaks, and the small changes that any live product accumulates. It is not the roadmap. New features, new integrations and new modules are project work with their own scope and price. A care plan that quietly absorbs feature work runs out of hours by the tenth of the month; a plan that refuses every small change is useless. The line is: if it takes under a day and does not change the architecture, it is care.

Care plan tiers and what they cost

Those are our maintenance and support tiers. The shape is the one to look for in any support plan cost: a coverage window, a response time for critical issues, an hour allowance, and a named person at the top tier. Compare plans on those four things, not on the monthly figure alone.

What every care plan should include by default

• Security patches and dependency updates on a schedule, with a changelog you can read
• Monitoring with alerts that reach a person, and a monthly report of what fired
• Backups that are restored on a schedule to prove they work
• Certificate, domain and credential rotation before expiry
• A ticket channel with the agreed response time and a named escalation path
• Small fixes and small changes inside the hour allowance
• A quarterly review of the system's health, cost and risk list
• Documentation kept current as changes are made

What an AI system adds

A conventional application behaves the same on Tuesday as it did on Monday. An AI system does not, because the model behind it is a service someone else runs. Providers retire models, release new versions with different behaviour, change prices and change rate limits. Your prompts were tuned for the old model. Your cost forecast was built on the old price. An AI maintenance retainer therefore has to include work a conventional AMC never had.

Evaluation re-runs

The golden set of real conversations or questions, graded and held from the build, is re-run on every model change, every prompt change and on a schedule regardless. If accuracy on an intent drops, the plan covers the fix or the rollback. Without this, the first sign of a model regression is a customer complaint.

Prompt and routing maintenance

Prompts are code and need tending: a new edge case from the escalation review, a policy update, a phrasing that a new model version handles differently. Routing tables need revisiting when a cheaper model becomes good enough for a call type, or a provider changes prices. Both are inside the allowance.

Cost tuning

Inference bills are reviewed monthly against the forecast. Caching hit rates, output token limits and retrieval sizes are adjusted. A plan that does not report cost per request each month is not maintaining the AI part of your system. The tracing that makes this possible is described in LLM observability.

Knowledge and data freshness

For retrieval systems, the index must reflect the sources. Refresh jobs fail silently unless watched. The plan should report unanswered questions and stale-content findings each month, so the content owners on your side know what to fix.

Percentage of build or monthly tier?

The 15–25% rule of thumb is a budgeting device, useful for a board paper. A monthly tier is what you actually buy, because it names the response time and the hours. For a $30,000 build, the rule gives roughly the Essential tier over a year; for a larger platform with integrations and an AI component, Standard or Enterprise is the honest number. Use the percentage to sanity-check the tier, not to replace it. The full picture of build, run and care over several years is in total cost of ownership for AI systems.

What the monthly report should show

The report is how you know the plan is being performed. For any system: uptime and incidents with cause and fix, patches applied, hours used against the allowance and on what, backup restores tested, and open risks. For an AI system, add the evaluation results by intent or question category against the previous month, prompt and routing changes with their eval outcome, inference cost per request and in total against forecast, escalation reasons clustered, and for retrieval systems the unanswered questions and stale sources found. One page is enough. If a vendor cannot produce that page, the AMC software pricing they quote is buying you a phone number, not maintenance.

Signs of a bad care plan

• No response time in writing, or one that only applies to business hours you do not keep
• Hours that expire monthly with no reporting of how they were used
• No monitoring, so you find out about outages from users
• No evaluation re-runs on model changes for an AI system
• No cost report for inference
• Feature work quietly billed as care, or care quietly refused as feature work
• A plan only the original vendor can perform, because nothing was documented

A worked example

A hospital network's multilingual voice agent went live after shadow mode with a graded set of recorded calls per language. Under the care plan, that set is re-run whenever the speech or language model provider announces a change, and monthly regardless. When a provider updated a model version, the re-run caught a drop in recognition for one language before the change reached production traffic, and the routing for that language was held on the previous version until the prompts were adjusted. The monthly report to the hospital's operations team carries per-language accuracy, cost per minute and the escalation reasons, which is how new call types get added to the roadmap. The multilingual voice agent case study describes the system.

How to size the tier

Count the integrations, the users and the hours the system must be watched. A single internal tool with office-hours users fits Essential. A customer-facing product with payments or a support agent handling real customers needs at least Standard, because a four-hour response on a critical issue is the difference between a bad afternoon and a bad week. Anything handling calls, money or health information around the clock needs Enterprise with a named engineer. Google's SRE book is the standard reference on the operational disciplines behind those windows, and our security page covers how access and data are handled during care.

Team and timeline

A care plan starts the day a build goes live and is agreed before the build is signed, so there is no gap. Essential is served by the build team's rota; Standard adds out-of-hours coverage; Enterprise assigns a named engineer who knows the system. Hours not used in a month do not carry over, and hours beyond the allowance are quoted before they are spent. Plans are monthly and can move between tiers with a month's notice. Tier prices and the build programs they follow are on the pricing page.

Before you start: a checklist

• Get the response time, coverage window and hour allowance in writing
• Confirm monitoring and alerting exist and who receives them
• For AI systems, confirm evaluation re-runs on model changes are included
• Ask for a monthly report format and see an example
• Agree the line between care and feature work before the first ticket
• Check that documentation is complete enough for another team to take over
• Confirm backups are restored on a schedule, not just taken
• Budget care from the go-live date, not from the first outage

Glossary

• AMC: annual maintenance contract; the traditional yearly maintenance agreement
• Care plan: a monthly retainer with a response time and an hour allowance
• Critical response: the time within which work starts on an outage or data issue
• Hour allowance: engineering hours included per month for fixes and small changes
• Evaluation re-run: testing the AI system against its golden set after a change
• Model retirement: a provider withdrawing a model version, forcing a migration
• Cost tuning: adjusting routing, caching and limits to keep inference inside forecast

Related reading

See total cost of ownership for AI systems, LLM inference costs: how to forecast your monthly bill and how much does AI development cost in 2026. For the operational principles behind response windows, Google's SRE book remains the reference.

Buy the tier that matches the hours your system must be watched, and for anything with a model in it, make sure the plan re-runs the evals before your customers run them for you.