Skip to content

Event Lifecycle

Uber revolves around rides. Airbnb revolves around stays. Eventbrite revolves around tickets. Yam3at revolves around the Event. The customer is not trying to book a photographer — they are trying to create a successful event. This page defines the Event as the platform's core entity: its lifecycle, its states, its types, and the data that attaches to it at every stage.

Why the Event is the core entity

Most marketplaces lose the customer the moment a booking completes. By anchoring everything to the Event, Yam3at stays useful across weeks or months of planning — and the finished Event becomes the seed of the next one (Rebook). Every quotation, booking, payment, message, review, and file has an event_id. There are no orphan transactions.

flowchart TD
    E["Event<br/>(core entity)"]
    E --> BUD[Budget]
    E --> GST[Guests]
    E --> VEN[Vendors involved]
    E --> QUO[Quotations]
    E --> BKG[Bookings]
    E --> PAY[Payments]
    E --> MSG[Message threads]
    E --> TML[Timeline & tasks]
    E --> DOC[Files & documents]
    E --> REV[Reviews]

The lifecycle

Ten stages. Quotations are only one step — this is what separates an Event OS from an RFQ website.

flowchart LR
    D[Discover] --> P[Plan]
    P --> Q[Quote]
    Q --> C[Compare]
    C --> B[Book]
    B --> Y[Pay]
    Y --> M[Manage]
    M --> X[Execute]
    X --> R[Review]
    R --> RB[Rebook]
    RB -.->|new event,<br/>seeded from the last one| P
    C -.->|negotiate| Q
# Stage What happens Owning domain(s) Phase
1 Discover Customer browses categories, searches vendors, saves favorites — possibly before creating an event. Marketplace, Experience MVP
2 Plan Customer creates the Event: type, date, city, guest count, budget. Later: checklist, timeline, guest list. Event MVP (planner suite Scale)
3 Quote Customer sends one RFQ to multiple vendors from the Event. Vendors respond with priced quotations. Booking MVP
4 Compare Side-by-side comparison of quotations; negotiation via messaging. Booking, Communication MVP
5 Book Customer accepts a quote; booking is created per vendor service. Booking MVP
6 Pay Deposit paid via KNET/card/Apple Pay/Google Pay; booking confirms. Financial MVP
7 Manage Between booking and event day: messages, changes, remaining tasks, budget tracking, reminders. Event, Communication MVP (basic) / Scale (planner)
8 Execute Event day. Vendors deliver; later phases add live dashboard and check-in. Event MVP (passive) / Vision (live tools)
9 Review Customer reviews each completed booking; ratings feed vendor reputation. Experience MVP
10 Rebook Customer duplicates a past event or reuses trusted vendors for the next occasion. Event, Intelligence Scale

The retention thesis

Stages 1–6 are transactional; competitors stop there. Stages 7–10 are what make Yam3at the app customers keep open for weeks — and return to for the next event. A يمعة (family gathering) recurs monthly; a company runs several events a year. Rebook is where marketplace economics get healthy.

Event states

The Event itself has a simple state machine — deliberately simpler than quotation and booking states, which live in the Booking domain.

stateDiagram-v2
    [*] --> Draft: customer starts wizard
    Draft --> Planning: required fields complete
    Planning --> Upcoming: ≥1 confirmed booking
    Planning --> Cancelled: customer cancels
    Upcoming --> InProgress: event date arrives
    Upcoming --> Cancelled: customer cancels<br/>(bookings handled per policy)
    InProgress --> Completed: event date passes
    Completed --> Archived: 90 days after completion
    Cancelled --> Archived: 90 days after cancellation
    Archived --> [*]
State Meaning Allowed actions
draft Wizard started, minimum fields not yet complete. Edit, delete.
planning Active planning: RFQs, comparisons, unpaid bookings. Everything; the default working state.
upcoming At least one confirmed (deposit-paid) booking; date in future. Manage, message, add more vendors, request changes.
in_progress Event date is today. Vendor contact, day-of info; no new RFQs.
completed Date passed. Review windows open per booking. Review vendors, download invoices, duplicate as new event.
cancelled Customer cancelled the event. Linked bookings follow their own cancellation/refund flows — cancelling an event never silently cancels paid bookings. View history, duplicate.
archived Read-only after 90 days. Still visible in history and Rebook. View, duplicate.

Business rules worth stating once:

  • An Event can exist with zero vendors (pure planning) — the planner must be valuable even before any transaction.
  • Event date changes after a confirmed booking notify every booked vendor and require their re-confirmation.
  • Deleting is only possible in draft; everything else is cancellation with an audit trail.

