For AI service providers · Guide
How to price managed AI services from observed delivery cost
Price managed AI services from the work you actually deliver: setup, recurring operation, human review and support. Measure those costs during a bounded pilot before quoting a retainer. Platform plans and model charges are inputs, not a market rate or proof that a service will be profitable.
By Agentic Workers Team · Published · Updated
Responsibilities and evidence
Agree on the owner and retain a safe evidence reference for each responsibility.
- Service scope
- Provider drafts; client accepts. Evidence: agreed output and stop conditions.
- Account ownership
- Client and provider confirm owners. Evidence: account inventory without secret values.
- Configuration
- Provider sets up the intended workspace and agent. Evidence: reviewed settings.
- Action review
- Named reviewer checks supported actions. Evidence: request and decision.
- Acceptance
- Client or delegated reviewer checks the result. Evidence: accepted artifact.
- Exit
- Account owner and provider remove access. Evidence: handoff and denied-access check.
1. Separate setup from ongoing work
Estimate discovery, account setup, configuration and acceptance testing separately from recurring review and support. Agree on which changes require a new scope. Do not sell an unlimited service before understanding exceptions.
2. Measure the pilot
Record platform and external usage, operator time, corrections and accepted outputs. Use your own measured values. Example formula: delivery cost equals direct service charges plus review effort plus support effort. Any hourly rate or margin you enter is your assumption, not a benchmark.
3. Write the commercial boundary
Specify included output, cadence, review responsibility and treatment of third-party charges. Check current plan eligibility and vendor pricing at quotation time. Review the quote after the pilot rather than presenting untested economics as a fixed truth.
Example provider workflow. Adapt it to the client’s agreed scope.
- 01
Step 1: Separate setup from ongoing work
- 02
Step 2: Measure the pilot
- 03
Step 3: Write the commercial boundary
Fit and limitations
- Good fit
- Providers applying this process to an agreed client service.
- Poor fit
- Treating this checklist as an automatic product feature or a substitute for a client agreement.
- Known limits
- These are operating recommendations. Test each supported product path in the target workspace and plan. Examples are not performance, pricing or security benchmarks.
Sources and evidence
Documentation establishes the scope of a claim. It does not replace an acceptance test in your client’s environment.
| Source | What it supports | Checked |
|---|---|---|
| Current plans and billingProduct documentation | Confirm current plan eligibility and separate third-party usage. No numeric pricing comparison is made here. | |
| Read an agent run recordProduct documentation | Inspect available tool calls and execution details within the relevant workspace. A completed run is not proof of an accepted result. | |
| Schedule a recurring jobProduct documentation | Configure and test the schedule, time zone, agent and supported result destination. |
Questions providers ask
Who is responsible for the result?
The provider names an operator; the client names the person who can accept the deliverable. The platform does not replace those responsibilities.
What evidence should we retain?
Keep the source date, workspace and agent, expected output, review decision and artifact reference. Exclude credentials and unnecessary personal data.
When should we stop and review?
Stop when the account, recipient, output or permissions differ from the agreed scope, then resolve the exception before continuing.
Set up one client service
Set up the client workspace, connect its tools and review the first deliverable. Use a tested delivery path, such as Telegram, so the client can receive work in chat. Track operating costs and review effort before pricing a recurring service.
Sign up now