Comparing AI pricing models fairly requires more than placing headline rates in a spreadsheet. Define the business result you need, identify exactly what each vendor bills for, measure how many billable units a complete attempt creates, and calculate the cost of achieving that result.
A credit, task, operation, conversation, token, or outcome is a billing unit, not automatically a measure of value. The same customer result may create several workflow charges, while several messages or procedures may count as one conversation under a vendor’s rules.
For example, if a workflow costs $0.40 per attempt and achieves the defined result 55% of the time, the estimated AI charge per AI-achieved result is $0.40 divided by 0.55, or about $0.73. That is a hypothetical buyer-side calculation, not a vendor rate or performance benchmark.
A billing unit is not a value unit. Compare vendors only after the chargeable event and the buyer-defined business result are both clear.
Identify the billing grain before comparing rates
Billing grain means the record or event that triggers a charge. Classify every quoted charge before comparing prices.
- Seat or platform: access, capacity, or a base subscription. Ask what usage is included and what is charged separately.
- Conversation or outcome: a conversation reaching a vendor-defined status or event. Ask whether a handoff can count and when the status becomes final.
- Attempt, task, action, or operation: a workflow step, successful action, or module run. Ask how many billable steps one complete result creates.
- Token, page, file, duration, or minute: model input and output, processed media, or elapsed usage. Ask which workload details change consumption.
These categories are comparison aids, not universal definitions. Rates and counting rules remain product- and contract-specific.
HubSpot’s current documentation lists Customer Agent at 50 credits for resolving one text-based conversation, and its product page describes pricing of $0.50 per resolved conversation. The documented resolution definition includes support without a human handoff for 72 hours, with lead qualification potentially qualifying as a resolution. Reply-based status may be evaluated 72 hours after the visitor’s last response. See the HubSpot product and services catalog and Customer Agent resolution rules. Deflection should not be substituted for resolution without checking the definitions.
Fin documents outcome billing at conversation grain. Certain successfully executed procedure handoffs can be billable even when a conversation transfers to a person or workflow, while some default or workspace-level escalations may be treated differently. Fin also documents at most one charge per conversation for the relevant billing period. See its outcome pricing rules.
Zapier generally counts successful action steps as tasks, although some products and features use different rates. Make uses credits as its billing label while retaining operations as a measure of module runs. A module can run multiple times when it processes multiple bundles, and AI credit consumption can vary with tokens, files, pages, processing time, model, and connection type. Review the official Zapier task guidance, Make credit documentation, and Make operation definitions.
For each quote, record the product edition, billing unit, rate, currency, conditions, effective date, source, and number of units generated by a representative end-to-end attempt. Do not assume one scenario run equals one operation or one business result equals one task.
Normalize every quote to the same result
Start with the general pilot measure:
Observed variable cost per buyer-defined result = total observed billable spend divided by buyer-defined completed results.
Keep fixed fees separate until you calculate all-in cost. For per-attempt billing, use this buyer-side estimate:
Estimated AI cost per AI-achieved result = variable AI cost per attempt divided by probability of achieving the defined result.
This assumes the attempt-level charge applies whether or not the attempt succeeds. If one attempt consumes three tasks or operations, include all three in the attempt cost. If unsuccessful attempts go to people, report human fallback separately rather than calling the completed case an AI-achieved result.
For outcome billing, do not automatically treat the quoted outcome rate as cost per buyer-defined result. Divide actual billed charges by independently counted buyer-defined results when billable outcomes can include procedure handoffs, lead qualification, or other vendor-defined events.
Hypothetical example: A workflow costs $0.40 per attempt and achieves the defined result 55% of the time. The estimated AI cost per AI-achieved result is $0.40 ÷ 0.55 = approximately $0.73. Replace both assumptions with workload-specific pilot observations.
Keep these three calculations distinct:
- AI cost per AI-achieved result: AI variable spend divided by results achieved by AI.
- Expected human fallback cost: the cost of handling unsuccessful, escalated, or quality-review cases.
- Total cost per completed case: AI spend, fallback, platform allocation, data charges, and other applicable costs divided by buyer-defined completed cases.
State how abandoned cases, repeat contacts, constrained cases, and cases resolved by people are treated. For annual planning, multiply workload-specific variable cost by expected volume, then add platform fees, minimum commitments, overages, add-ons, external provider charges, and expected fallback cost.
An outcome price is comparable only when the vendor’s outcome matches the buyer’s result. If a billable outcome can be a configured handoff, keep that charge separate from customer-resolution cost until the pilot confirms the business result.
Build a fair pilot and define the denominator
Use the same workload segments, eligibility rules, measurement window, and buyer-defined result across vendors where practical. Before testing, write a denominator contract that specifies:
- Which incoming cases are eligible for AI.
- What counts as an attempt and what counts as an AI answer.
- What result the buyer requires and who approves ambiguous outcomes.
- How handoffs, repeats, abandoned cases, and constrained cases are treated.
- When a result becomes final, including any vendor evaluation window.
Record incoming cases, eligible cases, AI-answered cases, constrained or bypassed cases, resolved cases, escalations, abandoned cases, units consumed, vendor status, and observed charges. Use at least two workload segments where feasible. A blended average can hide the difference between short routine requests and complex cases.
HubSpot documents a 72-hour evaluation window for relevant Customer Agent resolutions. Fin changed its performance metric definitions in 2026, including the treatment of constrained conversations. A vendor-reported resolution percentage is not comparable until the denominator, eligibility rules, metric version, and reporting period align. Fin’s metric update documentation describes those changes.
Use a practical implementation ledger
A buyer-controlled workbook or database should keep four grains separate: pricing observations, pilot attempts or workflow runs, outcome events, and period-level summaries. Do not combine messages, runs, outcomes, and monthly totals in one row.
A pricing-observation row should identify the vendor, product edition, feature, billing unit, rate, currency, effective date, source URL, retrieval date, and quote or rate-sheet version. An attempt or run row should identify the pilot, vendor, workload segment, business case, stable attempt or run ID, units consumed, success state, escalation state, and measured variable cost. An outcome row should identify the business case, outcome ID, vendor status, buyer result, billable flag, evaluation timestamp, and cost. A period summary should include the product edition, period boundaries, timezone, metric name, and metric-definition version.
The following is an illustrative buyer-side attempt record, not a vendor template:
{
"pilot_id": "pilot_01",
"vendor_id": "vendor_x",
"business_case_id": "case_0042",
"attempt_id": "attempt_0001",
"workload_segment": "billing questions",
"units_consumed": 3,
"buyer_result_state": "achieved",
"human_escalation_state": "not escalated",
"pricing_source_version": "quote_2026_10"
}Use a stable source event ID or pilot attempt ID for event-level deduplication. A proposed key such as pilot_id + attempt_id uniquely identifies pilot attempts, while a pricing observation needs a broader key such as vendor, edition, feature, billing unit, effective date, and source version. Monthly aggregates need their own period and metric-definition fields. Do not use vendor plus date alone.
When concurrent workers can record the same event, use a database-enforced unique index and an atomic upsert or transactional insert with conflict handling. A read-then-create check is not race-safe. Preserve the source event and append later observations rather than overwriting provenance.
AI may extract candidate rates and conditions from supplied quotes into draft fields. A person must verify the product edition, currency, effective date, included usage, failed-attempt treatment, and source version. Use deterministic calculations for totals and success rates. If the quote or rate-sheet edition is ambiguous, stop the calculation and ask procurement to resolve it. No API, export, webhook, or direct integration should be assumed unless the vendor confirms it.
Apply the method to common workflow patterns
The following patterns show how to compare billing grain with an actual operational sequence. They are buyer-side measurement designs, not verified vendor templates.
Support conversation to buyer-defined resolution
- Trigger: An eligible support conversation begins and receives an AI response.
- AI job: Answer the request, use approved support content, or execute a configured procedure.
- Validation: Record AI involvement, handoff category, vendor outcome status, buyer result, and evaluation timestamp. Wait for the documented evaluation window before finalizing recent cases.
- Action: Put the conversation in the outcome ledger and reconcile any billed outcome with the applicable contract rule.
- Fallback: Route unresolved or ambiguous cases to human review. Keep a configured procedure handoff distinct from a customer issue resolved by AI.
For HubSpot, keep resolution and deflection as separate fields because the official reporting documentation distinguishes them. For Fin, record whether a successfully executed procedure handoff was billable and whether the conversation had already generated an outcome.
Automation event to completed business result
- Trigger: A source event starts a workflow, such as a request to update a CRM record.
- AI job: Classify ambiguous text or extract fields when deterministic data cannot settle the decision.
- Validation: Check approved enum values, required provenance, confidence threshold, record existence, permissions, current record version, and duplicate-event key.
- Action: Write only validated fields to the system of record and retain the run, step, module, task, operation, or credit evidence separately.
- Fallback: Route low-confidence, stale, restricted, or high-impact cases to a human queue. Treat duplicate-key conflicts as idempotent completion only when the existing record matches the source event.
With Zapier, count successful action steps across the complete workflow rather than treating one Zap run as one task. With Make, record scenario run, module, bundle, operation, and credit details separately. A custom Make AI-provider connection can create two cost streams: Make credits and the external provider’s token charges.
Quote document to verified comparison field
- Trigger: Procurement receives a public rate sheet, quote, order form, or contract amendment.
- AI job: Extract candidate billing units, rates, conditions, and dates into draft fields.
- Validation: Compare every extracted value with the source and confirm edition, currency, effective date, included usage, minimums, overages, expiry, and failed-attempt treatment.
- Action: Store a checked pricing observation with its source URL, retrieval date, and quote or rate-sheet version.
- Fallback: Mark the quote unresolved when a charge, edition, or condition cannot be identified. Do not infer a conversion from an incomplete document.
Include costs beyond the headline rate
All-in cost may include base or platform fees, included usage, minimum commitments, overages, automatic upgrades, top-ups or capacity packs, credit expiry, add-ons, channel charges, premium models, quality review, human escalation, and external model-provider bills.
HubSpot documents that credits reset monthly and unused credits expire rather than roll over. Its catalog lists additional-credit pricing and feature-level rates, but account configuration, subscription, seats, channels, and contractual terms affect applicability. Its documentation also identifies possible service charges such as telephony minutes or SMS. Use the official HubSpot credit-management guidance and catalog when checking current terms.
Make documents dynamic credit consumption for some AI and advanced features. With a custom AI-provider connection, Make credits and provider token charges are separate. Do not assume a fixed prompt-to-credit conversion.
Model low, expected, and peak scenarios. Vary monthly volume, units per attempt, success rate, repeat-contact rate, human fallback cost, model or channel assumptions, overage exposure, and the share of included credits that expires unused. For a non-rollover plan, effective cost per consumed credit rises when the allowance is only partly used.
- Does the quote define failed attempts, retries, replayed steps, configured handoffs, and repeat conversations?
- Are base fees, minimums, included usage, overages, upgrades, and top-ups itemized?
- Do credits expire, roll over, or require a paid capacity pack?
- Are tokens, telephony, SMS, premium models, integrations, or external providers charged separately?
- Is human fallback and quality review included in the completed-case estimate?
- Can pilot usage and outcomes be inspected at the conversation, run, action, operation, or outcome grain needed for reconciliation?
Questions to resolve before choosing a vendor
- What exactly triggers a charge: an attempt, successful action, conversation, resolution, outcome, procedure handoff, token, page, file, or duration?
- Can one business case or conversation create multiple charges?
- Are unsuccessful attempts, failed procedures, retries, replayed runs, and error-handler actions billable?
- What is the exact resolution or outcome definition, eligible denominator, and evaluation window?
- How are constrained, abandoned, unanswered, escalated, and repeat cases treated?
- Are telephony, SMS, premium models, integrations, or external providers charged separately?
- Do credits expire or roll over, and what triggers an overage, upgrade, or capacity addition?
- Does the signed quote replace the public rate sheet?
- Can the vendor provide comparable consumption evidence and usage visibility at the level required for the pilot?
- Which fields, source IDs, metric definitions, and pricing versions can be retained for audit?
Turn unanswered items into written quote assumptions or contract clarifications. If a billing unit or cost condition remains unknown, show it as an unresolved scenario instead of silently estimating a conversion. Outcome pricing can simplify comparison when the billable outcome closely matches the buyer’s result, but it is not automatically cheaper or lower risk.
Choose the vendor whose verified contract and pilot produce the best fit across plausible all-in costs, operational exceptions, and required business results, not necessarily the lowest headline rate.
Teams defining an agent’s workload or the validation path before comparing offers can explore AI agent consulting. For workflow-specific billing and data-grain planning, see Zapier automation consulting or Make automation consulting.