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 unused tokens at the end of the cycle (or roll some over, depending on your policy).

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 policy — what happens to unused tokens at cycle end. Three options: hard-forfeit, partial rollover (e.g. 20%), or full rollover with a cap.
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.

We launched at a 1:1 rate and tried to be clever later with a “1 token = $1.20” promo. Members hated it. The clever move was the dumb one — keep tokens at 1:1 and change the allocation instead.

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.

{
  "tiers": [
    {
      "id": "lite", "label": "Lite", "priceMonthly": 49,
      "tokensPerCycle": 80,  "rollover": { "type": "none" }
    },
    {
      "id": "pro",  "label": "Pro",  "priceMonthly": 129,
      "tokensPerCycle": 240, "rollover": { "type": "partial", "fractionPct": 25 }
    },
    {
      "id": "team", "label": "Team", "priceMonthly": 299,
      "tokensPerCycle": 600, "rollover": { "type": "capped", "capPct": 50 },
      "scope": "company"
    }
  ]
}

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.

We tried “block” for two weeks and lost two members. Switched to auto-charge with a $200 cap and have had zero complaints in eight months.

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. All five are on the operator dashboard token report. Bookmark the page; 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.

-- Top-10 consumers + zero-consumers, this cycle
WITH cycle AS (
  SELECT date_trunc('month', now()) AS start_at,
         date_trunc('month', now()) + interval '1 month' AS end_at
),
spend AS (
  SELECT m.id, m.name, m.tier,
         coalesce(sum(t.tokens_spent), 0) AS spent
  FROM members m
  CROSS JOIN cycle c
  LEFT JOIN token_ledger t
    ON t.member_id = m.id
   AND t.created_at >= c.start_at
   AND t.created_at <  c.end_at
  GROUP BY m.id, m.name, m.tier
)
SELECT * FROM spend
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.Save the promo tokens, the loyalty multipliers, and the bonus packs for month 6. Launch boringly — 1:1, three tiers, partial rollover. 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.
• Skipping the warning email.The 80%-consumed warning is the single highest-value email in the token lifecycle. It surfaces the upgrade conversation without you having to start it. If you've disabled it “to keep the inbox quiet,” turn it back on tomorrow.