Case study · Business systems

Membership sales CRM, contracts and billing platform

Laravel platform covering leads, tour scheduling, e-signed contracts, payments, recurring invoicing, commissions, analytics and bulk SMS and email.

Sector
Travel membership sales
Category
Business systems
Maturity
Substantial Laravel application with a written handover document; automated tests are only skeleton examples

At a glance

Who it's for
Sales teams, managers, payroll and billing administrators, and members via a portal API.
Core stack
PHP 8.2, Laravel 12, Vue 3, MySQL
What sets it apart
One system that carries a membership sale from first lead through signed contract, payment, recurring billing and commission payout.

What it looks like in use

One family's record, from the booked tour to the signed contract, the bills and the sales team's commission.

Membership CRM: Parker household
Parker householdContract signed
Tour booking
CampaignSpring travel show
Day and waveSaturday, 10:00 wave
Time slot10:30
Reminder messageSent
AttendanceChecked in
Contract
MembershipStandard plan
SignatureSigned on screen
Signed copyPDF saved
PaymentPaid by card
Invoices
First paymentPaid
Next monthly invoiceScheduled
Following invoices are created automaticallyAutomatic
Commission
Sales rep and manager shares worked outAutomatic
Payroll reviewAwaiting review
Open payroll review
Illustrative screen sample data, not client data

A membership sale, step by step

  1. A family asks about membership

    They fill in a short form online, and the sales team has a new lead with a household record.

  2. They are booked into a tour time

    The lead picks a slot on the calendar, then gets a confirmation and a reminder message.

  3. The contract is signed on screen

    The family signs in the browser, and a PDF copy of the signed contract is saved to their record.

  4. Payments and bills run on a schedule

    The first payment is taken, and later monthly, quarterly or yearly invoices are created and sent on time.

  5. Commission is worked out for the team

    Each person's share is calculated from the contract, then checked on a payroll review screen.

The challenge

A membership sales operation runs a long pipeline: capture prospects, book them into scheduled sessions, confirm attendance, close a contract, collect payment, then bill recurring fees and pay commissions.

Without a single system, each step lives in a separate tool: forms, calendars, texting, payment links, accounting and payroll spreadsheets. That causes re-keying and disagreement over contract and payment status. The handover document describes all of these steps in one system with many roles involved.

The solution

A Laravel 12 monolith with Blade, Vue 3 and Alpine front ends. A lead form feeds scheduling, with campaigns, days, waves and time slots. Confirmation and reminder messaging follows, then contract creation with in-browser signature and PDF archiving.

Payments, recurring billing, invoices and commission calculation hang off the contract. Role-based access separates sales, management, payroll and admin views. A headless authentication API serves an external member portal.

For your technical teamhow it works under the hood

Mechanism: how the core records relate

Membership CRM data model sketchData model sketch. Scheduling hierarchy: a campaign has many days, a day has many waves and a wave has many slots. A lead books into a slot. A contract belongs to one lead. Observers on leads and contracts keep derived data consistent. A contract has invoice items, recurring billing schedules, a commission calculation and additional costs.SchedulingCampaignDayWaveSlothas manyhas manyhas manySalesLeadbooks into a slotContractone per leadObservers on leads and contractskeep derived data consistentMoney tied to the contractInvoice itemsRecurring billingschedulesCommissioncalculationAdditional costs
Scheduling is a tree, from campaign down to slot. Leads attach to that tree, a contract grows out of each lead, and everything financial hangs off the contract.

Key features