Event types taxonomy

Event type drives default checklist, suggested categories, budget templates, and AI recommendations (Scale). Kuwait/GCC-relevant from day one — types are seed data, per-country configurable, always bilingual.

Type (EN) Type (AR) Typical categories pulled in Seasonality / notes Phase
Wedding حفل زواج Hall, catering, photography, decoration, kosha, DJ/band, invitations Highest value; often two celebrations (men's/women's) — template supports linked sub-events later MVP
Engagement / Milcha ملچة / خطوبة Venue, sweets, photography, decoration Precursor to wedding — strong Rebook signal MVP
Family gathering (يمعة) يمعة عائلية Chalet/diwaniya rental, buffet catering, kids entertainment The brand's namesake; recurring, budget-sensitive, weekend-heavy MVP
Birthday عيد ميلاد Venue, cake, decoration, photography, kids entertainment High frequency, low ticket — good acquisition wedge MVP
Graduation حفل تخرج Hall, photography, catering, decoration Peaks May–June; predictable demand spike MVP
Corporate event فعالية شركات Hotel/hall, AV, catering, printing, hostesses Invoiced billing; team accounts (Scale) MVP
Conference / seminar مؤتمر / ندوة Conference hall, AV, translation, badges, catering Longer lead times; multi-day support MVP
Exhibition معرض Exhibition space, booths, logistics, security, printing Multi-vendor heavy MVP
Ramadan ghabga / futoor غبقة / فطور رمضاني Catering, tents, hotel ballrooms, decoration Entire demand compressed into one Hijri month — capacity crunch; Hijri-aware dates MVP
Eid celebration حفل عيد Catering, kids entertainment, gifts Twice yearly, family-centric MVP
National Day / Liberation Day العيد الوطني / التحرير Decoration (flags/themes), catering, entertainment Kuwait: Feb 25–26 peak; other GCC national days per country MVP
Hala February festival event هلا فبراير Venue, entertainment, logistics Kuwait-specific season Scale
Baby shower / newborn (عقيقة) استقبال مولود / عقيقة Venue, sweets, decoration, photography Growing category Scale
Condolence gathering (عزاء) عزاء Tent, catering, chairs, sound Handled with restrained UX: no celebratory copy, fast turnaround Scale
Private dinner / diwaniya night عشاء خاص / ديوانية Chef, catering, service staff Small but frequent Scale
Public ticketed event فعالية عامة بتذاكر Venue, ticketing, security, marketing Requires ticketing module Vision
Other (free text) أخرى Customer picks categories manually Catch-all; monitored to discover new types MVP

Calendar sensitivity

Kuwait demand follows two calendars. Gregorian: national holidays, graduation season, Hala February. Hijri: Ramadan (ghabgas), the two Eids, weddings clustering after Ramadan. Event date pickers show both calendars (Arabic-first & RTL), and demand forecasting (Intelligence, Scale) must be Hijri-aware.

Data attached at each stage

What the Event record accumulates as it moves through the lifecycle — the basis for the ERD.

Stage Data attached to the Event Written by
Discover Favorites and recently-viewed vendors (linked to the customer, attachable to the event once created) Customer
Plan Core fields: type, title, date (+ Hijri), city, area, expected_guests, budget_total (KWD, 3 decimals), notes; later: checklist items, guest list, timeline entries Customer
Quote RFQ record (requirements, attachments, target vendors, expiry); one quotation per responding vendor Customer, Vendors
Compare Quotation status transitions, negotiation messages, counter-offer history Customer, Vendors
Book Booking record per accepted quote: service snapshot, agreed price, deposit amount, cancellation policy snapshot System
Pay Payment records (PSP reference, method, amount in KWD), invoice, receipt Financial engine
Manage Message threads, change requests, uploaded documents (contracts, floor plans), task completions, budget actuals Customer, Vendors
Execute Day-of contact info; (Vision) check-ins, live status System, Vendors
Review One review per completed booking: rating, text, vendor reply Customer, Vendor
Rebook Duplication link cloned_from_event_id; reused-vendor shortcuts Customer, Intelligence

Two snapshot rules protect historical truth:

  • Price snapshots. A booking stores the agreed quotation content at acceptance time; later changes to the vendor's catalog never mutate past bookings.
  • Policy snapshots. The cancellation policy in force at booking time is stored on the booking, so disputes are resolved against what the customer actually agreed to.