Measure the usage of one AI workflow

A useful AI usage estimate starts with a finished business task. If the task is preparing an internal service summary, measure everything needed to produce an acceptable summary, including failed attempts and review. Counting only the first model response leaves important work outside the estimate.

This guide helps a business owner measure one workflow before expanding it. You will create a small usage log, compare it with provider records, and build an estimate with visible assumptions. The provider documentation referenced here was checked on October 10, 2026. No example rates or promised savings are used.

Define the unit you will measure

Write a clear completion rule. For example: one approved source document becomes a draft summary that a named reviewer either accepts or rejects. Record where the task begins and ends. If a person must collect missing information, that effort belongs in the record even when the AI does nothing during the wait.

Keep attempts and accepted results separate. A task that takes several attempts is still one business task, with several attempts attached. Give it a simple identifier so you can connect the initial request, corrections, tool activity, and final decision without copying confidential source text into every log.

Decide whether your estimate concerns direct service charges, staff effort, or the complete operating cost. Report these separately before combining them. A software invoice and an hour of staff attention are different kinds of evidence.

Choose examples that resemble your work

Select ordinary short tasks, longer tasks, and examples that require clarification. Include a missing attachment, a contradictory source, and a request that should stop for human approval. Use invented material first. Move to approved real material only when its disclosure and storage have been reviewed.

Do not build the estimate from the shortest, cleanest example available. Ask the people doing the work which cases regularly cause delays. Their answers will help identify the task groups that deserve separate measurements.

Record the current manual process on comparable examples. If the AI test uses ready-made clean inputs while the manual process includes finding and preparing them, the comparison will be misleading.

Capture a complete run record

For each task, record the configuration and what actually happened:

• Task identifier, task group, start time, and finish time
• Provider, exact model identifier, and relevant processing mode
• Input and output usage reported by the provider
• Separate cached usage or other billable categories when available
• Tool calls, retries, cancellations, and the reason for each repeat
• Reviewer time, corrections, and the final acceptance decision

The provider's usage record is more reliable than guessing from the visible answer length. OpenAI documents both request-level usage information and an account Usage Dashboard. Its dashboard uses UTC and has a project filter independent of the project selected elsewhere in the platform. Usage documentation.

Ask the implementer to capture the fields the chosen service actually exposes. If a field is missing, label it missing. Do not estimate invisible usage by treating every word as a fixed number of tokens. Also check whether a failed or cancelled task appears in billing rather than assuming it was free.

Apply the correct current prices

Look up the specific provider, model, processing mode, and usage category used in the test. A text model's visible input and output are not necessarily the only billable items. OpenAI's current pricing page separates model usage categories and lists tool-related charges. API pricing.

For each category, multiply measured units by the applicable rate, matching the rate's stated unit. Keep the currency and rate-check date beside the calculation. Record any account-specific pricing separately from public list prices, and have the billing owner confirm what applies.

Add hosting, storage, subscriptions, and other services only where the workflow uses them. Avoid allocating an entire shared subscription to one task unless that is your stated accounting method. Equally, avoid treating a shared service as free simply because the pilot did not generate a separate invoice.

Reconcile before forecasting

Compare the run log with the provider's reported activity for the same account, project, and time window. Look for background jobs, manual experiments, unrelated workflows, and delayed reporting. A mismatch is a question to resolve, not a reason to quietly adjust the figures until they agree.

For a monthly projection, estimate each task group's expected volume separately. Apply its measured usage pattern, then show a busier scenario with longer inputs or more retries. State which operating costs remain fixed and which vary with volume. Small samples support planning, not a guarantee about the next invoice.

Fictional example

Harbor Demo Repairs is an invented service business. Its pilot turns fictional technician notes into draft job summaries. Short notes, long notes, and notes with missing details are measured separately. The owner notices that clarification work is absent from the initial log and adds a reviewer-effort field before using the results. No customer performance or financial outcome is implied by this example.

Measurement checklist

1. Agree on one accepted business result and its task boundary.
2. Select representative examples, including incomplete inputs.
3. Record attempts, usage categories, tools, and human effort.
4. Attach dated provider prices without changing their units.
5. Reconcile the same reporting window and account scope.
6. Forecast by task group and disclose missing information.
7. Recheck after a model, prompt, tool, or workflow change.

Keep the log restricted to people who need it. Store identifiers and measurements wherever possible, with approved source material in its existing protected location. Bring a redacted log and the unresolved billing questions to InstallAI when discussing the next implementation step.