Use four commercial ledgers, clear usage rules, and a worked example to turn an AI website build into an offer clients can understand and you can operate.

AI website agency services become difficult to sell when one price is expected to cover four different things: creating the site, paying the platforms, keeping the system reliable, and making it better over time.

I would separate those responsibilities before inventing package names. The client should be able to see what they buy once, what can vary with usage, what keeps the site operational, and what creates new value. The agency should be able to tell which work is included without reopening the proposal every month.

This guide gives you a four-ledger model, a worked example, and a downloadable packaging worksheet. The example is illustrative. It assumes a fictional five-page service-business site with a bounded AI intake assistant, and it does not describe my customers, tests, prices, or results.

Define what is actually AI about the service

Start by distinguishing an AI-assisted build from an AI-enabled website.

In an AI-assisted build, your team uses AI to research, draft, design, code, test, or document the site. That may change your delivery process, but it does not necessarily create a new monthly cost for the client. You are still responsible for strategy, review, accessibility, quality assurance, and a usable handoff.

In an AI-enabled website, a visitor or staff member uses an AI feature after launch. A lead qualifier, document assistant, product finder, or client editing agent can create continuing model, search, storage, and monitoring costs. OpenAI's current pricing documentation, for example, meters models by model and modality and lists separate charges for some tools and storage. Treat those as variable operating inputs, not as free ingredients hidden inside the build fee (OpenAI API pricing).

This distinction changes the proposal. “We use AI to build your site” is a production method. “Your site contains an AI assistant” is a product feature with an operating model.

Use four ledgers for AI website agency services

You can present Launch, Managed, and Improve packages on a sales page. Behind those names, keep the four ledgers visible in your estimate and delivery system. That makes it possible to change a hosting plan without renegotiating your support fee, or add an optimization sprint without pretending it is maintenance.

Ledger A: package the one-time build around acceptance

A build package should define what will exist and how both sides will know it is ready. Include discovery, sitemap, pages, content responsibility, design system, integrations, data sources, responsive states, accessibility checks, privacy requirements, browser testing, launch work, training, and documentation.

For an AI feature, add its result contract. State the user input, the output, approved knowledge sources, what the feature must refuse, fallback behavior, and a small evaluation set. “Working chatbot” is not an acceptance criterion. “Answers these 20 representative questions from the approved knowledge base, cites the source page, and routes uncertain requests to the contact form” is much closer.

Then define the boundaries:

• number of pages, content types, integrations, and revision rounds;
• client review deadlines and the assumptions behind the launch date;
• what counts as a delivered defect during stabilization;
• what counts as a new request;
• the browser, device, account, and workflow checks you will perform;
• which changes trigger a written change order.

AI may help you produce faster, but speed does not remove accountability. A fixed price should reflect the outcome, review burden, integration risk, and acceptance criteria, not just estimated typing time.

Ledger B: separate platform usage from agency revenue

Platform cost is not one line called “hosting.” Modern sites can generate charges from data transfer, requests, compute, builds, image processing, storage, analytics events, model tokens, search calls, or email. Vercel's documentation, for example, separates several managed-infrastructure resources and explains that charges can begin after an included amount or credit is consumed (Vercel pricing documentation).

I see three defensible billing models:

1. Client-paid accounts. The client owns the vendor account and pays the vendor directly. This is my clearest default when the platform supports sensible collaboration and transfer.
2. Transparent pass-through. The agency pays the vendor, then passes through actual cost under written terms. State the invoicing lag, taxes, currency treatment, and any administration fee.
3. Allowance plus overage. The package includes a measured allowance. State the unit, reporting source, alert threshold, overage rule, and what happens at the limit.

For every variable resource, answer six questions: Who owns the account? Who pays? What unit is metered? What is included? Who can approve more? What happens if usage stops?

This matters on Fork too. Fork documents credits as a shared top-level organization wallet, with reservations and settlement for metered work. A funded wallet that is depleted fails closed rather than silently falling back to free usage (Fork credits and billing). That is an operating fact, not a ready-made per-client quota. Your package must still name the funding owner, monitoring process, included amount if any, and response to depletion.

Write usage rules before you need them

An allowance without an overage policy is only a delayed disagreement. Put these terms in the proposal or service schedule:

• the included monthly quantity and exact meter;
• the dashboard or invoice used as the source of truth;
• an alert threshold below the limit;
• whether the system continues, asks for approval, degrades gracefully, or stops;
• the pass-through or overage method;
• who can approve a higher budget;
• how abuse, bots, and accidental loops are handled;
• when vendor price changes trigger a review.

A hard cap protects budget but can interrupt the feature. A soft alert protects continuity but does not cap spend. Neither is automatically better. Give the client that choice and document the visible fallback. An intake assistant might switch to a normal form; a document search tool might display a support route.

