Setting up your token economy

A token is a synthetic unit of currency you grant to members as part of their subscription. They spend tokens to book bookable resources: meeting rooms, podcast studios, day passes for guests. They top up when they run out. They forfeit whatever they have not spent at the end of the cycle.

The four mechanics that matter

1. Token rate: the conversion from tokens to NZD. A 1:1 rate is the default; anything else needs explaining and is a tax on member comprehension.
2. Allocation: how many tokens each tier gets per cycle. This is the single biggest lever for perceived value.
3. Forfeit: what happens to unused tokens at cycle end. This one is not a decision you get to make. The monthly refresh sets the pool back to the plan allowance, so an unspent balance is discarded rather than carried forward. There is no rollover setting, partial or otherwise, so design your allocation on the assumption that every cycle starts from the allowance and nothing else.
4. Overage: what happens when members run out mid-cycle. Auto-charge, require top-up, or block until next cycle. Most operators ship auto-charge with a per-member monthly cap.

Even with a 1:1 rate, you still need to set the “resource cost” in tokens for every bookable room. This is the part where people overthink it. The rule is: start with the cash price you'd charge a guest, in tokens, and adjust from there by ±20% based on demand.

Three signals to calibrate against

• Guest day-pass parity. If a guest day-pass is NZ$45, a member day pass should cost ~45 tokens. Members feel they're getting the same value, but paying via their bundle rather than cash.
• Room demand curve. Pull the last 90 days of bookings per room. The top 25% utilisation rooms get +20% on token cost; the bottom 25% get −20%. Calibration nudges members toward your spare capacity.
• Member sticker shock. Round to numbers members can hold in their head. Don't price a meeting room at 37 tokens. Price it at 40. Round to the nearest 5 for hour-rate resources, 10 for half-day, 25 for full-day.

{
  "tokenRate": { "perDollarNZD": 1.0, "rounding": 5 },
  "resources": [
    { "id": "meeting-room-atrium",  "label": "Atrium",  "tokensPerHour": 60 },
    { "id": "meeting-room-forum",   "label": "Forum",   "tokensPerHour": 48 },
    { "id": "studio-podcast",       "label": "Studio",  "tokensPerHour": 36 },
    { "id": "day-pass-guest",       "label": "Day pass","tokensPerDay":  45 }
  ],
  "demandAdjustment": { "highUtil": 1.20, "lowUtil": 0.80 }
}

The above is read-only configuration. In LiteHQ this lives underbooking_settings.rate_card on the company row and is editable from the operator dashboard. Changes take effect on the next booking, never retroactively, by design.

The allocation is the number of tokens you grant each tier per cycle. Three principles: every tier should “feel free” for at least the first week, the top tier should never run out under normal usage, and the gap between tiers should be meaningfully bigger than the price gap.

The three-tier model that works

1. Lite (entry): 80 tokens / month. Covers 1 day-pass and a couple of short meeting room slots. Designed for the “I might use the space once or twice” member.
2. Pro (mid): 240 tokens / month. Covers a few full days plus regular meeting room time. The 3x bundle vs Lite is bigger than the 2x price differential, so members tier up quickly.
3. Team (top): 600 tokens / month, shared across the company. Heavy users + occasional guests get bundled together. Use the shared pool to lock in larger deals.

Write the three numbers down before you touch the product. LiteHQ has no tier-import file, so this is a worksheet for your own planning, not something you upload: you enter each allowance on the rate plan itself, and the pool is shared at the company level.

Tier   Price/month   Tokens/cycle   Pool
----   -----------   ------------   ----------------
Lite   $49            80            per member
Pro    $129          240            per member
Team   $299          600            shared by company

Unspent tokens are forfeited at the monthly refresh.
There is no rollover, so size each tier for a single cycle.

Overage is what happens when a member runs out of tokens mid-cycle. You have three choices, and each has a different effect on member experience and on your AR.

The three overage policies

• Auto-charge (recommended). Once tokens hit zero, every additional booking is billed to the member's card at the cash rate. Set a per-member monthly cap (default: NZ$200) so members never get a surprise bill larger than their tier price.
• Required top-up. Member has to buy a top-up pack (e.g. 50 tokens for NZ$50) before booking. Lower default trust; higher predictability for finance.
• Block. Member cannot book until the next cycle. Brutal but cheap; appropriate for non-paying trial tiers only.

For auto-charge, integrate with Stripe Connect (the platform charge model). KARO-222 is the playbook reference for how Xero treats the GST line item. TL;DR: per-line TaxType (OUTPUT2 for Booking Fee, NONE for Stripe Fee), no standalone GST line, ever. If you reintroduce one, Xero will silently overcharge your members by 15%.

Once tokens are live, you watch five numbers. The tokens page in your workspace gives you some of them directly: pool status, tokens issued and used year to date, and the pool balance as it stands. The rest, including who your heaviest users are, comes from a query like the one below. Either way, check it Monday at 09:00 before standup.

The five Monday numbers

1. Tokens issued this cycle. The total your tier allocations granted. Trending up = growing membership; trending down = churn worth investigating.
2. Tokens consumed this cycle. The total members actually spent. Aim for 60-75% consumption; lower and members feel ripped off, higher and you'll start hitting capacity.
3. Overage revenue. Cash from auto-charges. Should be 5-15% of subscription MRR; outside that range and your allocation is mis-tuned.
4. Top-10 consumers. The members spending the most tokens. Half of them are upgrade conversations, the other half are champions worth thanking.
5. Zero-token members. Members who've consumed zero tokens this cycle. Three weeks at zero is a churn risk; flag for outreach.

-- Heaviest consumers this cycle, by company.
-- Spend is stored as negative 'usage' rows, so negate the sum.
WITH cycle AS (
  SELECT date_trunc('month', now()) AS start_at,
         date_trunc('month', now()) + interval '1 month' AS end_at
)
SELECT c.name,
       c.credit_balance,
       coalesce(-sum(t.amount), 0) AS spent
FROM companies c
CROSS JOIN cycle cy
LEFT JOIN token_transactions t
  ON t.company_id = c.id
 AND t.type = 'usage'
 AND t.created_at >= cy.start_at
 AND t.created_at <  cy.end_at
WHERE c.deleted_at IS NULL
GROUP BY c.id, c.name, c.credit_balance
ORDER BY spent DESC
LIMIT 10;

Four mistakes show up in nearly every operator's first token rollout. Catch them before they catch you.

The four to avoid

• Pricing “cleverly” on launch. Bonus packs, loyalty multipliers and promo tokens are all manual adjustments today, so every clever idea is someone's recurring admin job. Launch boringly: 1:1, three tiers, forfeit at cycle end. Cleverness on day one is debt you'll pay back forever.
• Forgetting GST. Tokens are vatable. KARO-222 covers the Xero side: per-line TaxType, no standalone GST line. The operator dashboard configures this correctly out-of-the-box; don't override it.
• Retroactive changes. Changing token costs retroactively is the fastest way to break member trust. Token changes ALWAYS apply forward; if a member booked at 40 tokens, that booking stays at 40 tokens even if you re-price the room to 50.
• Assuming members get a low-balance warning. They do not. LiteHQ sends nothing when a balance runs down, so the first signal a member gets is a booking they cannot make. Until that email exists, the Monday check below is the warning system, and the upgrade conversation is one you have to start.