Zuna's Lucknow pilot exists to prove one thing: that IT professionals in the same corridor will share rides regularly when matched well and given a frictionless experience. Every decision in this playbook serves that proof.
| Metric | Definition | Who Drives It | Target Date |
|---|---|---|---|
| Qualified Lead | IT professional with a regular commute who expressed interest and filled the lead form | Field Promoters | D−7 |
| Registration | Downloaded the app, completed phone OTP, and submitted their profile | Promoters + Founder follow-up | D+3 |
| Published Ride | A Host has created a ride schedule with route, timing, and seat count set | Founder-assisted onboarding | D+7 |
| Active Ride Group | A published ride has at least 1 accepted Buddy and completed at least 2 real rides | Matching Ops + Support | D+20 |
North Star: Active Ride Groups. Everything else is a funnel leading to this. If registrations are high but published rides are low, the bottleneck is host onboarding. If published rides are up but groups are not forming, the bottleneck is buddy matching.
The pilot is considered successful and ready for expansion review when 3 active ride groups are running, each with a host and at least 2 buddies, for at least 5 consecutive ride days without support intervention.
Start with 2–3 high-density IT corridors in Lucknow. Do not spread too wide in the first 30 days — depth over breadth wins in a marketplace.
| Priority | Corridor | Why |
|---|---|---|
| Priority 1 | Hazratganj / Gomti Nagar → Vibhuti Khand IT Zone | Highest IT employee density, predictable commute times |
| Priority 2 | Indira Nagar / Faizabad Road → Lucknow Tech Campus | Large residential catchment, multiple tech companies |
| Priority 3 | Aliganj / Rajajipuram → Sahara Estate Business Park | Growing IT cluster, underserved transport options |
Rule: Do not accept leads from outside these corridors in the first 30 days. Matching only works when density is high. A scattered user base creates zero ride groups.
Best promoters are people who already work in IT or know the IT crowd. A software engineer who does this part-time is more credible than a general marketing intern. Peer trust converts.
2 promoters at each priority corridor. Position at the main entrance. Approach people arriving, not those rushing out. Target: 8–10 conversations per slot per promoter.
Same locations. People are relaxed and leaving — better time to have a full conversation. Capture leads who were missed in the morning. Target: same 8–10 per slot.
Post in Lucknow IT / tech groups. Direct message people in the target corridors. Be specific: "Do you commute from Gomti Nagar to Vibhuti Khand?" — specificity converts.
Ask every lead: "Do you know 2 colleagues who face the same commute problem?" Offer a referral incentive — priority matching when the app launches.
| Day | Total Leads Target (cumulative) | Focus |
|---|---|---|
| D−20 | 10 | Dry-run field pitch, adjust based on feedback |
| D−18 | 25 | Identify top corridors with highest interest |
| D−15 | 50 | Demand analysis checkpoint — do we have corridor density? |
| D−12 | 75 | Focus outreach on corridors with most leads already |
| D−11 | 100 | Lead collection target hit — begin filtering & qualification |
D−15 Demand Analysis: If by day −15 you do not have 10+ leads in any single corridor, shift all promoter effort to the corridor with the most traction. Do not spread further — go deeper.
A lead is qualified only if ALL of these are true:
A lead is disqualified if: work-from-home more than 3 days/week, route is outside corridors, or refused to share phone number.
Before real lead collection starts, do one full promoter dry run:
No-go conditions: If OTP login is broken, app is not on both stores, or fewer than 2 Hosts are confirmed — delay by 24 hours. A broken first experience cannot be undone.
| Time | Action | Who |
|---|---|---|
| 07:00 | Team WhatsApp check-in — all members confirm ready | All |
| 07:30 | Tech team confirms API and push notifications live | Tech Lead |
| 08:00 | Registration officially opened — announcement sent to waiting list | Founder |
| 08:00 | Promoters deployed at morning gate positions | Field Coordinator |
| 08:30 | First registration monitor — confirm OTP flow working for real users | Tech Lead |
| 09:00 | Notify waiting list again — push notification + WhatsApp | Founder |
| 10:00 | Morning field debrief — any issues? Leads count so far? | Field Coordinator |
| 12:00 | Midday support check — any tickets outstanding > 30 min? | Support |
| 12:00 | Founder reviews registration count — on track? | Founder |
| 17:00 | Evening promoters deployed for commute-time outreach | Field Coordinator |
| 18:00 | First host ride review — how many hosts published a ride today? | Founder |
| 19:00 | Evening promoters debrief and return | Field Coordinator |
| 21:00 | Day 0 report sent to full team: registrations, leads, published rides, open issues | Founder |
If OTP/login is broken: Pause the waiting list announcement. Tech fixes immediately. Resume when stable. Do NOT tell users to "try again later" without an ETA.
If registrations are very low (<5 by noon): Founder personally calls the top 10 leads. Do not wait. Direct phone call converts 3–4× better than WhatsApp message alone.
If everything is going well: Still do the 18:00 and 21:00 reviews. Good momentum can hide problems. Check support tickets and API error rate even when it feels fine.
Every WhatsApp reply, every support email, every complaint. Categorize: product bug / UX confusion / expectation mismatch. Share categories with the team.
If registrations are under 30, call everyone. Ask: "Did you find what you were looking for?" and "What confused you?" — 5-minute calls. Log every answer verbatim.
From the calls, identify what blocked users most. Fix these before focusing on anything else. The feature freeze lifts for bug fixes only — no enhancements this week.
Call each published host. Do they know how to start their schedule? Do they understand the meeting point flow? Offer to be on call during their first ride day.
| Time | Activity | Owner |
|---|---|---|
| 08:00 | Check overnight signups and support tickets. Prioritize any blockers. | Founder |
| 09:00 | Promoters continue outreach at gates to convert remaining leads | Field Coordinator |
| 10:00 | Check if any host started their schedule this morning. Any issues? | Founder |
| 12:00 | Midday support sweep — no ticket older than 2 hours without response | Support |
| 18:00 | Evening gate outreach for new leads + existing leads follow-up | Promoters |
| 21:00 | Daily report: new signups, rides published, ride subscriptions, open issues | Founder |
Do not rely only on the app's automatic matching in the first week. Do it manually:
First ride experience is everything. If a host and buddy have one smooth ride together, they continue. If the first ride has a problem and no one follows up, both churn. Be present for every first ride this week.
Look at the conversion funnel: where are users dropping off? Registration → profile complete → publish/subscribe → first ride → repeat ride. The biggest drop is your priority.
Active hosts who have had at least 1 successful ride — ask them to refer 1 friend who also drives. Host referrals are the highest-quality leads for new Host acquisition.
If Priority 1 corridor has at least 1 active group, begin light outreach in Priority 2 corridor. Do not switch focus — add capacity. Same promoter team, split morning/evening slots.
From users who have completed at least 2 rides. Short written quote or voice note. Use these for WhatsApp outreach in Week 3. Real users convert better than any marketing copy.
By Day +30, the pilot success metric is 3 active groups. This is the week to close that gap. If two groups are active, all energy goes toward activating the third.
Are users referring others without being asked? Track referral source for all new signups. If >20% are organic, the product is working. If 0% — the product needs a referral nudge built in.
Assemble data for the formal review (Chapter 13). Include: actual vs target on every KPI, top 3 learnings, top 3 risks, expansion recommendation with evidence.
Based on review data. This is a real decision — not automatic expansion. The framework is in Chapter 13.
| Objection | Response |
|---|---|
| "I have my own car" | "Perfect — you'd be a Host. You set your route once, 2–3 colleagues join you, and they share your fuel cost. You drive the same route you always drive." |
| "Is it safe? I don't know these people" | "Everyone on Zuna is an IT professional with a verified phone and profile. You see their company and photo before accepting. It's your colleagues, not strangers." |
| "My timings are irregular" | "You control your schedule. If you can't go one day, you just don't start the ride. Buddies are notified instantly." |
| "I'll check later" | "Totally fine — here's the QR code for the form. We have limited early spots, and matched users get priority. Takes 2 minutes." |
| "Is this free?" | "The app is free. The cost is just fuel sharing between you and the people you ride with — agreed directly between you. Zuna doesn't take a cut." |
| Slot | Target Conversations | Target Form Fills | Conversion Rate |
|---|---|---|---|
| Morning gate (8–10 AM) | 15–20 | 5–7 | ~35% |
| Evening gate (5–7 PM) | 15–20 | 5–7 | ~35% |
| Total per day | 30–40 | 10–14 |
A match is when a Buddy subscribes to a Host's published ride and the Host accepts that subscription. The match results in an active ride group.
Each morning, check which hosts published rides in the last 24 hours. Note their home area, office, and schedule in the matching sheet.
Look at all qualified leads who marked "Buddy". Which ones live near the host's home area and commute to the same office area?
Call the matched buddy: "A host near [area] published a ride going to [office]. Would you like me to introduce you?" If yes, create a 3-way WhatsApp group with both. Then let them move to the app.
24 hours after their first scheduled ride together, message both host and buddy: "How did the first ride go?" — track the response. Any friction = your next fix.
Bad match cost: A mismatched pair (wrong timing, too far) who have a bad experience will not return to the app. One bad first match can cost you two users. Be conservative — a slower match is better than a wrong match.
First contact for all users. Response target: under 30 minutes during business hours. Set auto-reply outside 8AM–8PM.
For detailed issues, complaints, or formal requests. Response target: under 4 hours. Use response templates.
For users who are stuck in a critical flow (can't login, ride in progress with issue). Founder or coordinator handles directly.
| Category | Example | Response SLA | Escalation |
|---|---|---|---|
| P0 Critical | Login broken for all users, app crash on launch, ride in progress with GPS failure | 15 minutes | Founder + Tech immediately |
| P1 High | Single user can't login, push notification not received, host can't start ride | 30 minutes | Tech on call |
| P2 Medium | App slow, minor UI issue, unclear error message | 2 hours | Tech next working slot |
| P3 Low | Feature request, general feedback, "how do I..." question | 4 hours | Document in backlog |
Send every evening at 21:00 via WhatsApp to the full team. Keep it short — numbers only. If something needs discussion, flag it with ⚠️.
| Risk | Likelihood | Impact | Contingency |
|---|---|---|---|
| App Store rejection Apple rejects the build |
Medium | High | Submit by D−30 to allow 2 resubmission cycles. Keep Android live as fallback. Focus lead collection on Android users first. |
| Not enough Hosts Buddies sign up but no one publishes a ride |
High | High | Founder personally converts the top 5 vehicle-owner leads. Call them. Do it by video if needed. The first 3 hosts are the most important people in the pilot. |
| Low corridor density Leads are too spread out to match |
Medium | High | Enforce corridor rule strictly. Refuse leads outside zones. Concentrate all promoter effort in 1 corridor until density exists, then expand. |
| OTP delivery failure Users can't log in |
Low | Critical | Have a backup OTP provider configured and tested before launch. If primary fails, switch within 30 minutes. Founder notified immediately. |
| First ride bad experience Host or buddy has a conflict on ride 1 |
Medium | Medium | Founder personally follows up with both parties within 24 hours. Offer to mediate. Do not let one bad ride become a negative WhatsApp story. |
| Promoter no-show A promoter doesn't turn up for a field slot |
Medium | Low | Always have a backup person on standby. Founder or field coordinator covers if no backup. Track promoter reliability from D−20 dry runs. |
| API/SignalR outage Real-time features break during active rides |
Low | High | Set up uptime monitoring with instant alerts (PagerDuty or similar). Tech on call during 7–10 AM and 5–8 PM windows when rides are active. |
The biggest risk is not technical. The highest-probability failure is "not enough hosts." Every process in this playbook that touches host acquisition should be treated as a P0 priority.
| Scenario | Decision | Next Steps |
|---|---|---|
| ✅ 3+ active groups, 10+ rides completed, users asking for more | Expand | Open Priority 2 and 3 corridors. Hire a second field coordinator. Begin word-of-mouth growth campaign. |
| ⚠️ 1–2 active groups, rides happening but slowly | Continue & Optimise | Stay in Priority 1 corridor. Identify and fix the #1 retention issue. Set a 2-week extension target before next expansion decision. |
| ❌ 0 active groups, or groups that formed but dissolved | Diagnose & Pivot | Do not expand. Hold a root-cause session. Is the problem: product, matching, host supply, trust, or timing? Fix the root cause with a new 30-day plan. |