User Journeys¶
Three end-to-end journeys that the MVP must make excellent: a customer planning a wedding, a vendor going from registration to first payout-relevant booking, and an admin approving a vendor and resolving a dispute. Each step notes the emotional moment (what the person feels — Yam3at sells confidence, so feelings are requirements) and the drop-off risk (where we lose them if the product stumbles).
Personas and their backstories are defined in Personas; screen-level detail lives in Key Screens.
Journey A — Customer plans a wedding (signup → review)¶
Sara, 27, Kuwait City. Wedding in 6 months, budget ~8,000 KWD, planning in Arabic on her phone, currently drowning in Instagram DMs and a WhatsApp group with 14 unread vendor threads.
sequenceDiagram
actor S as Sara (Customer)
participant Y as Yam3at
participant V as Vendors (×5)
participant A as Admin
S->>Y: Sign up (phone OTP, Arabic UI)
S->>Y: Browse wedding halls & photographers (no account wall)
S->>Y: Create Event: wedding, date, Salmiya, 250 guests, 8,000 KWD
S->>Y: Send one RFQ to 5 photographers
Y->>V: Notify: new RFQ received
V-->>Y: 4 quotations within 48h
Y-->>S: Push: "You received a new quotation"
S->>Y: Compare quotes side-by-side
S->>V: Negotiate with top choice (in-app chat)
V-->>S: Revised quote (−10%, adds second shooter)
S->>Y: Accept quote → booking created
S->>Y: Pay 30% deposit via KNET
Y-->>S: Booking Confirmed + receipt (KWD, 3 decimals)
Y-->>V: Booking Confirmed notification
Note over S,V: Months of Manage: messages, schedule details, reminders
Note over S: 💍 Event day
Y-->>S: "How was Golden Lens Studio?" (after completion)
S->>Y: 5★ review + photos
Y-->>A: Review enters moderation queue
| Step | Emotional moment | Drop-off risk & mitigation |
|---|---|---|
| Discover before signup | Curious, guarded — "is this another empty directory?" | High. Thin vendor supply kills trust in 30 seconds. Launch only when priority categories are stocked (see launch criteria). Browsing requires no account; the wall appears only at RFQ. |
| Sign up (phone OTP) | Mild friction tolerance — one shot at goodwill. | High. OTP delayed >30s on Kuwaiti carriers = abandoned signup. Resend timer, fallback to email, Google/Apple one-tap. |
| Create Event wizard | "Someone finally gets what I'm doing" — first taste of the Event OS. | Medium. Too many required fields feels like a tax form. 5 required fields max; everything else deferrable. |
| Send RFQ to 5 vendors | Empowerment — one form replaces 14 WhatsApp threads. This is the aha moment. | Medium. If she must retype requirements per vendor, we've rebuilt WhatsApp. One RFQ, multiple recipients, by design. |
| Waiting for quotes | Anxiety. Silence reads as a dead platform. | Critical. Zero quotes in 48h ≈ churned forever. Vendor response-time SLAs by plan, nudges to slow vendors, expected-response-time shown up front, push on every quote received. |
| Compare quotations | Control — the spreadsheet she'd have made, done for her. | Low. Comparison must normalize what's included/excluded, not just totals. |
| Negotiate | Confidence with a safety net; haggling is culturally expected. | Medium. Risk of going off-platform to WhatsApp. Keep chat fast, mobile-first, with attachments — the path of least resistance must be in-app. |
| Pay deposit (KNET) | Peak anxiety. Largest sum she has ever paid through an app, to a business she has never met. | Critical. KNET-first (the trusted local rail), clear refund/cancellation policy on the payment screen, instant confirmation + receipt. Any PSP glitch here is fatal to trust. |
| Manage until event day | Calm — budget, contacts, threads in one place. Confidence compounding. | Low, but real. A silent app gets deleted. Milestone reminders ("2 weeks out — confirm final guest count with your caterer"). |
| Event day | Joy (not looking at our app — correct). | — |
| Review | Gratitude, closure, pride in contributing. | Medium. Reviews need prompting: push 24–48h post-event, 2-minute flow, photo upload optional. |
| Later: Rebook | Loyalty — sister's graduation party starts from a duplicated event. | Retention on display: past event, trusted vendors, one tap. Scale. |
Journey B — Vendor: registration → payout of first deposit¶
Abu Fahad runs a catering company in Hawalli: 8 staff, a commercial license, all business through Instagram DMs and phone calls. Quotes get lost; follow-ups get forgotten.
flowchart TD
R[Register business account] --> L[Upload commercial license + profile details]
L --> W{Admin review<br/>SLA ≤ 48h}
W -->|Approved| S[Choose subscription plan]
W -->|Rejected with reason| RF[Fix documents & resubmit]
RF --> W
S --> P[Pay subscription via KNET/card]
P --> C[Build catalog: services, packages, gallery, service area]
C --> LIVE([Listing goes live])
LIVE --> RFQ[Receive first RFQ notification]
RFQ --> QT[Submit quotation: price, notes, validity, attachments]
QT --> N[Negotiate in chat]
N --> ACC{Customer accepts?}
ACC -->|Yes| BK[Booking created - customer pays deposit]
ACC -->|No / expired| RFQ2[Back to pipeline - next RFQ]
BK --> CONF[Booking Confirmed - deposit held per payout policy]
CONF --> DEL[Deliver on event day]
DEL --> DONE[Booking Completed]
DONE --> PAYOUT[Vendor share settled per payout schedule - net of commission]
PAYOUT --> REV[Receives review -> reputation grows]
Deposit handling (MVP policy)
The customer's deposit is collected by Yam3at through the PSP against the booking. On confirmation the platform captures its commission (5% of the booking total) from that deposit and settles the vendor's share (deposit − commission) — see the commission model. Settlement is not instant: the vendor's share follows the payout schedule defined in Payments — after the booking is Confirmed and outside the refund-request window, standardly reconciled after Completed. This gives customers real protection (the confidence we sell) without full escrow, which is Vision. Refund requests freeze settlement of the disputed amount until Operations resolves.
| Step | Emotional moment | Drop-off risk & mitigation |
|---|---|---|
| Register + license upload | Hope mixed with skepticism — burned before by platforms that brought zero customers. | High. A license photo taken by phone must be acceptable (JPG/PDF), with clear file-size guidance. Every extra required field costs vendors. |
| Awaiting approval | Impatience; the platform is being judged on responsiveness. | High. >48h silence = vendor gone. Status visible in dashboard, notification on decision, rejections always carry an actionable reason. |
| Choose & pay subscription | "Is this worth real money before I've seen one lead?" | Critical. This is why the Free plan exists — taste the RFQ flow before paying. Upgrade prompts trigger on hitting the monthly quotation cap, not on day one. |
| Build catalog & gallery | Pride — his business has never looked this professional. | Medium. Uploading 30 photos on mobile must not fail silently. Progress indicators, background upload, drafts. |
| First RFQ arrives | Validation. The platform is real. The single most important vendor moment. | Critical. If a new vendor gets no RFQ in 2–4 weeks, the subscription won't renew. Ops must balance supply/demand per category and city (flywheel). |
| Submit quotation | Focus — wants to win. | Medium. Quote form ≤ 3 minutes on mobile, reusable templates (Scale: AI drafting). |
| Negotiation | Engaged; also tempted to pull the customer to WhatsApp to dodge the platform. | Medium. MVP counterweights: in-app speed and the trust badge that on-platform payment gives the customer. Scale: platform benefits (calendar, CRM-lite) make leaving costly. |
| Booking + deposit paid | Best day on the platform — real money committed to him through Yam3at. | Low. Instant, celebratory confirmation. |
| Deposit settlement | Trust in the platform's money handling: "when do I get paid?" | High if opaque. Payout schedule stated on the booking screen, not buried in terms. Predictability > speed. |
| Review received | Pride; reputation is now an asset that compounds on Yam3at. | — Renewals follow from RFQs won + reviews earned; both must be visible in his analytics. |
Journey C — Admin: vendor approval and a dispute¶
Noura works platform operations. Her two highest-stakes flows: gatekeeping vendor quality, and defusing money conflicts.
C1 — Vendor approval¶
flowchart LR
Q[Approval queue] --> D[Open application:<br/>license, profile, category]
D --> V{License valid, legible,<br/>matches business activity?}
V -->|Yes| A[Approve → vendor notified,<br/>can subscribe & publish]
V -->|No| RJ[Reject with reason →<br/>vendor can resubmit]
V -->|Unclear| H[Request more info<br/>status: On Hold]
H --> D
A --> AU[(Audit log)]
RJ --> AU
- Every decision is written to the audit log with admin ID, timestamp, and reason.
- Target SLA: decision within 48 hours — it is a launch metric, not an aspiration.
- Emotional stake: approvals feel routine to Noura but existential to Abu Fahad. Queue tooling (side-by-side license view, canned rejection reasons in Arabic and English) keeps quality high at speed.
- Risk: rubber-stamping to clear the queue seeds the marketplace with bad vendors — the single fastest way to destroy the confidence the brand sells. Checklist-driven review, not vibes.
C2 — Dispute over a booking¶
A customer files a refund request: the decoration vendor delivered late and incomplete for a graduation party. Booking is Refund Requested; the disputed deposit settlement is frozen automatically.
sequenceDiagram
actor C as Customer
participant Y as Yam3at
actor N as Noura (Admin)
actor V as Vendor
C->>Y: Request refund on booking (reason + photos)
Y->>Y: Booking → Refund Requested; settlement frozen
Y-->>V: Notified: refund requested, 48h to respond
Y-->>N: Dispute appears in Operations queue
V-->>Y: Vendor response + evidence
N->>Y: Reviews thread history, quotation terms,<br/>policy snapshot, evidence
N->>Y: Decision: partial refund 60%
Y-->>C: Refund processed to original payment method (PSP)
Y-->>V: Remaining 40% released per payout schedule
Y->>Y: Audit log + dispute record closed
| Aspect | Rule of the road |
|---|---|
| Evidence | The in-app record is the arbiter: message threads, quotation content, policy snapshot at booking time. This is a core reason to keep negotiation on-platform. |
| SLA | First response to both parties ≤ 24h; resolution target ≤ 5 business days. |
| Outcomes | Full refund · partial refund · no refund — each with a written reason sent to both parties. |
| Money | Refunds go back via the PSP to the original method; vendor-side settlement adjusts accordingly (Payments). |
| Emotions | The customer feels wronged at a moment tied to a once-in-a-lifetime day; the vendor feels accused in front of their reputation. Tone of every template message matters — neutral, specific, bilingual. |
| Escalation risk | A dispute mishandled publicly (social media) costs more than any refund. Empower Noura with a goodwill-credit budget (Scale: wallet credits). |
Journey health metrics¶
Each journey has one number that tells us it works (full KPI tree in KPIs & Risks):
| Journey | North-star check | Target at MVP |
|---|---|---|
| Customer | % of RFQs receiving ≥ 2 quotations within 48h | ≥ 80% |
| Customer | Event creation → first RFQ sent | ≥ 60% |
| Vendor | New vendors receiving ≥ 1 RFQ in first 30 days | ≥ 70% |
| Vendor | First-term subscription renewal | ≥ 60% |
| Admin | Vendor approval decision within SLA | ≥ 95% |
| Admin | Disputes resolved within 5 business days | ≥ 90% |