> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Pricing

> Outcome-based pricing. Per-vertical published rate cards. Audit-able resolution definitions backed by a deterministic classifier, not vendor opacity.

Vorel publishes per-vertical rate-card pages anchored to a transparent outcome model. The model and the resolution definitions are public: no NDA, no sales call required to understand how you're charged. Published per-outcome bands are finalized per pack at sign-off.

This page links to the per-vertical cards, explains the outcome model that anchors the pricing, and clarifies which ACV bands Vorel sells into.

## Outcome-based pricing: how it works

Vorel charges per **resolved outcome**, not per minute of voice, not per token of LLM, not per call. The outcome is determined by a deterministic classifier that runs after every conversation closes. You pay for outcomes that happened; you do not pay for conversations that did not resolve. Invoicing is **manual today**: your operator generates the invoice from the recorded resolution events and the per-conversation ledger, against your agreed rate card. There is no self-serve checkout or usage-metered card-on-file billing.

The five outcomes are sealed by an architectural decision record and frozen from this point forward (any change is a load-bearing architectural decision visible in version history):

| Outcome                     | What it means                                                                                      |
| --------------------------- | -------------------------------------------------------------------------------------------------- |
| **`qualified_lead`**        | Lead captured with required slots populated; conversation closed with the lead written to CRM.     |
| **`appointment_booked`**    | Appointment held in your booking system / CRM.                                                     |
| **`payment_completed`**     | In-conversation card payment acknowledged within the booking-hold window (PCI-enabled packs only). |
| **`escalated_to_operator`** | Conversation routed to a human via Slack / email / inbox per the tenant's handoff rules.           |
| **`closed_no_resolution`**  | No outcome reached: wrong number, spam, off-topic, customer hung up early.                         |

`closed_no_resolution` is the default. **No revenue accrues to Vorel on a `closed_no_resolution` outcome.** The classifier runs the same way for every conversation; the resolution is determined by the data Vorel collected and wrote, not by who is reading the dashboard.

The classifier code is shared across every tenant. Auditors and procurement teams can trace the exact deterministic logic that maps a conversation onto an outcome: no vendor opacity, no "we look at it manually," no per-customer pricing rules buried in a contract appendix.

## Per-vertical rate cards

Each pack has its own rate-card page on the Vorel app, with the per-outcome bands, an audit-trail link to the resolution definitions, and the canonical pricing band the pack targets. Four operator-led packs publish a rate-card page today; the remaining packs are gated on first signed deal.

<CardGroup cols={2}>
  <Card title="Real estate" icon="house" href="https://app.vorel.ai/pricing/real_estate">
    Brokerages, agencies, property managers. Outcomes: qualified\_lead, appointment\_booked (viewing),
    escalated\_to\_operator.
  </Card>

  <Card title="Salon" icon="scissors" href="https://app.vorel.ai/pricing/salon">
    Salons, spas, wellness studios. Outcomes: qualified\_lead, appointment\_booked, payment\_completed,
    escalated\_to\_operator.
  </Card>

  <Card title="Auto service" icon="car" href="https://app.vorel.ai/pricing/auto_service">
    Auto-service shops, body shops, dealerships' service departments. Outcomes: qualified\_lead,
    appointment\_booked (intake), payment\_completed, escalated\_to\_operator.
  </Card>

  <Card title="Restaurant" icon="utensils" href="https://app.vorel.ai/pricing/restaurant">
    Restaurants, multi-location groups. Outcomes: appointment\_booked (table reservation),
    payment\_completed (deposit), escalated\_to\_operator.
  </Card>
</CardGroup>

Each card links to its **resolution-definitions document**, which spells out (to the level of "what fields must be populated on the lead row for `qualified_lead` to fire") exactly what triggers the outcome classifier. This is the auditable artifact procurement teams use to compare Vorel against vendors that price by opaque dimension (Sierra's per-task, Decagon's per-resolution-as-defined-by-Decagon).

## ACV bands

Vorel sells into two named ACV bands. Each pack's published rates are tuned to fit one or both bands depending on conversation volume:

| Band           | Annual contract value  | Typical pack scale                                                                              |
| -------------- | ---------------------- | ----------------------------------------------------------------------------------------------- |
| **SMB**        | **$5K – $15K** / year  | Single-location salon, single-shop auto-service, single-restaurant, mid-size real estate office |
| **Mid-market** | **$15K – $80K** / year | Multi-location salon / restaurant group, regional brokerage, multi-shop auto-service chain      |

Vorel does not sell into the enterprise band where Sierra (\$150K+ floor) and Decagon (enterprise minimums) operate. Our pricing model and our operator-led onboarding model are tuned for the SMB-to-mid-market segment that those competitors structurally exclude.

## Why published rate cards, not "contact us"

Sierra protects margin via per-customer opacity. Decagon defines resolution per-customer in private contracts. Both have structural reasons not to publish: they want pricing power at the negotiating table and they don't want their competitors to undercut them on a public list.

Vorel publishes for two reasons:

1. **Procurement signal.** A buyer comparing Vorel against three opaque-pricing vendors immediately recognizes which vendor lets them estimate cost before the sales call. Procurement and finance teams strongly prefer this.
2. **Audit-able resolution.** Published rate cards force the resolution definition to be public. The resolution definition forces the outcome classifier to be deterministic. The deterministic classifier means you and Vorel agree on what counts, not "Vorel decides what counts."

This is one of the five stacked moats Vorel commits to architecturally: published per-vertical rate cards with audit-able resolution. Sierra cannot match this with a contract addendum; matching it means publishing their own opacity.

## What about volume discounts?

For mid-market tenants with high call volumes, Vorel operators negotiate volume tiers on top of the published rate card. The negotiation has a published floor (your tier discount cannot drop a per-outcome rate below the floor we publish), so even a 50%-volume-discounted contract still derives from the same audit-able numbers. The floors are documented per-pack.

## Custom verticals

If your business does not fit one of the four published packs (legal intake, generic SMB, healthcare-clinic, etc.), Vorel's operator works with you during kickoff to:

* Pick the nearest published pack as the rate anchor.
* Configure the resolution definitions for any pack-specific slot requirements.
* Document the per-tenant rate sheet as a contract attachment.

Even custom-vertical pricing derives from the same outcome model: `qualified_lead`, `appointment_booked`, `payment_completed`, `escalated_to_operator`, `closed_no_resolution`. The classifier is shared; the rate per outcome is the variable.

## Related docs

* [Product → CRM](/product/crm): how Vorel writes outcomes into your CRM (the resolution anchor).
* [Product → Voice](/product/voice): voice agent capabilities; per-vertical qualification rules.
* [Security → Payments](/security/payments): PCI scope for the `payment_completed` outcome path.
* [Security → Data retention](/security/data-retention): `resolution_events` retention (365 days for billing reconciliation).

{/* verified-against: apps/web/src/app/(marketing)/pricing/[pack]/page.tsx — per-vertical pricing pages for real_estate, salon, auto_service, restaurant */}

{/* verified-against: roadmap/workstreams/Q2-WS-CC-rate-cards-published.md — WS-CC ship of 4 per-vertical pricing pages */}