What the system does, as built in the codebase.

  • 01

    Lead capture and household records

    Public and internal lead forms feed household and member models.

  • 02

    Campaign, wave and slot scheduling

    Campaigns divide into days, waves and bookable slots, with timezone handling and check-in views.

  • 03

    Contract lifecycle

    Contract creation, e-signature capture and generated PDFs.

  • 04

    Payments and shared payment links

    Card payments through a payment gateway, plus Stripe link support.

  • 05

    Recurring billing and invoicing

    Commands and an invoicing service generate monthly, quarterly and yearly invoices. A nightly job syncs billing status, and an accounting-platform service creates and sends invoices.

  • 06

    Multi-tier commissions and payroll review

    Commission calculation with a payroll review screen.

  • 07

    Analytics and report builder

    Query-driven reports with CSV import and export.

  • 08

    Bulk SMS and email notifications

    Notifications, reminders and surveys delivered through queue jobs.

How it fits together

From a first lead to a signed contract, payment and commission.

  1. Lead intakepublic forms, SMS and email
  2. Schedulingcampaigns, waves, slots
  3. Contractse-signature and PDF
  4. Paymentsgateway and payment links
  5. Billing and commissionsscheduled invoices, payroll
  6. Analytics and portal APIreports, member auth
Leads enter through forms and are booked into scheduled slots. A contract is signed and archived as a PDF. Payments, recurring billing and commissions hang off the contract, while analytics and a portal API expose the results.
  • Queue jobs deliver notifications.
  • Scheduled commands drive reminders, recurring invoices and billing sync.

Implementation notes

Engineering decisions worth knowing about.

  1. Role and permission access control

    Role and permission middleware separates sales, management, payroll and admin views.

  2. Dual authentication

    Sanctum for the single-page app and JWT for external API consumers, plus key-based API clients.

  3. Queues and scheduled commands

    Queue jobs are configured for Redis, with a database driver as fallback. 25 artisan commands cover billing, reminders and sync, about ten of them registered in the scheduler.

  4. Model observers

    Observers on leads and contracts keep derived data consistent.

  5. Integrations in service classes

    Telephony SMS, email delivery, calendar, geocoding, Slack and Zoom are each isolated behind a service.

  6. Log sanitizing

    A log processor keeps sensitive values out of logs.

  7. OpenAPI documentation

    API docs are generated with a Swagger package.

  8. Iterative schema history

    Roughly 100 migrations show how the data model evolved.

Technology stack

Taken from the project's dependency and config files.

Backend
  • PHP 8.2
  • Laravel 12
  • Sanctum
  • JWT auth
Frontend
  • Vue 3
  • Alpine.js
  • Tailwind CSS
  • Vite
  • Blade
Data
  • MySQL or MariaDB
  • Redis (Predis)
Payments and documents
  • Stripe
  • DomPDF
  • League CSV
Messaging
  • Postmark
  • Slack notifications
  • Cloud telephony SMS
API docs
  • L5-Swagger
For your technical teamtechnology layers

Technology stack by layer

Membership CRM technology stack by layerLayered stack diagram. Frontend: Vue 3, Alpine.js, Tailwind CSS, Vite and Blade. Backend: PHP 8.2, Laravel 12, Sanctum, JWT auth and L5-Swagger API docs. Payments and documents: Stripe, DomPDF and League CSV. Messaging: Postmark, Slack notifications and cloud telephony SMS. Data: MySQL or MariaDB, and Redis.FrontendVue 3Alpine.jsTailwind CSSViteBladeBackendPHP 8.2Laravel 12SanctumJWT authL5-SwaggerPayments anddocumentsStripeDomPDFLeague CSVMessagingPostmarkSlack notificationsCloud telephony SMSDataMySQL or MariaDBRedis (Predis)
One Laravel application serves both the Blade and Vue front ends. Stripe, PDF generation and messaging providers sit behind service classes, with MySQL or MariaDB and Redis underneath.

Business value

What the system enables. No numbers are claimed.

  • Keeps the whole prospect-to-payment journey in one record chain, avoiding re-keying between tools.
  • Automates recurring invoices, reminders and commission calculation that would otherwise be manual.
  • Separates access by role so sales, payroll and admins see only what they need.
  • Exposes a headless API so a member-facing site can reuse the same accounts.

Need a system like this built?

Tell us what it needs to do and we will scope it with you on a call.

Discuss a build