elmenus Projects

Problem/Opportunity

At elmenus, when Riders collected cash payments from customers for their deliveries, they were required to either directly deposit these amounts into the company account or submit the money to their operators, who would then deposit it. This created two main issues:

Extended Cash Collection Cycle: This process resulted in a prolonged period between order delivery and cash receipt by the company, negatively impacting our profitability targets.
High Risk of Rider Fraud: There was a significant risk of riders delivering orders for a period, collecting money, and then churning without notice or reconciling the collected funds.

Hypothesis

By implementing a wallet feature on the Rider app to track collected order values, we would:

Reduce the percentage of fraud
Maintain better oversight on cash flow
Ensure faster cash collection by implementing a reconciliation threshold, prompting riders to deposit money when the threshold is reached

Solution

We implemented the wallet feature in the Rider app with the following capabilities:

Automated order value reflection - as soon as the order is marked 'Delivered.
Configurable reconciliation thresholds.
Wallet admin panel in Fleet Management System.
Partnership with e-payment third party (Fawry Egypt) - By partnering with Fawry, we leveraged their extensive network of payment hubs across various neighborhoods, making it convenient for riders to deposit collected cash quickly and securely.

Process

As the Product Manager leading the initiative, here's a breakdown of the process I followed:

Collaborated with fleet operations teams to define the problem scope by analyzing cash collection cycles and fraud-related losses.
Explored with stakeholders the key considerations when designing the solution. These included:
- Wallet reconciliation threshold configuration options; per Rider, per delivery pool, per Rider Operator
- Feasibility of partnering with payment providers
- Monitoring tools for operations teams
- Reconciliation conditions and minimum thresholds
Discussed effort requirements with the engineering manager.
Prioritized the project within the existing roadmap based on gauging effort vs. impact.
Conducted a workshop with the tech team to discuss technical implementation and design considerations.
Collaborated with the UX designer to ensure the designs captured all requirements and to brainstorm ideas for an intuitive user interface. This collaboration was particularly crucial given that the majority of our riders weren't tech-savvy. We focused on creating a simple, easy-to-understand wallet feature that would be accessible and user-friendly for riders with varying levels of technological proficiency.
Worked with the engineering manager to break down the work into smaller, estimable tickets.
Collaborated with the engineering manager and stakeholders to define a strategic release plan. We opted for a phased rollout approach, carefully selecting our initial deployment targets. We decided to start by implementing the wallet feature in low-risk delivery pools, which were characterized by:
- Good supply-demand rates: These pools had a balanced ratio of riders to orders, ensuring stable operations.
- Low fraud rates: We chose areas with historically lower instances of rider fraud to minimize potential risks during the initial rollout.
Implemented in low-risk pools first. Monitored performance and gradually expanded to more pools focusing on the main KPIs and success metrics.

KPIs and Success Metrics

Cash collection cycle per pool: To measure the impact of implementing the wallet feature per area (compared to pre-release).
Overall cash collection cycle: To measure the impact of the wallet feature on our overall cash collection (compared to pre-release).
Number of incompliant runners and cash loss (broken down by pool): To measure how successful the wallet feature along with our training efforts for riders were (compared to pre-release).

Results

Achieved 100% cash collection in 1.5 days, improved from 1 week
Contributed to meeting profitability targets for Q3 and Q4 2022

Problem/Opportunity

One of our main goals as a company was to achieve smooth (contactless) deliveries to maximize customer satisfaction as contact during the order delivery process often indicates an issue. A smooth delivery doesn't include any of the following contact types:

Rider to customer contact
Customer to elmenus customer support contact
Rider to customer support contact

Rider to customer contact was particularly common, with riders often contacting customers multiple times per trip. This led to customer frustration and negative feedback on social media and in surveys. Understanding and addressing this behavior was crucial to reduce contact rates and achieve smooth contactless deliveries.

Hypothesis

By addressing obstacles causing riders to call customers, educating them on contactless delivery benefits, and maintaining proper oversight, we could decrease the contact rate, increase smooth deliveries, and improve customer satisfaction.

Solution

Collaborated with the data science team to develop and integrate a machine learning location calibration model, reducing wrong-location-related calls.
Partnered with operations teams to implement a training program for our riders, focusing on customer contact etiquette.
Developed and implemented an incentive program to motivate riders to adopt the new behavior.

Process

As the Product Manager leading this initiative, here's the process I followed to roll out the solution:

