Numbers only help when they are read on a rhythm and acted on by rules agreed in advance. This page is that plan. The numbers come from Metrics; the fixes that make them trustworthy are in Optimizations.
Principles
- One number at the top. Collected revenue per week. Every other metric earns its place by explaining it.
- Baselines before targets. No target is invented. We measure first, then set targets from what we measured.
- Compare with yourself. A number is read against last week and against its own 4-week median — not against a guess.
- Decide by rule. The rules below say what to do when a signal fires, so the meeting is about action, not opinions.
- One change at a time. Change one thing per lever, run it at least two weeks, and write down what happened.
The rhythm
Daily — 5 minutes, desk lead
Run the automation health query. Verify every Bankak transfer waiting on bookings and tickets, close yesterday's open visits, and answer every enquiry still NEW.
Weekly — Monday, 30 minutes, the team
Fill in the scorecard below for the week that just ended. Mark each line as up, flat or down against its 4-week median, and apply the decision rules to anything that fired.
Monthly — first Monday, 1 hour, leadership
Look at the revenue mix by stream, retention, package use, office occupancy and lost demand. Close last month's experiments and choose at most two for the coming month.
Weekly scorecard
Copy this table into the weekly notes. Each line names the query that fills it.
| Metric | This week | Last week | 4-week median | Query |
|---|---|---|---|---|
| Collected revenue (SDG) | collected-revenue.sql | |||
| Active customers / new | customers.sql | |||
| Booking requests / confirmed % | booking-funnel.sql | |||
| Lost demand (SDG) | lost-demand.sql | |||
| Tickets sold / fill % | event-fill.sql | |||
| Registrations / waitlisted | registrations.sql | |||
| Enquiries / stale | enquiries.sql | |||
| Café orders / average ticket | cafe-weekly.sql | |||
| Café minutes to ready | cafe-weekly.sql |
Baselines first
For the first four weeks, fill in the scorecard without setting any targets. At the end of week 4, each metric's median becomes its baseline. A target is then the baseline plus the step the team commits to — written down, with a date.
Decision rules
A signal fires when a metric is worse than its 4-week median two weeks in a row. Then the rule says where to look and what to try.
| Signal | Likely cause | Lever | Should move |
|---|---|---|---|
| Revenue down | One stream fell | Read the stream split; apply that stream's rule | Collected revenue |
| One stream above half of revenue | Dependence on a single stream | Promote the weakest stream that has spare capacity | Stream mix |
| New customers down | Fewer people discovering Space | Run a free event or open day; post with tagged links | New customers |
| Room confirmation down | Slow follow-up, or price | Verify and confirm within the day; review the room rate | Confirmed %, lost demand |
| Lost demand up for one product | Payment friction or a short hold | Send the Bankak details on WhatsApp at request time; review ticketHoldMinutes | Lost demand |
| Free event waitlist above a tenth of capacity | Demand beyond the room | Add a second session or a bigger room | Seats taken, new customers |
| Event show-up down | No reminder | WhatsApp reminder the day before | Show-up % |
| Package use down | Customers drifting away | Call customers with low use before expiry | Retention, renewals |
| Retention down | The space isn't meeting a need | Ask the people who stopped coming why | Retention |
| Stale enquiries above zero | No owner | Name an owner per topic; answer within a day | Stale enquiries |
| Café minutes to ready up at peak | Not enough hands at the peak hour | Prep before the peak, or add staff at that hour | Minutes to ready |
| Café QR share down | Guests don't notice the table QR | Move or enlarge the QR cards; staff mention them | QR % |
Experiments
Every change the team makes to move a number is written down before it starts:
Hypothesis: WhatsApp reminders the day before raise event show-up.
Change: Staff send the reminder link to every registration, 24 hours ahead.
Metric: show_up_pct (registrations.sql)
Baseline: 4-week median before the change
Duration: 2 weeks, or 3 events — whichever is longer
Result: the metric after, next to the baseline
Decision: keep · change · dropKeep experiments as GitHub issues in the space repository, so the result and the decision stay next to the code that made the change.
The first 90 days
| Days | Build | Read and decide |
|---|---|---|
| 1–30 | Fix the first three defects; record where people come from; tag every link Space posts | Run the daily and weekly rhythm; collect baselines |
| 31–60 | Record transition times; count WhatsApp taps | Set targets from the baselines; run the first two experiments |
| 61–90 | Add page-view analytics | Compare revenue by channel; put more into the channels that bring paying customers, less into the rest |
Until where people come from is recorded, the data can say what happened — but not which post, partner or channel caused it. That one change is what turns these numbers into growth decisions.