# The Passion Table — Delhi Pilot Playbook

## Pilot objective

Prove that recently relocated professionals will pay for, receive reliably, and extend a structured 7- or 14-day meal-continuity service.

The pilot is successful only when **customer demand, operational reliability, and contribution margin** are simultaneously credible.

## Fixed pilot scope

- **Geography:** Saket, Hauz Khas, Greater Kailash, and immediately adjacent serviceable pockets.
- **Customer:** professionals who moved within the previous 30 days or will move within the next 14 days.
- **Product:** two meals per day for 7 or 14 days.
- **Capacity:** maximum 30 active subscribers unless the kitchen and route model is re-approved.
- **Interface:** landing page + WhatsApp concierge.
- **Supply:** one primary kitchen and one backup.
- **Customization:** dietary exclusions and spice preference only.
- **Payment:** full package or clearly defined reservation token before start-date confirmation.

## Roles

| Role | Responsibility |
|---|---|
| Pilot owner | Owns metrics, pricing, partner pipeline, and daily decisions |
| Concierge | Qualifies leads, confirms payment, communicates menu and exceptions |
| Kitchen lead | Owns batch plan, ingredients, hygiene logs, and dispatch readiness |
| Delivery lead | Owns route plan, pickup, ETA, proof of delivery, and escalations |
| Quality owner | Reviews feedback, complaints, recovery, and kitchen scorecard |

One person may hold multiple roles during the pilot, but every responsibility must have an owner.

## Lead pipeline

Use these exact stages:

1. New request
2. Serviceability check
3. Qualified
4. Payment pending
5. Paid / scheduled
6. Active
7. Extension offered
8. Extended
9. Completed
10. Lost / not serviceable

Required lead fields:

- lead ID;
- created date;
- acquisition source;
- name;
- WhatsApp number;
- email;
- move-in date;
- neighborhood;
- selected plan;
- diet and exclusions;
- preferred meal windows;
- serviceability status;
- payment status;
- start and end dates;
- loss reason.

## Customer qualification script

The concierge should confirm:

1. Exact delivery address and landmark.
2. Move-in date and requested service start.
3. Whether two meals per day are required.
4. Vegetarian/non-vegetarian preference and hard exclusions.
5. Preferred breakfast and dinner/lunch windows.
6. Refrigerator, reheating, and basic utensil availability.
7. Pantry or cookware support needs.
8. Agreement with the fixed-menu and fixed-window pilot format.
9. Payment method and deadline.
10. Backup contact for delivery.

Do not accept the order until kitchen capacity and route serviceability are confirmed.

## Daily operating rhythm

### Previous day, 2:00 PM

- Lock active subscriber count.
- Confirm pauses, extensions, and exceptions.
- Freeze menu quantities.
- Route new qualified customers to the next available start date.

### Previous day, 5:00 PM

- Kitchen confirms ingredient availability.
- Backup substitutions are approved.
- Delivery routes and pickup windows are assigned.

### Service day, before first dispatch

- Record batch completion time.
- Complete hygiene and packaging check.
- Verify labels, exclusions, and subscriber count.
- Release only after kitchen and delivery leads sign off.

### During delivery

- Record pickup time, ETA, handoff, and exception code.
- Notify customers proactively when ETA changes by more than 10 minutes.
- Escalate any missed or incorrect order immediately.

### After delivery

- Send one-tap rating request.
- Contact all ratings below 4/5.
- Log the recovery action.
- Review renewal signals and repeated preferences.

## Kitchen onboarding checklist

- Valid FSSAI registration or license verified.
- Kitchen address and responsible operator recorded.
- Hygiene, storage, pest-control, and water checks completed.
- Raw-material suppliers documented.
- Standard recipes and portion weights agreed.
- Allergen and dietary-exclusion process documented.
- Batch and temperature log format tested.
- Packaging tested for the actual delivery duration.
- Daily capacity and stop-sell number signed off.
- Backup menu and backup kitchen defined.
- Incident and recall contact tree confirmed.

## Menu rules

- Maximum two menu paths per meal window.
- Reuse ingredients intelligently across the week.
- Avoid dishes that degrade materially during the delivery window.
- Publish the next-day menu before the order cutoff.
- Never substitute an allergen-sensitive item without explicit confirmation.
- Cost every serving using actual yield, not recipe estimates alone.
- Track plate waste, rejected batches, and customer-return reasons.

## Service recovery rules

| Incident | Required response |
|---|---|
| Delivery more than 20 minutes late | Proactive message plus credit decision |
| Wrong meal or dietary breach | Immediate replacement/refund and quality escalation |
| Packaging leak or unsafe temperature | Do not consume; replace/refund; investigate batch |
| Rating below 3/5 | Same-day call and tagged root cause |
| Repeated menu dissatisfaction | Offer allowed alternate path or end service cleanly |
| Kitchen capacity breach | Stop sales and route only to approved backup |

Every recovery must be logged with cost and root cause.

## Feedback questions

Keep the daily survey short:

1. Overall meal rating, 1–5.
2. Was it delivered within the promised window?
3. Portion: too small, right, or too large?
4. Taste/energy tag: light, balanced, heavy, oily, bland, spicy, other.
5. Would you choose this meal again?
6. Optional comment.

At the end of the package ask:

- What problem did the service remove?
- What was still frustrating?
- Would you extend for another week?
- Would you take a weekday lunch subscription?
- Who else should receive this when they move?

## Pilot dashboard

Track these daily:

- new requests;
- qualified leads;
- paid conversion;
- active subscribers;
- meals planned and delivered;
- on-time percentage;
- complaints by type;
- average rating;
- kitchen cost;
- delivery cost;
- packaging cost;
- recovery/refund cost;
- revenue;
- contribution margin;
- extensions offered;
- extensions accepted;
- referrals.

## Experiment backlog

Run one controlled change at a time:

1. 7-day versus 14-day default.
2. Full payment versus refundable reservation token.
3. Partner referral versus direct acquisition.
4. Pantry add-on messaging.
5. Breakfast + dinner versus lunch + dinner.
6. Fixed menu shown upfront versus menu preview after qualification.
7. Extension offer on day 4 versus day 5.
8. Referral credit versus pantry add-on reward.

Document the hypothesis, segment, dates, result, and decision for every experiment.

## Weekly review

Every seven days, answer:

- Which source produced paid customers?
- Which menu items drove high and low ratings?
- Where did deliveries fail?
- What caused refunds or recovery cost?
- Is route density improving?
- Are customers extending?
- What is the actual contribution margin by plan?
- What should be stopped next week?

## End-of-pilot decision

### Continue and expand

Only when reliability, extension, and contribution targets are met.

### Continue but redesign

Use when customers value the product but price, menu, windows, or kit scope prevent sustainable economics.

### Stop

Use when paid demand remains weak after channel and offer tests, or when reliable delivery cannot be achieved within the intended price.

The purpose of the pilot is not to prove the original idea correct. It is to discover whether a durable business exists.