💰 Billing & Metering

Bill 70,000 Restaurants.
Hold Nothing.

Every Restaurant CRM CFO asks the same two questions in the same meeting: how do I bill my franchisees, and how much of my customers' data do you hold? Both answers come from the same primitive.

🔑 The Primitive

Every execution is stamped with three fields

That's the entire billing surface. Everything else — the invoice, the reconciliation, the per-franchisee report — is derived from it.

app_namewhich restaurant / brand the action belongs to
user_idwhich logged-in user triggered the workflow
uidyour own reference — an opaque mapping only you can resolve
🏷️

Per-execution metering

Every workflow run is stamped with app_name, user_id, and uid. That's the entire billing surface — a two-column join, not a data warehouse.

📋

Invoice-shaped export

The metering dashboard exports columns your CFO already uses: app name, restaurant name, executions, async runs, retention days, billing period. It's the same shape as the existing franchise invoice.

🔒

Zero data custody by default

The runtime holds a reference, not the data. The uid is an opaque identifier only the CRM knows how to resolve. No PII, no order history, no menu, no pricing.

🚪

No billing lock-in

The moment the CRM outgrows the built-in attribution, they point their own finance stack at the metering export and stop paying the attribution fee. The runtime is designed to lose that business.

🎯 The Four Questions

What your CFO and CISO actually ask

"How do I bill my franchisees for this?
Every execution carries app_name and user_id. The metering export drops directly into your existing franchise invoice. You build an invoice template, not a billing system.
"How much of my customers' data do you hold?
Almost none. We hold an opaque uid — a reference that only you can resolve. Your customer profiles, order history, menu, and pricing never leave your database.
"What if I want to build my own billing later?
Good. The runtime is designed for it. The moment you have your own billing system, point it at the metering export and stop paying the attribution fee. We're not here to own your finance stack.
"What happens if I leave Sageion tomorrow?
Nothing to migrate. Your users exist. Your data exists. Your billing system exists. The runtime was routing, not storing. You turn it off.
🔒 Custody Boundary

What the runtime holds — and what it doesn't

✅

What the runtime holds

  • The opaque uid reference (a mapping only you can resolve)
  • The app_name attribution tag
  • The execution count, timestamp, and duration
  • Async workflow state (encrypted, with TTL)
  • Encrypted auth tokens (never plaintext)
❌

What the runtime never holds

  • Customer names, emails, or phone numbers
  • Order history or menu contents
  • Pricing, discounts, or policy data
  • API request or response bodies (default)
  • Plaintext credentials or session tokens
Default retention: zero. API requests and responses are not stored unless the CRM explicitly opts in per-API. Session history is opt-in and lives in the CRM's own storage, not Sageion's.
🚪

The runtime is designed to lose your billing business

The moment your CRM has its own billing system, you should stop paying Sageion for attribution. Point your finance stack at the metering export, and we'll get out of the way. There's no contractual bundling, no data portability puzzle, no migration project. The primitive is designed for exit — because a Restaurant CRM should never be locked into a billing layer they don't want.

See the metering export in a live demo

Book a 30-minute call and we'll walk your CFO through the exact invoice shape, the custody boundary, and the exit path. No commitment, no procurement cycle.

Book a Demo →See Pricing