Vendor Dashboard
Control over how a venue, photographer or DJ is presented and seen, with enough visible return to justify a R400 to R1,200 monthly line item to an owner who does their own books.
User stories
- Venue ownerI want to see how many couples viewed my listing this month versus last, so I know if my photos and pricing are working.
- PhotographerI want one inbox for every quote request across all my listed weddings, so nothing gets lost in someone's personal WhatsApp.
- DJI want to block dates I've already booked off-platform, so the AI never recommends me for a clashing date.
- Any vendorI want to know exactly why I ranked below a competitor, and the one lever I can pull to fix it.
- Small vendorI want the whole dashboard usable on a mid-range Android phone over a 3G data bundle.
Key screens & flows
- Listing Health scoreA single 0 to 100 score built from profile completeness, photo count and quality, response time, review volume and rating, and booking rate. Shown with a concrete checklist, not a vague grade: "add 4 more photos to reach 90."
- Catalogue & portfolio managerDrag-to-reorder photo grid, a tiered package builder (Silver / Gold / Platinum style, line-item pricing), and style tags (rustic, Indian, beach, budget-tier) that feed the AI matcher directly.
- Analytics funnelImpressions to profile views to shortlists to quote requests to bookings, with a conversion rate at each step, benchmarked anonymously against similar vendors in the same category and province.
- Lead inbox & pipelineA Kanban board: New, Quoted, Negotiating, Won, Lost. Each card shows the couple's budget band, date, guest count and style tags pulled from their AI chat profile (with consent), and a WhatsApp-native reply thread proxied through Aisle so nothing depends on one staff member's phone.
- Availability calendarManual blocks plus ICS/Google Calendar import. Feeds the matcher directly (an unavailable vendor is never recommended) and powers a public "next available date" badge on the listing.
- Response-time metricsMedian time to first reply and time to quote, visible to the vendor always, and surfaced to couples (aggregated, tiered) as a trust badge: "usually replies within 3 hours."
- Boosted placementSelf-serve weekly budget cap with an estimated impression lift. Boost only re-orders within the set of already relevance-qualified vendors; it can never push an irrelevant vendor above a better match.
- "Why am I recommended" panelThe actual ranking factors and their weights: style match, budget fit, availability, response time, review score, boost. A simulator shows the effect of a single change: "reply within 2 hours on average and your projected rank moves from #7 to #4."
Data model sketch
AI-agent hooks
Offline & ZA considerations
Monetisation angle
- Basic listing
- Capped leads / month
- No analytics
- Full analytics funnel
- Unlimited leads
- Calendar sync
- WhatsApp inbox
- Included boost budget
- AI-drafted replies
- Team seats
- "Fast responder" badge
The anti-churn mechanism is a number, not a feature: every login shows an attributed-revenue ledger, "3 bookings this quarter came through Aisle leads, worth R48,000," alongside the funnel and Health Score. A vendor who cannot see what a subscription bought them cancels it; a vendor whose accountant can see it renews it without being asked.
Lean MVP vs later phases
- Listing profile + portfolio manager
- Single lead list with a status dropdown (no Kanban)
- Manual availability calendar
- Basic impressions / views count
- PayFast subscription billing
- WhatsApp reply logging
- Full funnel analytics with category benchmarking
- Boosted placement auction
- AI-drafted first replies
- Ranking transparency panel and simulator
- Team seats, ICS two-way calendar sync
- Public response-time trust badge
Day-of Check-in App
Live wedding-day operations that keep working when the venue's uplink dies and three phones are running low, because on this one day the app is not allowed to fail.
User stories
- CoordinatorI want to see who has arrived versus who hasn't, per table, without needing signal.
- UsherI want to check a guest in by QR or name search in under 3 seconds, even if the venue wifi is down.
- CoordinatorI want a running headcount I can hand the caterer every 30 minutes without doing the maths myself.
- CoordinatorI want to reconcile plus-ones and walk-ins live without breaking the seating chart.
- Two ushersI want our check-ins at different doors to merge without double-counting or fighting over whose list is current.
Who runs it on the day
One device carries a Command role, usually the lead coordinator or planner: full seating view, reconciliation, headcount broadcast. One to three devices at entrances carry a Check-in role, usually ushers or family members: scan and search only, no seating edits. The split matters because a chaotic door queue is exactly where an usher should not be able to accidentally move someone's seat.
Key screens & flows
- Pre-day downloadThe full guest list, seating chart, plus-one records and dietary flags are pulled to the device the night before, over home or office wifi, with an explicit "Ready for offline" confirmation. This is the load-bearing screen; everything downstream depends on it having actually happened.
- Check-inFuzzy name search (handles misspellings and nicknames) plus a QR toggle. One tap confirms, with a visible plus-one prompt ("Thabo + 1, both here?") and an "add guest not on the list" walk-in flow that flags for later reconciliation rather than blocking the door.
- Live floor viewA table-by-table grid, each card showing arrived over expected with a colour state (empty, partial, full). Tapping a table shows named seats with arrival ticks: the actual "who's here" screen for answering "has my aunt arrived yet."
- Headcount stripA persistent header: total arrived, expected, no-shows so far. One tap formats it straight into a WhatsApp message to the caterer's own number, "142 arrived, 8 no-shows, catering confirmed for 150," because that conversation happens on WhatsApp regardless of what app exists.
- Table-ready boardA separate checklist axis from arrival: coordinator marks each table set and inspected (cutlery, name cards, centrepiece). Useful for a hired coordinator running staff, distinct from guest arrival status.
- No-show & walk-in reconciliationAfter cocktail hour: a list of not-yet-arrived guests with a one-tap call or WhatsApp to a designated family contact, and a list of walk-ins with a seat suggestion pulled straight from the constraint-solved seating engine's open seats.
Data model sketch
Offline resilience: the sync model
This is the section that decides whether the product works. Venue wifi in South Africa is inconsistent even without load-shedding, and a rolling outage regularly kills a venue's fibre or LTE backhaul while the local router keeps running on a UPS. The design has to assume the internet is the thing that's down, not the room.
Why conflicts mostly don't happen: a check-in is an append-only, idempotent event with a client-generated id, not an overwrite of a "checked in" field. Two ushers checking in the same guest at once just produces two events for the same guest; the UI treats "checked in" as true if any event exists for that guest, and headcount dedupes by guest id, not event count. There is no last-write-wins race to lose.
What does need resolving: two people editing the same non-idempotent field, most commonly a walk-in's table assignment. That case falls back to last-write-wins by timestamp, but the UI never overwrites silently: it shows "edited elsewhere, tap to see both versions."
Every screen states its own sync honesty: "142 events, last synced with the cloud 6 minutes ago, 3 devices connected locally," so the coordinator always knows whether they're looking at the full picture or a partial one. Guessing is the failure mode this design is built to avoid.
Monetisation angle
Sold as a per-wedding add-on, roughly R249 once-off, to couples who have already paid for the seating solver, the natural upsell moment. Venues can also white-label it as something they "provide," which reads as more professional to the couple and strengthens venue subscription retention on the vendor side, a small cross-sell between Flagships A and B.
Lean MVP vs later phases
- Pre-day full download
- Name search + QR check-in
- Live table grid, arrived vs not
- Running headcount, WhatsApp share button
- Single device, or manual file export/import to merge a second
- True peer-to-peer local sync across devices
- Walk-in to seat auto-suggestion from the solver
- Table-ready ops board
- No-show family-contact shortcuts
- Auto-emailed post-event attendance report
WhatsApp-Native Guest Concierge
One conversational thread per guest that resolves RSVP, dietary needs, transport and a group gift, and feeds every other Aisle system with clean structured data instead of a couple manually chasing 120 people by hand.
Why this one
Considered against the alternatives (budget-aware vendor negotiation, a standalone registry, transport logistics on their own, dietary-to-seating auto-sync as an isolated feature): each of those is a good feature, but each is also a form with a nicer skin. The concierge is chosen because it is the one surface every guest already has open, WhatsApp penetration in South Africa runs above 90%, so it needs no install and works on a low-end Android phone over patchy data, and because "chasing 120 people on WhatsApp for RSVPs and dietary requirements" is, by a wide margin, the single most dreaded task couples report. Automating a thread that already exists relieves a real, named pain; it doesn't invent a feature guests have to be sold on.
It is also the one place genuinely hard to do without an LLM. A form can capture "attending: yes, party size: 2." It cannot parse "ya we coming but my mrs doesn't do meat" into an RSVP, a party size, and a dietary flag on the correct person. That parsing, done in the language the guest actually used, is the product.
And it is the connective tissue the brief asked for: dietary output lands directly in the caterer's lead thread from Flagship A; the final guest-and-plus-one list is the authoritative source Flagship B downloads the night before; transport needs cluster into a shuttle booking; and a shared gift fund gives diaspora family, who can't attend and can't leave a card on a gift table, a way to contribute in their own currency.
User stories
- GuestI want to RSVP by replying in my own words on WhatsApp, without opening an app or filling in a form.
- BrideI want to see RSVP, dietary and transport status for all 180 guests in one place without asking anyone myself.
- Diaspora uncleI want to contribute to the honeymoon fund in my own currency without needing a South African bank account.
- CoupleI want non-responders nudged automatically two weeks before the deadline, in the family's own language, without me chasing them one by one.
- Caterer (vendor)I want the final dietary breakdown to land in my lead thread automatically the week before, not as a stressed phone call at 11pm.
Key screens & flows
The guest-facing "screen" is the WhatsApp thread itself. Below is the shape of that conversation, followed by the couple's own dashboard.
- Concierge Ops dashboardOne table on the couple's side: guest, RSVP, party size, dietary, transport need, gift status, last contact. Filters to "needs follow-up," a nudge-all button, and a manual override for the rare mis-parse.
- Transport & accommodation viewGuests clustered by need, "14 need a Cape Town CBD shuttle," "22 need accommodation near the venue," with a vendor or room-block link attached per cluster; the agent then messages only the affected guests with the specific pickup time.
- Group giftingA shared cash fund and item registry with a PayFast contribution link sent conversationally. A running thermometer shows the couple total raised, not who gave what, unless a guest opts to make their name visible.
- Vendor hand-offA set number of days out, the final dietary and headcount summary posts automatically into the caterer's Lead thread from Flagship A, and becomes the guest-and-dietary source Flagship B downloads for check-in day.
Data model sketch
AI-agent hooks
Offline & ZA considerations
Monetisation angle
Two components, deliberately not one: a modest allowance included in the couple's paid plan up to a guest-count threshold, then a flat per-additional-guest fee above it, plus a small basis-point fee on GiftContribution throughput. The gifting fee scales with a wedding's size and generosity rather than penalising a budget-conscious couple simply for having a guest list to manage. Vendors never pay for this directly, but cleaner leads and a dietary breakdown that shows up on time make Flagship A's subscription easier to keep, a cross-sell that doesn't show up on an invoice anywhere but shows up in the churn number.
Lean MVP vs later phases
- WhatsApp invite send
- Single-turn RSVP, party size, dietary parse
- Couple dashboard table
- Manual nudge button (no auto-schedule)
- Basic cash-fund link via PayFast
- Auto-detect language, auto-nudge scheduling
- Transport and accommodation clustering with vendor hookup
- Itemised registry, diaspora payment path
- Direct hand-off into vendor lead threads and day-of check-in
How the three connect
None of these are built in isolation. The Concierge (C) is the data engine that keeps the Vendor Dashboard's leads (A) clean and the Day-of app's (B) guest manifest current on the morning of download. The Vendor Dashboard's availability calendar keeps the matching agent honest everywhere it recommends a vendor. And the Day-of app's offline-first architecture, local write, peer sync, opportunistic cloud sync, isn't a one-off for check-in day; it's the pattern the rest of the ZA-facing product should be judged against, because the constraint that shaped it (patchy venue connectivity, load-shedding, one shared phone) is not specific to a wedding day. It's specific to the country.