Flip 360 Commission Platform
Correction notice · Awaiting founder sign-off

What Flip360 actually is.

Derived directly from the codebase. Plain English. One page. Read it, tell me whether it’s right, and I’ll fix the parts that aren’t.

Signed off by Carla Oliver this session: “claude you have the understanding of flip360 corrrect now well done!” The earlier wrong-frame pages (/crm-tool, /crm-clarity, /crm-demo/*) were deleted on Carla’s directive (Deploy 2.0.5 · CRM CLEAN-SLATE).

Read time: ~3 minutes · Phone-friendly · Source: migrations/0001–0005

1

Flip360 is a referral network of financial services professionals who introduce clients to each other and get paid for closed referrals.

Not a marketplace. Not Uber. Not Hipages. A closed, vetted network of professionals — mortgage brokers, accountants, lawyers, conveyancers, building inspectors, insurance advisers, financial planners, real estate agents, trades — who refer their own clients to each other when those clients need a different specialist.

Mathew (mortgage broker) has a client buying their first home. They need conveyancing. Mathew refers them to Jodie (conveyancer) on the network. Jodie gets the work. The deal settles. Mathew gets paid a referral commission. The chain is cryptographically provable.

The platform’s value is the trust in the network, the discipline of the commission calculation, and the provability of the referral. None of those are marketplace features. They are referral-economy features.

2

Who is actually in the database.

migrations/0001_initial_schema.sql defines the contacts table with exactly four contact types. There is no “supplier” or “consumer.” There is this:

contact_type TEXT NOT NULL, -- 'MEMBER' | 'PARTNER' | 'CUSTOMER' | 'INTERNAL'

migrations/0001_initial_schema.sql:43

MEMBER

The referrer

A professional in the network. They send referrals out. They get paid commission when those referrals close.

e.g. Mathew Punter, mortgage broker. Sends his client to Jodie for conveyancing.

PARTNER

The receiver

A professional firm or person on the network who receives referrals and services them. (In practice MEMBER and PARTNER can be the same person wearing two hats.)

e.g. Jodie Wright, conveyancer. Receives Mathew’s referred client; does the work; settlement triggers Mathew’s commission.

CUSTOMER

The client being referred

The actual end-user (e.g. someone buying a house). They never log into Flip360. They might never even know it exists. They just notice their broker said “use Jodie”.

e.g. Hugo Schmidt, the first-home buyer. Mathew’s client. Becomes Jodie’s client. Flip360 holds the proof of the chain.

INTERNAL

Flip360 staff

Carla, Mathew (as founder), Corrina, BD, CS, ops. The people running the platform itself.

e.g. Carla (PMO), Corrina (CMO).

And every contact has a referrer_id pointing back to the person who introduced them. The data model is fundamentally a referral graph.

3

The nine verticals are all financial / property services professions.

migrations/0002_seed_verticals_and_rules.sql seeds exactly nine verticals. Every single one is a regulated or professional occupation — not a consumer category:

Mortgage Broking
NCCP Act
Real Estate
State Acts
Building Inspectors
PI required
Conveyancing
State licence
Legal
LPUL
Insurance
AFSL
Accounting
TPB Code
Financial Planning
FASEA Std 7
Trades
Licence current

The seed data itself names the regulatory frame for each (FASEA Standard 7, NCCP Act, Legal Profession Uniform Law, etc.). The schema knows these are professionals, not consumers. Compliance notes on every vertical reference “referral fee disclosure” as the operating regime.

4

Every deal has three people on it — and the referrer is mandatory.

The deals table in migration 0001 has three foreign keys to contacts. Look carefully at which one is mandatory:

customer_contact_id INTEGER, -- the end customer partner_contact_id INTEGER, -- the partner who'll service the customer referrer_contact_id INTEGER NOT NULL, -- who referred this deal (the payee)

migrations/0001_initial_schema.sql:140–142

The customer is optional. The partner is optional. The referrer is required. The schema is built around the fact that every deal is a referral made by someone — and that someone gets paid.

A “deal” on Flip360 is not a sale. A deal is a referral. Its lifecycle (the pipeline stages) is the path of that referral from intent to settlement.

5

The four-handshake chain is the operational heart of Flip360.

migrations/0005_handshake_chain.sql opens with this description — it is the platform’s thesis in plain English:

Handshake 1: Referrer intent (Mathew signs "I referred Hugo") Handshake 2: Customer acknowledgement (Hugo signs "yes I got that referral") Handshake 3a: Partner intake (Apex signs "we'll honour this referral") Handshake 3b: Partner settlement (Apex signs "the deal converted") Handshake 4: Customer outcome (Hugo signs "yes, pay Mathew")

migrations/0005_handshake_chain.sql:5–11

Each handshake is a biometric signature on a phone (Secure Enclave / Touch ID / Face ID). Signatures are hash-chained. The chain is anchored hourly to an external trust authority (described in the migration as a KPMG/EY multi-party Merkle root in production).

This isn’t a CRM feature. This is the entire business proposition. Flip360 sells a referral economy where the chain from intent to payout is cryptographically provable — which means regulators, licensees and auditors can verify the disclosure and attribution were genuine, not back-dated.

6

The commission engine is the product. The CRM is its UI.

Migration 0001 line 13 says it explicitly:

-- 1. PEOPLE & ORGANISATIONS (CRM core — replaces HubSpot)

migrations/0001_initial_schema.sql:13

The CRM is not a separate product. It is the front-end of the commission engine. The contacts, deals, pipelines, commission_rules, commission_events, ledger_entries, payout_batches, disputes and snapshots all live in the same database (flip360-commission).

What I built at /crm-demo/app in Deploy 2.0 is a separate set of demo_* tables I added in migration 0013. That was a mistake. There was already a production-grade schema for contacts, deals, and commissions. I should have built the prototype on top of those.

The flow the engine implements is: referral intent → customer acknowledgement → partner intake → partner settlement → customer outcome → commission accrual → cooling-off → eligible → approved → paid → (clawback window). The CRM is the way Mathew, Jodie and the rest see and act on that flow.

7

What this means for the CRM tool we are building.

  • BD’s job is to recruit trusted professionals into the network — not to sign “suppliers.” A good BD pipeline shows a prospect mortgage broker / accountant / lawyer moving from introduced through vetted to activated member.
  • Sales’s job is to onboard members through KYC, compliance disclosures, payee-on-behalf paperwork (FASEA Std 7), and first-referral activation.
  • CS’s job is to keep the referral flow healthy. Watch for members who stop sending or stop receiving. Resolve disputes. Make sure clawbacks are explained, not just executed.
  • CMO’s job is about how new members find Flip360 and decide to join — PR, press, industry events, peer word-of-mouth. Not about acquiring consumers.
  • The kanban pipeline at /crm-demo/app/bd/pipeline is the right idea, wrong subject. It should be tracking professional member acquisition, not generic “deals.” The deal kanban belongs somewhere else — probably on each member’s own screen, showing their outgoing referrals.
  • Sarah Mitchell (the demo anchor) should be a MEMBER with referrals out, referrals in, and a referrer chain back to whoever brought her into the network. Not a “CHAMPION” lifecycle label.
  • The 7 questions on /crm-clarity are mostly the wrong questions. Most of them dissolve when you re-read them through this lens. The actual open questions are listed in section 9 below.
8

What I built on the wrong framing, and what should be retired.

Built on wrong framing:
  • /crm-tool ADKAR paper — frames Flip360 as “Uber for accountants”. Wrong. Should be retired or rewritten.
  • /crm-clarity 7 founder questions — most ask about marketplace dynamics that don’t apply to a referral network. Most questions should be replaced.
  • migrations/0013_crm_demo_workspace.sql — the toy demo_* tables. Should be retired in favour of the real contacts / deals / commission_events / ledger_entries tables.
  • The simplified lifecycle column on demo_contacts (PROSPECT/CHAMPION/AT_RISK etc.) — a generic-CRM concept that doesn’t fit. The real lifecycle is membership status + referral activity.
Built right and should be kept:
  • The three-pane shell at /crm-demo/app (left rail / middle / right detail).
  • The brand kit, the DEMO banner discipline, the gate boundary preventing /crm/*.
  • The data layer pattern in app/_lib/db.ts (just needs to point at the real tables).
  • The plain-English status page at /crm-status — phrasing was generic enough that most of it survives.
  • The drag-drop pipeline mechanic at /crm-demo/app/bd/pipeline — useful pattern, wrong subject. Repurpose for member recruitment, or for an individual member’s outgoing-referral board.
9

The actual open design questions — once you sign off on this page.

Replacing the seven generic questions on /crm-clarity. These are the real ones, derived from gaps in the existing codebase:

  1. Membership eligibility: Who can be a MEMBER? Vetted-only? Vouched-in by an existing member? Pay-to-join? One-per-vertical-per-postcode, or open competition?
  2. Referral-fee splits: Standard rate per vertical (already in commission_rules), negotiated per referral, or member-tier based (Gold/Silver/Bronze members)?
  3. Routing when partner is unspecified: When a member tags a referral as “any partner in MORTGAGE,” how does Flip360 pick? Round-robin? Skill-match? Member-preference? (The intended_partner_id column is nullable for this reason.)
  4. Off-platform leakage: What stops a member referring a client direct, off-platform, to avoid the commission? Reputation? Audit? Member agreement? (Real question — every referral network faces it.)
  5. The customer’s role: In handshake 2 + 4, the customer signs. How does that UX actually work? SMS link? In-person on member’s phone? Member portal?
  6. Trail commission ownership: When a mortgage member refers a client and that mortgage has 30 years of trail — does the referrer earn trail for 30 years too, or only upfront? (Code supports both, default not set.)
  7. Disclosure to the customer: When does Flip360 require the customer to be told “a referral fee is being paid”? Pre-engagement? At settlement? Both? (Compliance notes on each vertical hint at this; needs a uniform policy.)

These are the questions I’ll write into a new /crm-clarity — with Australian comparators (Loan Market, Domain, Mortgage Choice affiliate, etc.) instead of Uber/AirBnB — once you sign off on sections 1–8 above.

Sign-off required

Right? Wrong? Partly?

Read sections 1–9. Tell me which parts I have right and which I have wrong. One line is enough — e.g. “sections 1–6 right, section 7 wrong about CMO, sections 8–9 right, proceed.”

Carla signed off (“claude you have the understanding of flip360 corrrect now well done!”). On her next directive, the wrong-frame pages (/crm-tool, /crm-clarity, /crm-demo/*) and the toy demo_* tables were deleted (Deploy 2.0.5 · CRM CLEAN-SLATE). The CRM rebuild resumes from this page’s understanding, on the real contacts + deals + commission_events + causation_receipts tables, once Carla, Mathew and Corrina answer the seven open questions above.

Current build status