Crisla
Pott

Rappi's marketplace operations were reactive by design. When a restaurant integration failed, a payment processor went down, or supply-demand imbalances spiked, the ops team discovered problems through customer complaints — not early detection. Incident response took over an hour. By then, hundreds of orders were affected and recovery costs were high. No centralized monitoring, no automation, no shared playbook across countries.

---

Rather than patching individual problems, I focused on building infrastructure for proactive operations: a system that could detect anomalies in real time, route them to the right people, and resolve them before they escalated. Foundation before headcount — tooling first, then team structure.

---

100+ real-time alerts built from scratch to detect anomalies across integrations, payments, restaurant performance, and supply — all verticals, 9 countries.

"Supervisor Online" model: Centralized shopper support through a WhatsApp-based triage bot, reducing on-site supervisors from 30 to 7 across LATAM — shifting from physical presence to remote queue management.

10+ automation bots for escalation, containment, and reporting — eliminating manual work that previously required dedicated headcount.

Holiday operations framework: Plug-and-play playbooks for peak days — pre-activating monitoring rules and response teams before incidents could occur.

---

OCC strategy & design · Backoffice product ownership · Process architecture & documentation · Ops-to-tech translation · Cross-functional alignment · Team efficiency & automation.

---

Operational excellence is a product problem. The best interventions weren't process changes — they were systems that anticipated failures, automated response, and freed humans to focus on judgment-heavy exceptions. You can't fix what you can't see.

When users wanted to cancel an order, Rappi's flow went straight to confirmation — with no attempt to understand why or offer alternatives. Many cancellation intents were actually fixable problems: wrong address, preferred payment method unavailable, or order running late. The result was avoidable order loss, revenue impact, and a poor experience for users who would have stayed if given the right option at the right moment.

---

Rather than accepting cancellation as the default outcome, the new flow intercepts the moment of intent and presents the user with relevant alternatives: change the delivery address, switch payment method, or accept a compensation to wait for a delayed order. Each option is shown conditionally — only when technically feasible and contextually relevant. The right option at the right moment creates retention; an irrelevant one creates friction.

---

Foundation first: modernized the underlying tech infrastructure with engineering before shipping any new UX — to avoid building on a fragile base that would limit future iterations.

Context-driven logic: designed rules for when to show each modification option based on order status, vertical, and cancellation reason — not a one-size-fits-all screen.

Validated incrementally: launched delay compensation first as the simplest, most measurable intervention — generating proof of concept before investing in more complex modification flows.

---

End-to-end PRD ownership · Problem framing & solution scoping · Cross-functional alignment with engineering, design, data, and ops · A/B test design & metric definition · Prioritization of rollout sequence across modification types.

---

---

Led the scoping, spec, and delivery of a VoIP integration using Amazon Chime — covering permission flows and fallback logic for Android and iOS. Shipped to 80% of users before leaving Rappi. Expected to improve courier-user contactability, reduce "customer not home" cancellations, and decrease order not delivered complaints.

Every day, thousands of customers opened support tickets claiming their order never arrived. The support team had no way to determine who was telling the truth — the driver claimed delivery, the customer claimed otherwise. With no evidence system, the default was to compensate the customer to avoid risk. This created two problems: significant monthly costs from unwarranted payouts, and no way to identify patterns of fraud or driver misconduct.

---

Rather than relying on manual case review, I led the development of a microservice that automatically analyzes the full order lifecycle at the moment a customer opens a ticket. The key insight: the evidence already existed in our systems — geolocation, photos, timestamps, chat history. We just needed to connect it and surface it at the right moment, before a human made a decision.

---

Prioritized 'order not delivered' over other defect types (damaged product, poor quality) because it had the highest user friction and the richest evidence trail.

Built the diagnosis at ticket-creation time — so the support agent received the evidence before making any decision, not as an afterthought.

Designed the output as a clear recommendation (evidence found / not found) rather than raw data — reducing cognitive load on support agents and standardizing decisions across teams.

Launched first in smaller markets (Uruguay, Peru) as a controlled experiment. Initial results were below expectations, so we refined the model before rolling out to larger markets.

---

End-to-end problem framing & solution scoping · Alignment with engineering and support teams · Prioritization rationale & rollout sequencing · Experiment design & post-launch iteration.

---

Beyond cost savings, the system created a consistent, data-driven standard for resolving disputed deliveries — reducing variability across support agents and countries. The evidence was always there. The product problem was surfacing it at the right moment.

⚡ AI-assisted build

A personal project to prove a concept: a solo PM, using AI tools and cloud infrastructure, can ship a working geospatial product in a short iteration cycle — without a dedicated engineering team.

---

An interactive demand forecasting map for Bogotá that shows where food delivery orders concentrate across the city, in 30-minute time windows, for the next 3 days. Couriers see where demand is heading before it peaks. The same architecture scales to any city with order history.

---

Data: 30-day order history (lat/lng, timestamp). Spatial indexing: Uber H3 hexagonal grid at resolution 9 (~0.1 km² per cell). Forecast: Statistical demand profile per hex — fully explainable, no black box. Score: Percentile ranking (1–5) per time window, the same approach used by Uber and DoorDash. Exclusion: AK30 highway corridor removed via buffer geometry — a real operational barrier in Bogotá logistics. Stack: Python · pandas · h3 · shapely · Kepler.gl · AWS S3.

---

ChatGPT and Claude throughout the pipeline: architecture design, geospatial edge case debugging, Python scripts, scoring methodology validation. Claude Code for refactoring. From concept to live demo in a few weeks of part-time work.

---

View live demo ↗