Ledger C: sell support and maintenance as responsibility

A platform subscription can keep infrastructure available. It does not promise that your agency will notice a broken form, test a restore, respond to an incident, review an AI failure, or make a content change.

A care plan should describe the human responsibility in operational terms:

• monitoring targets and check frequency;
• backup scope, frequency, retention, storage location, and restore testing;
• dependency or platform updates and regression checks;
• form, integration, and key-journey tests;
• AI evaluation, retrieval-content freshness, abuse review, and fallback checks;
• support channel, coverage hours, and severity definitions;
• included minor-change allowance and exclusions;
• a monthly activity and usage report.

WordPress illustrates why “backups included” is too vague. Its official guidance says a typical complete restore requires both files and the database, and recommends checking automated backups and retaining recent copies in different locations (WordPress backup guidance). Your plan should state what is captured and whether anyone tests recovery.

Also separate acknowledgment from resolution. You can promise to acknowledge a critical issue within a defined coverage window. You often cannot promise a final resolution time before you know whether the fault is in your code, a vendor, DNS, client data, or an external integration.

Ledger D: sell improvement separately from keeping the lights on

Maintenance preserves an agreed operating state. Improvement changes that state.

An improvement retainer might include new service pages, content refreshes, conversion experiments, accessibility work, performance tuning, Search Console review, or changes to an AI prompt, model, retrieval source, and evaluation set. Those tasks need prioritization, implementation, measurement, and review. Hiding them inside a basic care plan makes the care plan unprofitable or the improvement promise hollow.

Google says Search Console can show performance by queries, pages, and countries and suggests checking around monthly or when content changes (Search Console guidance). That supports a practical monthly review cadence. It does not support a ranking guarantee. Google's SEO Starter Guide says there is no secret that automatically ranks a site first, changes may take hours to months to appear, and not every change produces a noticeable result (Google SEO Starter Guide).

Promise outputs you control: two content refreshes, one experiment, a technical issue backlog, a monthly review, or a quarterly roadmap. Describe the intended business signal, but do not turn an uncertain search or conversion outcome into a guaranteed deliverable.

Turn the ledgers into three understandable packages

Not every client needs all three. A small brochure site may only need Launch and a modest care option. An AI lead magnet may require Managed from day one because it collects data, calls external services, and needs a failure path. If that is your offer, the AI lead magnet guide provides concrete formats and operating questions.

Worked example: a bounded AI intake site

Assume a fictional consultancy needs five marketing pages and an AI intake assistant. The assistant asks approved discovery questions, summarizes the visitor's answers, and sends the result into an existing inquiry workflow. It does not give professional advice, make commitments, or autonomously contact third parties.

Here is how I would divide the offer:

The price comes after the scope. Estimate your delivery labor, specialist costs, review and project-management time, expected support load, contingency for the risks you accepted, and target margin. Calculate platform usage separately from labor. These assumptions make the number explainable and make later changes easier to price.

Make ownership and exit part of the package

A clear offer says who owns the domain and DNS, platform account, source repository, model-provider project, analytics property, application data, and design files. It also says what the client receives at termination and which managed features stop.

On Fork, a client application can live in its own persistent space and runtime, but Fork's documentation warns that a space is a trusted application boundary (Fork spaces). The application's backend still needs its own authorization for end users. Likewise, project roles and instructions are not interchangeable with every possible application permission. Fork documents separate role, billing, secret, project, and runtime boundaries (Fork roles and permissions).

Recovery needs the same precision. Fork snapshots can preserve and restore workspace state, and a restore is destructive (Fork history and snapshots). A workspace restore does not unsend email, reverse a payment, or guarantee recovery of every external system. Name the recovery owner for each connected service.

For a full ownership, account, permissions, and training process, use the website handoff checklist. If clients will make AI-assisted changes after launch, also define their editing surface with the client AI editing guide.

Use the five-question proposal test

Before sending a proposal, check whether a client can answer these questions without a call:

1. What exactly will exist at launch?
2. What can make the monthly bill change?
3. What happens when something breaks?
4. What work improves the site rather than merely maintaining it?
5. What do we own and receive if the relationship ends?

If one answer is fuzzy, the package is not finished. Use the AI website service packaging worksheet to complete all four ledgers, assign ownership, and write the client-facing summary.

Package the responsibility before you price it

The strongest AI website agency services are not a menu of AI features. They are a clear allocation of outcomes, costs, operational responsibility, and improvement work.

Build once. Meter what varies. Charge for care when you accept operational responsibility. Sell improvement when you are committing to new work. Then price each ledger from your own cost, risk, capacity, and margin instead of borrowing an unsupported market average.

Fork is designed around agencies creating client websites with controlled AI access. If you want to explore that model, join the Fork waitlist. Access is opening in batches, so I would treat the worksheet as the immediate next step and the platform as one implementation option.