A pet-care booking app, rebuilt as a marketplace

IncrediPets runs a pet-care services business in Delhi NCR and Mumbai. Dog training, grooming, vaccination and walking are booked in an app and delivered at home by field partners. When I joined as product manager in December 2025, the business had two problems that fed each other: partners arrived late, and most users booked once and never came back.

The problem#

Supply. Fewer than half of sessions started on time. Partners had no live view of their own punctuality, so penalties arrived as unexplained wallet deductions. CX and operations had no single score for a partner, so the same escalation was handled differently by different people.

Why supply decided demand. A user whose partner arrives late is about 3x less likely to rebook. Punctuality was not an operations metric sitting next to retention. It was the biggest input to retention.

Demand. The app gave people a reason to open it only when a service was due. My analysis in June showed where the funnel broke:

• Of the people who signed up in a 30-day window, 11.7% reached a booking and 4.6% reached a successful payment.
• 63.6% of people who ever booked did so on the day they signed up or the next day. If they did not book then, they almost never did.
• In the same 30 days, for every 10 people shown an available service, about 7 were told at least once that no service was available at their address. Supply was a hard ceiling on demand.

Supply: a graduated penalty and rewards engine#

The old model penalised lateness without showing partners where they stood. I rebuilt it as a programme of eight PRDs around one rule: a partner should always be able to see their score, what will cost them money and how to recover.

• One visible score. Each booking is scored by how far off its start time was, from full credit for on time to zero for a no-show, over a rolling 30 days. Scores fall into four bands (Red, Amber, Green, Elite) shown on the partner app’s home screen, with copy that says exactly how many on-time bookings it takes to reach the next band. A composite score (ratings 40%, punctuality 40%, tenure and volume 20%) feeds assignment priority.
• Graduated penalties. Penalties grow with severity and with repeat offences inside a rolling 30-day counter. Late and early starts share one counter, so a partner cannot dodge escalation by alternating between them. Any counter resets after five consecutive on-time sessions. A false commitment never costs less than an honest no-show, and usually costs more.
• Rewards on the same ledger. Streak bonuses arrive at 10, 15, 30 and 60 on-time sessions, doubling each time. Streaks also earn shields, which absorb one late or early start penalty. A partner who warns the customer in the app 10 to 50 minutes before the start pays half the penalty, up to 10 times in 30 days. Being honest about running late is cheaper than going silent.
• A rule for “when did it start?” Evidence is ranked: partner GPS within 100 metres of the address, then the partner’s own tap, then the scheduled time plus a short grace period. If two sources disagree by more than 10 minutes, the booking is flagged for audit instead of guessed.
• Caps on daily load. Daily booking limits by band, so the system stops setting partners up to fail before it penalises them.

Over my time there, partner on-time sessions went from under 50% to 75%.

Demand: from booking app to marketplace#

The second half was giving people a reason to come back between bookings.

• AI-generated diet charts and interactive pet-training features made the app useful between appointments, not only on the day of a service. I tracked diet-chart generation closely: it succeeded on 79.2% of attempts in the 30 days to 2 June and on 90.2% in the first ten days of June, and failures fell from 17.4% to 7.9%.
• A master plan for the marketplace. I wrote the plan that turns the services app into a single marketplace for services, products and membership. It has a unified home and a five-item navigation (Home, Services, Shop, Membership, Profile and Pets), recurring service packs offered by default at checkout, auto-replenish for pet food at 15 to 60 day intervals, reminders when a vaccination, grooming or session is due, and one rewards wallet built on the ledger that already held partner penalties.
• Ranked with RICE, not by excitement. The cheapest item scored highest: instrumentation, at 16.8 against 4.8 for the revamp as a whole. Without it, none of the later phases could be measured.

The recurring-user rate grew 5x, from about 5% to 25%.

Measuring what the business ran on#

A lot of the job was making the numbers trustworthy before acting on them.

• The quarter’s headline metrics were invisible. On-time rate and session completion existed only in the operational database, with no events in the analytics tool. I flagged bridging them as a P0.
• Two “collapses” were not real. A day with less than a tenth of the usual completed sessions was simply a Sunday, when sessions barely run. A daily-active-user “drop” of about two-thirds came from a narrower saved definition; on the broad definition usage had not fallen. Session alerts had to become day-of-week aware, or every Sunday would raise a false alarm.
• Payment success fired under two event names. Counting one name gave a 20.9% conversion and counting both gave about 40%, so no one could quote the real number until the events were merged.
• No experiments were running on a funnel that lost 88% of new users before their first booking.

Results#

• Partner on-time sessions went from under 50% to 75%, across Delhi NCR and Mumbai.
• The recurring-user rate grew 5x, from about 5% to 25%.
• I led a 20+ person engineering and design team across both problems.

What is still open#

75% was the new floor, not the finish. The next target was more than 90% on time, and session completion from about 85% to more than 95%. By late June the score was live and the penalty engine was in code review. Partner tiers, a fairness layer (force-majeure grace and anti-fraud signals) and the deactivation and appeals process were written up but not yet built.

What I’d do differently: ship the fairness rules with the first penalty. The fairness layer was mine to review, and it sat for weeks while it held up the partner-app side of the penalty engine. I would also build the travel-time check before hard accountability. A partner can only be held to a schedule that was realistic in the first place.