Franchise Revenue Intelligence

Engineering revenue operations at enterprise scale.

Published indicatorSimulated valuesProposed architecture

01 · Business problem

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.

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.

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.

Existing process

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.

02 · Mathematical foundation

Reconciliation: transaction matching

Simulated values

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

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

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

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

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

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

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

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

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

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.

Run the calculation

03 · Technical 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.

Architecture layers

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.
Simulated values
Communication and agents
WhatsApp, email and the management agent.
Published indicator
Learning and MLOps
Predictive models, optimization and monitoring.
Proposed architecture

Layers marked as published are backed by the case’s public information; the others are explanatory models or proposed evolution.

04 · Agentic execution

Ingestion Agent Simulated values
Receives titles from ERP, spreadsheets and email and standardizes the data.
Reconciliation Agent Simulated values
Matches payments to titles and isolates what is ambiguous.
Exception Agent Simulated values
Detects anomalies and classifies priority.
Communication Agent Published indicator
Talks over WhatsApp and email, 24/7, with first response within one minute.
Next Best Action Agent Simulated values
Suggests the next action within the network policy.
Management Agent Published indicator
Gives management a view of the portfolio and of collections.

Agents execute within the policy defined by Zamp. When a rule is exceeded, an exception appears and a person takes the decision.

Execution workflow

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.
Simulated values
Communication
Contact over WhatsApp and email, 24/7.
Published indicator
Human escalation
People decide what exceeds the limit.
Simulated values
Outcome tracking
Management follows the portfolio and collections.
Published indicator

05 · Business impact

~1,500

Stores in the network (approximate)

+1,000

Titles per month

+500 h

Hours of manual work avoided per month

4.5/5

Network satisfaction with collections

Stores in the network (approximate) Published indicator
Network whose collections run on the platform.
Titles per month Published indicator
Financial obligations handled per month.
Hours of manual work avoided per month Published indicator
Figure published at menlopagamentos.com.br/subway.
Network satisfaction with collections Published indicator
Published score.
First response Published indicator
Within one minute in 100% of cases.
Service Published indicator
24/7, over WhatsApp and email, with a management agent.
Collections and return Published indicator
Increase in total collections and positive ROI in the first year, with no public percentages.

Before

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.

06 · Evaluation & learning

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.

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.

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.

Open the interactive algorithm tour

The tour walks through eleven chapters, from data quality to the learning system.