Extracted from PPN OG Thread23 March 20260 decisions recorded
Purpose: This document captures every significant decision made during the PPN design phase — what was decided, why, and what it affects downstream. It exists so that new chat threads and future collaborators can understand the reasoning behind the system without needing to read the full OG Thread. Treat it as authoritative. If a decision is revisited, update this log.
🔍
01
Schema & Data Design
0
S-01
Contacts table as a separate entity from Suppliers
SchemaSoftr-readiness
▶
Decision
Create a dedicated Contacts table separate from Suppliers. Multiple contacts can link to one Supplier via Supplier_ID FK.
Reason
Softr requires a dedicated user directory table — one row per login email. A single Portal_Email field on Suppliers cannot support multiple staff accounts per business or granular role-based access.
Affects
Tally form field mapping (must create Contact record alongside Supplier), Make scenarios must write to both tables, Softr login configuration in Phase X.
S-02
First_Name + Last_Name instead of Full_Name on Contacts
SchemaEmail
▶
Decision
Split Full_Name into separate First_Name and Last_Name fields on the Contacts table.
Reason
Make email templates need to address recipients by first name only ("Hi Sarah,"). A single Full_Name field requires string manipulation in every scenario. Separate fields are cleaner for personalisation and for Softr display blocks.
Affects
All Make email scenarios use {{Contact.First_Name}} for salutation. Concatenate both fields when a full name is needed. ERD updated to v2 to reflect this change.
S-03
PPN House as the default Referred_By_Supplier
SchemaBusiness logic
▶
Decision
Create a "PPN House" record in the Suppliers table. Set it as the default value for Referred_By_Supplier on all Events where no external supplier referred the enquiry.
Reason
Commission split formulas need to run identically for all quotes — no special-case code for "no referral." With PPN House as the default, Has_Referral = FALSE simply means the 4% referral share goes to PPN rather than a third party. One formula, no branching.
Affects
Referrals table, all commission formulas on Quotes and Payment_Schedules. PPN House record must exist in Airtable before any Quote records are created.
S-04
[Ref] Outcodes as a lookup table with Gibbs CSV data
SchemaMake
▶
Decision
Build a [Ref] Outcodes reference table in Airtable. Populate with 2,857 rows from the Gibbs/uk-postcodes GitHub CSV. Fields: Outcode (PK), Latitude, Longitude, Town, Region, Country.
Reason
Distance-based supplier matching requires lat/long at the postcode level. Pre-aggregated outcode-level data is sufficient (no need for full postcode granularity), freely licensed, and directly importable to Airtable. Avoids the cost and complexity of a live postcode API.
Affects
Suppliers and Events both have an Outcode FK to this table. Make extracts the outcode from Postcode_Raw using a formula, then links the record. Haversine distance calculation in the Match Engine uses lat/long from this table.
S-05
Commission tracked per payment instalment, not as a lump sum
SchemaBusiness logic
▶
Decision
Commission is calculated and recorded on each row of Payment_Schedules as the payment falls due — not as a single total on the Quote.
Reason
Events have multi-stage payment structures (Deposit, Interim, Balance). PPN's commission obligation is tied to when the supplier actually receives money. Tracking per instalment enables accurate cash flow reporting and prevents commission being "collected" before the supplier is paid.
Affects
Payment_Schedules has full commission formula fields (Commission_Due, PPN_Overhead, Referral_Share, PPN_Net). Commission Tracker view in Airtable filters by Commission_Paid = FALSE. Settlement Payment_Schedule is created dynamically only after Honesty Loop confirms the event happened.
S-06
Contact_Stage field added to Contacts
SchemaEmail
▶
Decision
Add a Contact_Stage single-select field to the Contacts table with values: Waitlist / Onboarding / Active / Inactive.
Reason
Lou has pre-launch email workflows for waiting list signups that are distinct from registered suppliers. Make needs to distinguish between these stages to route emails correctly — a waitlisted contact should not receive the same onboarding flow as an active supplier.
Affects
Make pre-launch scenarios filter by Contact_Stage = Waitlist. The "Network Is Now Live" broadcast targets this segment. ERD updated to v3.
S-07
Introduction_Date and Protection_End_Date added to Referrals
SchemaBusiness logic
▶
Decision
Add Introduction_Date and Protection_End_Date to the Referrals table. Protection_End_Date = Introduction_Date + 4 years.
Reason
Lou's supplier terms include a 4-year tapering commission (10/8/6/4%) for repeat bookings between the same event organiser and supplier after an introduction. PPN needs a permanent record of when the introduction was made and when the protection expires to enforce this contractually and to send bi-annual reminder emails.
Affects
Applies to repeat-event bookings only. One-off events remain at standard 10%. Make scheduled scenario (May and October) queries Referrals where Protection_End_Date is in the future. R5 email template sends tapering schedule reminder. ERD updated to v3.
S-08
Supplier_ID lookups on all child tables for Softr filtering
SchemaSoftr-readiness
▶
Decision
Add a Supplier_ID lookup field to Quotes, Payment_Schedules, Reviews, and Activity_Log — not just a linked record field.
Reason
Softr's filtering mechanism works on text/number fields, not on linked record fields. A supplier logged into the Softr portal can only see their own records if there is a plain Supplier_ID text field to filter against. Linked record fields alone are not filterable in Softr.
Affects
Every child table has a lookup chain of max 2 hops (confirmed safe). Must be built into the schema from day one — retrofitting is painful. No functional impact until Softr is configured in Phase X.
S-09
Insurance expiry field removed — not PPN's responsibility
SchemaProduct
▶
Decision
Do not add Insurance_Expiry_Date to the Suppliers table. Remove the related email template from the tracker.
Reason
Insurance validity is a matter between the supplier and their event clients, not PPN's liability to monitor. Adding this field would imply PPN is vouching for supplier compliance, which is outside the platform's scope and creates potential legal exposure.
Affects
Email template O5 (Insurance Expiry Warning) removed from the workspace. No field added to Suppliers table. Removes one Make scheduled scenario from the build scope.
S-10
Supplier referral tracking via unique Referral_Code and URL parameter
SchemaMakeProduct
▶
Decision
Each supplier is assigned a unique Referral_Code field on the Suppliers table (auto-generated at onboarding). Suppliers share a referral URL e.g. prepitched.co.uk/refer?ref=SMITH24. The Event Request form captures the ref parameter in a hidden Referral_Code_Used field. Make looks up the matching Supplier on submission and writes the linked record to Referred_By_Supplier. A separate open-text How_Did_You_Find_Us field is also on the form as a fallback and marketing insight capture. Referral_Code will be customisable by suppliers via the Softr dashboard in Phase X.
Reason
The original schema assumed Referred_By_Supplier would be populated directly by the organiser, but suppliers cannot be exposed publicly for privacy and business reasons. A URL-based referral code solves this: the organiser never sees supplier names, the supplier just shares a link, and the attribution is captured automatically. The How_Did_You_Find_Us fallback replaces the idea of asking the organiser to name a supplier directly, while also capturing useful marketing data.
Affects
Suppliers table: new Referral_Code field. Events table: new Referral_Code_Used (hidden form field) and How_Did_You_Find_Us (open text) fields. Referred_By_Supplier description updated — now populated by Make lookup, not manual entry. Make Event submission scenario gains a lookup step. Supplier onboarding email (O1) should include the supplier's unique referral link. Phase X: Softr dashboard allows code customisation. Decided: 24 March 2026.
02
Commission & Business Logic
0
B-01
10% total commission, split three ways
Business logicSchema
▶
Decision
PPN takes 10% of every payment instalment. Split: 2% PPN overhead, 4% PPN profit (or 8% with no referral), 4% to referring supplier when an external referral exists.
Reason
Standard marketplace commission rate for UK event services. The split incentivises suppliers to refer overflow enquiries (they earn 4% passively) while keeping PPN's net revenue predictable. PPN Overhead covers operational costs regardless of referral status.
Affects
All commission formula fields on Quotes and Payment_Schedules. PPN House default makes the formula run identically whether or not a referral exists. The 4-year tapering (10/8/6/4%) only applies to the PPN profit share on repeat bookings — the overhead stays at 2%.
B-02
4-year tapering commission applies to repeat events only
Business logicSchema
▶
Decision
The 4-year tapering commission schedule (Year 1: 10%, Year 2: 8%, Year 3: 6%, Year 4: 4%) applies only when the same organiser re-books the same supplier introduced through PPN. One-off events always pay the standard 10%.
Reason
The tapering reflects reducing PPN's claim on a relationship as it matures. After 4 years the introduction value has been fully amortised. Applying it to one-off events would unnecessarily complicate the formula and reduce PPN revenue with no relationship-building benefit.
Affects
Referrals table stores Introduction_Date and Protection_End_Date. Make calculates which commission year applies when a repeat booking is confirmed. One-off event quotes use the standard 10% formula with no year-based logic.
B-03
Honesty Loop: supplier self-reports via CC alias
Business logicMake
▶
Decision
Suppliers send their quotes directly to organisers in their own email client, cc'ing confirm@prepitched.co.uk. Make monitors this alias, parses the PPN-{Event_ID}-{Supplier_ID} reference code from the subject, and sets the Quote to Submitted.
Reason
PPN is a matching service, not a communication intermediary. Routing quote emails through PPN would add friction, delay communication, and raise legal questions about being a party to the contract. The CC approach keeps PPN out of the quote content while maintaining audit evidence.
Affects
Make Scenario 6 watches the confirm@ inbox. CC_Reference_Code formula on Quotes generates the parseable reference. Gmail must be connected via OAuth with the confirm@ alias set up as a forwardable address. Honesty Loop escalation ladder fires if no CC is detected post-event.
Layer 1 (build now): Full schema, scenarios 1–6, Event Request and Supplier Onboarding forms. Layer 2 (stub now): Reviews, Activity_Log, Subscriptions tables created but not automated. Layer 3 (defer): WhatsApp, Softr portal, score-based discounts.
Reason
11-day window to internal live (2 April). Building everything at once risks missing the deadline and shipping an untested system. The layered approach gets the revenue-critical flow live first, then layers in retention and optimisation features when there is real data to inform them.
Affects
Go-Live Checklist and visual Roadmap reflect this structure. Phase X items in the checklist are marked deferred and excluded from the progress count. WhatsApp removed from pre-launch scope entirely. Softr portal readiness fields are baked into the schema but not activated.
B-05
Supplier score fields built now but suppressed until 3+ reviews
ProductSchema
▶
Decision
Build Supplier_Score and Quality_Flag formula fields in the Suppliers table from day one. Do not surface them in any view or portal until a supplier has at least 3 reviews.
Reason
Score data must accumulate from the first event. Building it later means losing early data and having to backfill. Suppressing until 3 reviews prevents misleadingly low scores from penalising new suppliers who simply haven't been reviewed yet.
Affects
Airtable views and any future Softr portal filter out suppliers with fewer than 3 reviews from score-based sorting. Match Engine score-based priority (Phase X) will use the same field when activated. Exact suppression threshold is an open decision — 3 is the working assumption.
B-06
Tally stays for unauthenticated onboarding permanently
ProductSoftr
▶
Decision
New suppliers always onboard via Tally, even after Softr portal is live. Tally handles unauthenticated first contact. Softr handles everything post-login.
Reason
New suppliers have no login credentials yet — they cannot access Softr. Redirecting them to Softr for signup creates a chicken-and-egg problem. Tally handles unauthenticated submission cleanly and the webhook writes directly to Airtable.
Affects
Tally Supplier Onboarding form is a permanent part of the stack, not a temporary placeholder. The action_base_url Data Store variable controls where authenticated action links point — Tally now, Softr in Phase X — but onboarding always stays on Tally.
03
Make Automations
0
M-01
action_base_url stored in Make Data Store for single-line Softr switchover
MakeSoftr-readiness
▶
Decision
Store the base URL for all email CTA links as a single variable action_base_url in a Make Data Store. All 47 email templates reference this variable for their action buttons.
Reason
When Softr replaces Tally forms for authenticated actions in Phase X, updating one Data Store variable updates every email CTA simultaneously. Without this, switching to Softr requires editing every Make scenario individually.
Affects
Every Make scenario that sends an email with an action button reads from this variable. Phase 1 value: Tally form URLs. Phase X value: Softr portal URLs. Zero scenario rebuilding required at switchover.
M-02
Outcode linking via Make, not Airtable formula alone
MakeSchema
▶
Decision
Airtable formula extracts the outcode text from Postcode_Raw. A Make scenario then searches the [Ref] Outcodes table and writes the linked record ID back to the Supplier or Event.
Reason
Airtable formulas cannot create linked record relationships — they can only compute text values. The two-step approach (formula for extraction, Make for linking) is the only way to get a proper FK relationship that enables the Haversine calculation and Softr geographic filtering.
Affects
Make Scenario 1 handles this on every new or updated Supplier and Event. The Outcode FK must be populated before the Match Engine runs. Formula: IF(FIND(" ",Postcode_Raw)>0, TRIM(LEFT(Postcode_Raw,FIND(" ",Postcode_Raw)-1)), LEFT(UPPER(TRIM(Postcode_Raw)),3)).
M-03
WhatsApp deferred to Phase X — not free, requires Meta verification
MakePhase X
▶
Decision
Remove WhatsApp notification scenarios from the pre-launch build. Fields (WhatsApp_Number, Comms_Preference, WhatsApp_Opted_In) remain in the schema as stubs.
Reason
WhatsApp Business API is not free — Meta charges per-message since July 2025. It also requires a dedicated business phone number and Meta Business verification (1–2 weeks). Neither the number nor the budget has been confirmed. Adding this complexity to the pre-launch build risks delaying the 2 April target for a feature that isn't critical at launch.
Affects
Schema fields remain ready. When activated, Make adds a WhatsApp send step after every email trigger, routing by Comms_Preference. SMS fallback via Twilio. Requires explicit GDPR opt-in captured at onboarding — WhatsApp_Opted_In checkbox on the Supplier form.
M-04
Duplicate event detection via Duplicate_Check_Key formula
MakeSchema
▶
Decision
Create a formula field on Events: UPPER(TRIM(Organiser_Company)) & "-" & Outcode & "-" & TEXT(Event_Date,"YYYY-MM"). Make checks for a matching key on every new Event and sets Duplicate_Flag = TRUE if one is found.
Reason
The same event can be submitted by both the organiser and a supplier referral. Without duplicate detection, PPN would attempt to match the same event twice, potentially sending ITQs to the same suppliers twice. Monthly granularity (not exact date) catches near-duplicates where the date was entered slightly differently.
Affects
Make Scenario 2 runs on every new Event record. Human review (Lou/Katie) required before resolving the flag. A Duplicate Flags view in Airtable surfaces these for review. Phase X: Softr shows a warning to the submitter before the form is submitted.
04
Email System
0
E-01
Email style: Option 3 + Option 6 confirmed
EmailDesign
▶
Decision
PPN emails use: white header background, #124747 forest green title (Playfair Display), #758C85 sage subtitle, #FFC701 gold horizontal bar, white body, #124747 forest green CTA button with white text.
Reason
Option 3 matches the PrePitched website's existing colour palette exactly — the same forest green (#124747) is used in the nav band, and gold (#FFC701) is the accent. Using the same palette gives emails immediate brand recognition without requiring a separate brand design exercise.
Affects
All 47 email templates in the Email Workspace use this style. The "Copy HTML" function in the CMS editor generates production-ready table-based HTML with this styling. Tally form white-labelling should use the same colour palette when confirmed.
E-02
Make variable syntax adopted: {{Contact.First_Name}} format
EmailMake
▶
Decision
All merge variables in email templates use Make syntax: {{Contact.First_Name}}, {{Event.ID}}, {{Quote.Amount}} etc. Lou's existing HubSpot {curly bracket} syntax is converted at template build time, not speculatively.
Reason
PPN is moving from HubSpot to Make + Gmail. The Email CMS (ppn_workspace.html) has a variable inserter that uses Make syntax. Converting Lou's templates en masse risks errors — it's cleaner to convert each template at the point it's being drafted in the CMS.
Affects
Email Workspace variable inserter uses Make syntax. Templates marked with the HS→Make badge in the tracker need conversion when drafted. HubSpot syntax must never appear in a template that is wired into a Make scenario.
E-03
47 templates mapped across 8 groups from combined sources
Email
▶
Decision
The canonical email template set is 47 templates across 8 groups: Pre-Launch, Onboarding, Enquiry & Matching, Quoting, Acceptance, Referrals, Honesty Loop, Billing, Monthly Series (12), and Operational. Source badges (AUTO/LOU/BOTH) track provenance.
Reason
The original 14 automation triggers were a minimum viable set. Lou's email document revealed a much richer set of touchpoints (47 total) including pre-launch workflows, monthly retention series, referral lifecycle emails, and soft compliance messaging. All are now mapped to prevent gaps at build time.
Affects
Email Workspace (ppn_workspace.html) is the single source of truth for all templates. Technical schema automation ledger updated to reference template IDs (E1–E5, Q1–Q5, A1–A4, H1–H4, R1–R5, B1). Monthly series (M1–M12) are manual sends, not automated.
05
Design & Tools
0
D-01
Seamless theme as placeholder — PPN brand not yet defined
Design
▶
Decision
All Seamless deliverables (ERD, schema docs, checklists, hub, email workspace) use the Seamless dark theme as a placeholder. Dark bg #0f1117, surface #181c27, light mode #f0f2f7, IBM Plex Sans + IBM Plex Mono, Seamless accent palette.
Reason
PPN brand colours have not been formally confirmed. Using a coherent placeholder theme prevents a patchwork of inconsistent deliverables. The Seamless theme is structurally separable — when PPN brand colours are confirmed, only the accent CSS variables need updating, not the structural CSS.
Affects
All HTML deliverables in the project hub. Email templates use the confirmed PPN palette (#124747, #FFC701, #758C85) regardless of placeholder theme. Tally white-label and Softr portal will need the confirmed brand palette applied when available. Branding chat thread handles this.
D-02
Tally form mockups are logic validation tools, not visual fidelity targets
DesignProduct
▶
Decision
HTML form mockups (Event Request Form v2, Supplier Onboarding) are built to validate field logic, flow, and conditional branching — not to replicate the Tally visual style. They intentionally look different from Tally.
Reason
The mockups were setting a false expectation of the final form appearance. Tally has its own design system that cannot be replicated in HTML. The value of the mockup is confirming the right questions are asked in the right order, not visual accuracy.
Affects
Further form mockup HTML builds are paused. The Event Request Form v2 mockup is used as a logic specification when building the real form in Tally. Visual appearance will be white-labelled via Tally's own settings using confirmed PPN brand colours.
D-03
Tracker and CMS combined in one file with session persistence
DesignProduct
▶
Decision
The email template tracker and the CMS editor are combined in a single HTML file (ppn_workspace.html). The editor opens as a full-screen overlay from the tracker. Session storage persists content and status within a browser session.
Reason
Two separate files require cross-file state sharing, which only works reliably via localStorage (device-specific) or a backend (not yet available). A single file eliminates the coordination problem. The tracker is the source of truth for the template list.
Affects
Content saves per-session only — closing the browser loses progress. Phase X upgrade path: connect to Airtable as the storage backend. Template content would then persist across devices and be accessible to Lou via Airtable directly. One variable swap to activate.
06
Open Decisions
Pending
PPN Brand Colours & Logo
No formal PPN brand defined. #124747 green and #FFC701 gold from the PrePitched website are the leading candidates. Needs a decision on whether PPN is sub-brand or distinct identity.
Owner: Lou · Chat: PPN Branding & Design
Minimum Supplier Count Before Event Form Goes Public
How many active, onboarded suppliers before the Event Request form opens publicly? Recommended: 10–15 covering a spread of UK regions. Prevents organisers submitting with no one to match.
Owner: Lou · Chat: PPN Project Ops
Supplier Score Suppression Threshold
Working assumption is 3 reviews minimum before score is surfaced. Needs Lou confirmation. Affects when Supplier_Score becomes visible in views and eventually in Softr.
Owner: Lou · Chat: PPN Project Ops
WhatsApp Business Number
A dedicated number needs registering with Meta before Phase X WhatsApp notifications can be built. Decision: existing PrePitched number or new PPN-specific number?
Owner: Lou · Chat: PPN Project Ops · Phase X
Ops Runbook Owner
A short internal guide covering manual fallback processes must exist before Katie's maternity leave in August 2026. Who writes the first draft and maintains it?
Owner: TBC · Deadline: before August 2026
Tally Custom Domain
Tally supports custom domains on paid plans (e.g. forms.prepitched.co.uk). Decision needed before forms go public. Affects Tally account setup and DNS configuration.