Conducted surveys and focus groups with riders to identify common reasons for customer contact.
Implemented an in-app survey to capture real-time data on contact reasons, feeding insights directly to our analytics platform.
Analyzed app data to understand average contact rates and attempts per order, broken down by delivery pools.
Data showed that in about 65% of deliveries, riders contacted customers at least once.
Qualitative data analysis revealed that approximately 80% of contact attempts were location-related, including:
- Missing address details
- Incorrect pin locations
- Unclear address information
Facilitated brainstorming sessions with UX, engineering, and stakeholders to ideate solutions, prioritizing the primary issue of incorrect pin locations.
Collaborated with engineering and data science to develop a location calibration model that:
- Stores and compares delivery locations to original customer pins
- Recalibrates locations after collecting multiple trusted data points
- Continuously refines accuracy through iterative calibrations
Outlined a phased rollout plan, selecting test zones based on diverse neighborhood characteristics and high contact rates.
Monitored key metrics during and post rollout.

KPIs and Success Metrics

Correlation between contact rates and calibrated locations: The hypothesis here is that calibrated locations are more accurate which should lead to a reduction in contact rates.
Contact rates pre and post release (broken down by delivery pool).
Percentage of calls due to incorrect pin locations pre and post release (broken down by pool).

Results

The implementation of the location calibration model, combined with operational improvements in rider training and oversight, yielded significant improvements:

16% reduction in rider-to-customer contact rate
12% increase in smooth deliveries
10% increase in orders rated 5 stars
Notable improvement in overall customer satisfaction and operational efficiency

Background

Elmenus initially started as a simple app providing customers with available restaurants in their neighborhood along with their menus, without offering delivery services. As restaurants were onboarded, they were assigned to zones that aligned with their delivery capabilities. However, as the company grew and started building its own fleet, we aimed to provide more support for our partners by expanding our delivery reach, resulting in the creation of delivery pools that extended beyond the restaurants' delivery boundaries.

Problem/Opportunity

This expansion created a challenge: when customers searched for restaurants, they only received results based on their zones, not considering the delivery pools. This system worked fine for restaurants that managed their own deliveries but resulted in missed opportunities for those covered by our delivery pools but not by the traditional zones. Consequently, 65-75% of order-generating restaurants using our delivery services were losing potential orders from customers located beyond the zone borders but within the delivery pools, especially in suburban areas.

Hypothesis

By aligning customer locations with our delivery pools, we could provide them with more options in search results, including more popular choices, thereby increasing our orders.

Solution

We completely revamped our ordering and delivery structure by separating the search and delivery logic for restaurants based on their delivery methods. This change ensured that customers could see 100% of the options available for delivery to their exact location without any restrictions.

Process

As the Product Manager leading the initiative, here's a breakdown of the process I followed:

Analyzed ordering data to identify the size of the opportunity. Focused on the percentage of missed orders based on the number of specific restaurant searches that yielded no results due to the customer's location being out of zone and the percentage of these visits ending in abandonment. Also examined the percentage of 'Out of zone' errors customers encountered.
Broke down this data to pinpoint specific neighborhoods or areas with the highest potential.
Engaged with stakeholders, particularly the Fleet Operations teams, to further analyze the data and identify immediate opportunities (areas already covered by our fleet but not included in ordering zones) and medium to long-term opportunities (high-potential areas with existing expansion plans). We collectively agreed on the significant business opportunity.
After validating the problem and opportunity from a viability perspective, discussed technical feasibility and dependencies with the Engineering Manager and other relevant teams, such as the Search squad.
Conducted a kick-off meeting with all stakeholders, including restaurant operations, customer support, and fleet operations teams, to explain the initiative's details and its expected impact on both user experience and business outcomes.
Ran a tech kick-off workshop with the entire tech squad to brainstorm approaches, assess risks, and finalize the best implementation plan.
Finalized the Product Requirements Document (PRD) and shared it with relevant teams for review. Broke down the work into tickets in our backlog, which went through the normal cycle of estimation and prioritization.
Ahead of the go-live date, collaborated with stakeholders to review initial estimates for high-opportunity and high-risk areas and developed a contingency plan.
After the go-live, monitored overall performance, including the number of orders, to ensure there were no unexpected losses due to the change.
For three months post-release, reported on the performance of our delivery pools in terms of the number of orders and success rate (in comparison to pre-release), with a focus on new areas of expansion.

KPIs and Success Metrics

Expansion % of our fleet coverage: This directly measures the primary goal of expanding delivery reach, ensuring that the fleet can cover more areas.
Number of new orders coming from newly added zones: This metric will help quantify the success of the new delivery pools by tracking the orders from newly covered areas.
% new-zone orders out of overall orders: This provides insight into how significant the new zones are in contributing to overall order volume, reflecting the success of the expansion.
Demand increase due to fleet expansion: This metric captures the overall impact of the expansion on customer demand, indicating the broader success of the initiative.
% of rejected/out-of-zone orders pre and post release: This will show the effectiveness of the new system in reducing missed opportunities due to delivery zone restrictions.

Results

Expanded our delivery coverage by 33%, incorporating 17 new zones previously excluded by the legacy zone structure.
Increased demand by 11%, translating to an additional 2.75 million EGP in weekly revenue.