Crisla
Pott

A large LATAM marketplace's 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.

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, the platform'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 the user base. Designed 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.

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.

Delivery platforms in LATAM face a growing threat during driver onboarding: synthetic-identity fraud — AI-generated profile photos reused across multiple fraudulent driver registrations under different documents. Manual fraud review is slow, inconsistent, and doesn't scale. No automated system existed to detect fraud rings across applications.

An end-to-end fraud-detection pipeline covering three layers of defense: document OCR cross-validation to catch inconsistencies between submitted documents; AI-generated image detection to flag synthetic profile photos; and facial-embedding deduplication to surface fraud rings — the same face registered under multiple different identities.

Translated a manual process into automatable rules first — mapped every step the ops fraud-review team did manually, identified which decisions followed consistent logic, and converted those into business rules and risk-scoring thresholds before writing a single line of code.

Modular architecture — each detection layer (OCR, image, face) operates independently, so the system can flag a case based on any single signal or a combination, and each module can be iterated without breaking the others.

Risk scoring output, not binary decisions — the system surfaces a risk score and evidence summary for human review, rather than auto-rejecting applications, keeping a human in the loop for edge cases.

Claude Code as the primary development partner: scaffolding the pipeline architecture, iterating on the OCR validation logic, debugging embedding comparisons, and reviewing the risk-scoring model. This is consistent with my AI-first building approach — AI as co-pilot from architecture to implementation.

During mass events — carnival street parties, protests, large concerts, elections — the ops team had to manually identify which stores fell inside the affected area and close them individually at the right time. This was slow, error-prone, and entirely dependent on someone scanning a map and remembering to act at the exact moment the event started.

A tool that automates the entire process: input a location, define an affected area, and the system identifies and schedules closures automatically. Two modes to match real-world event shapes: radius mode for point-based events (concerts, stadiums) and line mode for linear events (parade routes, marches), each expandable by a custom distance.

Scheduled closures at the exact event time — removing the ops team from having to be present at a specific hour and manually trigger anything.

Built line mode as a second iteration — after seeing that many real-world events (parades, marches) don't fit a simple radius, expanding applicability without adding complexity.

Scaled across all 9 countries once validated — disruptive events (protests, holidays, elections) are a universal operational challenge, not market-specific.

Customers didn't place orders that couldn't be fulfilled. Couriers weren't sent into unsafe areas. Stores weren't overwhelmed trying to serve demand they couldn't meet. The team no longer needed to manually monitor or intervene at the exact moment an event began.

Store supervisors across the grocery/mart operation were spending most of their time solving algorithm-driven problems — courier assignment, order cancellations, routing — rather than focusing on in-store quality. The root cause wasn't a staffing issue. It was a product gap: the work these supervisors were doing didn't require physical presence, but no system existed to let them do it remotely.

A WhatsApp-based bot where shoppers identify themselves and select their issue from a structured list. Simple cases resolve automatically; complex cases route to a remote support queue. WhatsApp was chosen because it required zero onboarding — shoppers already used it daily.

Single global decision tree — one structured taxonomy covering all markets, rather than bespoke flows per country.

Human team for judgment-only cases — only genuinely complex issues reached a person, keeping the support team small and focused.

Full interaction logging — every conversation created a data trail for tracking resolution time and identifying patterns for future automation.

Problem identification & reframing (staffing → product) · End-to-end solution design & issue taxonomy · Cross-functional delivery with engineering · Rollout across 9 countries.