Case · Subway Brasil · Franchise Revenue Intelligence
Engineering revenue operations at enterprise scale.
It is the case with real operation and published evidence: approximately 1,500 stores, more than 1,000 titles per month and more than 500 hours of manual work avoided monthly, with 4.5/5 satisfaction. Models, curves and simulations in the tour and on this page are explanatory and are labeled.
01
Executive summary
Since April 2025, collections for the Subway network in Brazil have run on the Menlo Tech platform. Zamp defines the policy: criteria, control points and how far to go with a franchisee who is late. Menlo Tech executes within those limits, across the whole base, without anyone having to trigger step by step.
It is the case with real operation and published evidence: approximately 1,500 stores, more than 1,000 titles per month and more than 500 hours of manual work avoided monthly, with 4.5/5 satisfaction. Models, curves and simulations in the tour and on this page are explanatory and are labeled.
- ~1,500Stores in the network (approximate)
- +1,000Titles per month
- +500 hHours of manual work avoided per month
- 4.5/5Network satisfaction with collections
02
Business context
A franchised network of about 1,500 stores generates thousands of financial obligations between the franchisor and each store every month.
The challenge is not to collect more: it is to handle each obligation with the right criterion, at the right time, without multiplying manual work.
03
The operational problem
Accounts receivable spread across many stores, with data coming from systems, spreadsheets and email.
Payment reconciliation against titles, collection workflows, financial communication, transaction monitoring and operational reporting, all disconnected.
04
Current process and limitations
Before
- Fragmented financial workflows.
- Manual payment reconciliation.
- Reports disconnected from operations.
Limitations
- Effort grows with the number of stores.
- Deciding whom to contact first is intuitive.
- Exceptions get lost between spreadsheets and messages.
05
Data architecture
Titles
Financial obligations between the network and each store.
- Amount and due date
- Reference and store
- Source: ERP, spreadsheets and email
Payments
Inflows to reconcile against titles.
- Amount and date
- Payment identifier
- Payment with no matching title
Relationship
Conversations and answers per channel.
- WhatsApp and email
- First response and service
- Negotiation requests
Network policy
Rules defined by Zamp.
- Criteria and control points
- Negotiation limits
- When a person decides
The demonstration uses a synthetic portfolio. There is no access to real Subway financial data.
06
Mathematical formulation
Reconciliation: transaction matching
Simulated values · Illustrative parametersBusiness interpretation
The exact identifier resolves first. The rest is scored by reference, date, amount and relationship between entities.
Variables
- scorematch score between payment and title
- wₖweight of attribute k (reference, amount, due date, store)
- simₖsimilarity of attribute k, between 0 and 1
Objective function
Match each payment to the right title and isolate what is ambiguous.
Constraints
- Exact identifier takes priority.
- Pairs with intermediate scores go to human review.
- Duplicates and incomplete data become pending items and do not enter collections.
Practical example
A payment with no identifier, with the same amount and date as a title from the same store, gets a high score; if two titles are candidates, it goes to review.
Business implication
Automatic reconciliation covers what is clear and hands the analyst only what is doubtful.
Assumptions and limitations
The weights and threshold in the tour are explanatory and must be calibrated with operations.
Anomaly detection
Simulated values · Illustrative parametersBusiness interpretation
It measures how far a value departs from the expected pattern, in standard deviations. Beyond the limit, it becomes an exception for analysis.
Variables
- zstandardized deviation of the observed value
- xobserved value (for example, a payment)
- μmean of the expected pattern
- σstandard deviation of the expected pattern
Objective function
Separate real exceptions from noise with an explicit limit.
Constraints
- The limit on |z| is defined by policy.
- The expected pattern should be estimated by comparable group (for example, by store profile).
Practical example
A payment far above or below the store’s history generates an exception for analysis.
Business implication
Human attention goes to what departs from the pattern.
Assumptions and limitations
The roughly-normal-distribution assumption does not always hold; limits must be validated with real data.
Priority scoring
Simulated values · Illustrative parametersBusiness interpretation
It combines risk, amount, payment propensity and elapsed time into a score that orders who deserves attention first.
Variables
- Rᵢnormalized risk of title i
- Aᵢnormalized amount
- Pᵢpayment probability (the weight’s sign is a policy decision; in the demonstration we use 1 − P)
- Tᵢnormalized elapsed time
- α β γ δweight of each term
Objective function
Order collection actions by priority.
Constraints
- Terms normalized between 0 and 1.
- Weights must be calibrated with operational evidence; the ones in the demonstration are illustrative.
- Policy defines what is never done, however high the score.
Practical example
In the demonstration, moving the weights reorders the portfolio and shows, per title, how much each term contributed.
Business implication
Priority stops being intuition and gets an explanation per title.
Assumptions and limitations
Without calibration against real data, the score is a reasoning tool, not a forecast.
Optimization under capacity
Simulated values · Illustrative parametersBusiness interpretation
The team has limited hours. Choosing which actions to execute means maximizing expected value within the effort budget.
Variables
- xᵢ1 if action i is executed
- vᵢexpected value of action i
- aᵢeffort of action i
- bavailable capacity (hours)
Objective function
Maximize the expected value of the chosen actions.
Constraints
- The sum of efforts does not exceed capacity.
- Actions outside policy do not enter.
- Each action is either in or out.
Practical example
In the demonstration, reducing the hours capacity reduces the set of selected actions and shows the value left out.
Business implication
Limited effort is allocated where it can return the most.
Assumptions and limitations
Expected value depends on payment models that are still proposed; the example selection is greedy and illustrative.
Collection states as a Markov chain
Simulated values · Illustrative parametersBusiness interpretation
Each title lives in a state: issued, upcoming, overdue, notified, in negotiation, paid. The transition matrix describes how titles usually advance.
Variables
- Xtitle state at step t
- Pᵢⱼprobability of moving from state i to state j
Objective function
Understand the portfolio flow and anticipate where it tends to go.
Constraints
- Each row of the matrix sums to 1.
- Paid is an absorbing state.
Practical example
A policy change that moves the reminder earlier shifts the probability of going from upcoming to paid.
Business implication
It allows evaluating policy changes in simulation before applying them.
Assumptions and limitations
The probabilities in the tour are explanatory, not measured.
07
AI and agent architecture
- Ingestion AgentReceives titles from ERP, spreadsheets and email and standardizes the data.Simulated values
- Reconciliation AgentMatches payments to titles and isolates what is ambiguous.Simulated values
- Exception AgentDetects anomalies and classifies priority.Simulated values
- Communication AgentTalks over WhatsApp and email, 24/7, with first response within one minute.Published indicator
- Next Best Action AgentSuggests the next action within the network policy.Simulated values
- Management AgentGives management a view of the portfolio and of collections.Published indicator
Policy layer
Agents execute within the policy defined by Zamp. When a rule is exceeded, an exception appears and a person takes the decision.
08
Execution workflow
- Simulated values
Financial data ingestion
Titles from ERP, spreadsheets and email reach the platform.
- Simulated values
Transaction normalization
Fields are standardized and duplicates flagged.
- Simulated values
Reconciliation
Payments are matched to titles.
- Simulated values
Exception detection
Deviations from the pattern become pending items for analysis.
- Simulated values
Priority classification
The score orders what to do first.
- Simulated values
Agent orchestration
Agents execute the steps within policy.
- Published indicator
Communication
Contact over WhatsApp and email, 24/7.
- Simulated values
Human escalation
People decide what exceeds the limit.
- Published indicator
Outcome tracking
Management follows the portfolio and collections.
09
Interactive demonstration
A synthetic portfolio: from priority to the outcome ledger
The 12 titles below are fictitious. Adjust the priority score weights, see why each title sits where it does, simulate team capacity and follow the approval workflow. Nothing is sent and there is no access to real Subway data.
10
Governance and human oversight
Zamp defines the policy: criteria, control points and how far to go with a franchisee who is late.
Menlo Tech executes within those limits. What exceeds the limit goes to a person, with the reason recorded.
Every state change becomes an event, in order, which makes it possible to rebuild each title’s path.
Three monitors watch the model in operation (calibration, drift and human feedback) once predictive models exist; this monitoring is part of the proposed evolution.
11
Operational outcomes
- ~1,500Stores in the network (approximate)
- +1,000Titles per month
- +500 hHours of manual work avoided per month
- 4.5/5Network satisfaction with collections
- Stores in the network (approximate)Network whose collections run on the platform.Published indicator
- Titles per monthFinancial obligations handled per month.Published indicator
- Hours of manual work avoided per monthFigure published at menlopagamentos.com.br/subway.Published indicator
- Network satisfaction with collectionsPublished score.Published indicator
- First responseWithin one minute in 100% of cases.Published indicator
- Service24/7, over WhatsApp and email, with a management agent.Published indicator
- Collections and returnIncrease in total collections and positive ROI in the first year, with no public percentages.Published indicator
Annualized calculation from the published monthly figure (500 h/month × 12). It is not a separately audited result and uses “more than 500 h” as a floor.
CalculationBefore
- Fragmented financial workflows
- Manual reconciliation
- Disconnected reporting
After
- Structured financial intelligence
- Prioritized actions
- Automated coordination
- Measurable operational efficiency
How to measure (proposed definitions, no published values)
- Hours saved
- Reconciliation accuracy
- Exception rate
- Collection efficiency
- Cost per processed transaction
- Average resolution time
Source: indicators published by Menlo Tech at menlopagamentos.com.br/subway. There are no public recovery percentages and none is inferred here.
12
Limitations and assumptions
- Only the indicators marked as published are real operating results.
- Curves, probabilities, weights and simulations are explanatory and use synthetic data.
- There are no public recovery percentages, and none is inferred.
- The 6,000 hours per year figure is an annualization of the published monthly number, not a separately audited result.
- The demonstration does not access real Subway data.
13
Technical architecture
- Simulated values
Ingestion and normalization
ERP, spreadsheets and email into a structured portfolio.
- Simulated values
Reconciliation and exceptions
Matching, anomalies and pending items.
- Simulated values
Decision and priority
Scoring, segmentation and next best action.
- Published indicator
Communication and agents
WhatsApp, email and the management agent.
- Proposed architecture
Learning and MLOps
Predictive models, optimization and monitoring.
Layers marked as published are backed by the case’s public information; the others are explanatory models or proposed evolution.
14
Future opportunities
- Calibrate priority weights and payment probabilities with operational data.
- Introduce predictive models with calibration and drift monitoring.
- Optimize the allocation of team capacity under policy constraints.
- Publish new indicators when there is verification and authorization.
Discuss a challenge in your operation
Tell us the process you want to improve. We reply by the email you provide.
Discuss a challenge in your operation