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.Real estate
Brokerages, agencies, property managers. Outcomes: qualified_lead, appointment_booked (viewing),
escalated_to_operator.
Salon
Salons, spas, wellness studios. Outcomes: qualified_lead, appointment_booked, payment_completed,
escalated_to_operator.
Auto service
Auto-service shops, body shops, dealerships’ service departments. Outcomes: qualified_lead,
appointment_booked (intake), payment_completed, escalated_to_operator.
Restaurant
Restaurants, multi-location groups. Outcomes: appointment_booked (table reservation),
payment_completed (deposit), escalated_to_operator.
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 | 15K / year | Single-location salon, single-shop auto-service, single-restaurant, mid-size real estate office |
| Mid-market | 80K / year | Multi-location salon / restaurant group, regional brokerage, multi-shop auto-service chain |
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:- 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.
- 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.”
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.
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: how Vorel writes outcomes into your CRM (the resolution anchor).
- Product → Voice: voice agent capabilities; per-vertical qualification rules.
- Security → Payments: PCI scope for the
payment_completedoutcome path. - Security → Data retention:
resolution_eventsretention (365 days for billing reconciliation).