How to Compare Delivery Fees Across Apps

To compare delivery fees fairly, hold the basket, restaurant, delivery address, time and customer state constant, then record every mandatory charge separately. Repeat the same scenario across apps, cities and user types. The useful benchmark is not the lowest fee in one screenshot. It is the fee ladder: how delivery, service and small-order charges change with distance, basket value, location, account status and time.

Key points for a reliable delivery fee benchmark

Compare matched orders, not unrelated screenshots.
Keep delivery charges, service charges and other mandatory fees as separate fields.
Treat account status, membership, promotions and location as part of the scenario.
Compare fee curves and distributions, not only citywide averages.
Record unavailable restaurants as unavailable, never as a zero fee.
State the market, period, sample, denominator and limitations behind every result.

What should a delivery fee comparison include?

A delivery fee benchmark is a structured comparison of the customer-facing charges attached to a food delivery order. It should include every mandatory charge shown before an optional tip, while preserving the platform’s own labels.

Capture these components separately:

Basket subtotal: Record the items, quantities, listed prices and item-level discounts so the team can see whether baskets are genuinely comparable.
Delivery charge: Keep the exact amount and displayed label. The charge may differ by address, distance, time or other observed conditions.
Service charge: Record the amount, displayed rate and stated calculation base, if shown. A percentage is not useful if the base is unclear.
Small-order or minimum-order charge: Store both the amount and the displayed threshold. This charge can change which app has the lowest total for a small basket.
Other mandatory charge: Keep the platform’s exact label and amount so locally specific charges do not disappear into an average.
Promotion, credit or membership benefit: Record the amount and eligibility condition. This separates a standard fee structure from a user-specific benefit.
Final total before optional tip: Capture the amount shown to the customer so the final comparison can be checked against its components.

Do not rename different charges into one generic fee during collection. A delivery charge and a service charge can follow different rules. Combining them too early removes the pattern that pricing and e-commerce teams need to see.

For the wider menu and product-matching process, see Getplace’s guide to menu and price comparison at scale.

Build matched delivery scenarios before comparing platforms

The strongest comparison changes one variable at a time. Start with a reference order and freeze the fields that should remain constant.

Fix the delivery point. Use the same address or geographic coordinate for every platform in the local comparison.
Match the restaurant and basket. Use the same restaurant branch, items, quantities and options where possible. Mark substitutions instead of treating them as exact matches.
Capture at the same time. Record the timestamp and time zone. A morning observation and an evening observation are not a matched pair.
Separate customer states. Anonymous, new, active, subscribed and non-subscribed users may see different conditions. Do not mix them in one average.
Record promotions and credits. Note whether a discount was automatic, account-specific, membership-based or absent.
Repeat the observation. A single checkout shows what one customer could see at one moment. Repeated collection shows whether the pattern persists.

If an exact match is impossible, label the comparison as partially matched and explain the difference. It is better to preserve an honest gap than create false precision.

Why customer state must be part of the benchmark

One logged-in account cannot represent every customer. Account status, membership, credits, promotions and previous activity can change the conditions displayed at checkout.

Treat each state as a separate scenario. Do not combine anonymous, new, active, subscribed and non-subscribed users until the team has checked the distributions underneath the summary.

The checkout establishes what that account saw at that moment. It does not reveal why the platform produced the result. A difference between user states is a finding to document and investigate, not proof of the platform’s internal fee logic.

Compare fee ladders across basket values and delivery distances

One basket is rarely enough. A platform can be cheaper at one order value and more expensive at another because delivery charges, service rates and small-order thresholds may change at different points.

Create a test grid for each app and city:

a fixed set of locally relevant basket values;
a fixed set of delivery points or distance bands;
the same restaurant or a clearly defined matched restaurant set;
agreed customer states and membership conditions;
consistent collection times, with additional time windows where variation matters.

Then calculate the same measures for every eligible observation:

Total mandatory fees: Add all mandatory customer-facing charges before an optional tip.
Fee burden: Divide total mandatory fees by the defined basket subtotal and multiply by 100. State exactly which subtotal is used.
Pre-tip checkout total: Add the basket subtotal and mandatory charges, then subtract applicable discounts or credits.
Difference from the reference app: Subtract the reference total from the comparator total for the same matched scenario.

Do not force a value where a restaurant is unavailable. Availability is a separate result that can be commercially important, but it is not a zero-fee order.

Compare cities without hiding local conditions

A cross-city benchmark should use a common method, not assume that every city is the same. Keep the local currency, fee labels, taxes where displayed, platform coverage and restaurant availability visible in the underlying data.

For each city, report:

the number of eligible matched observations;
collection dates and time windows;
platforms and customer states covered;
the median and range for each fee component;
the share of matched scenarios in which each platform had the lowest pre-tip checkout total;
missing or unavailable observations.

If results are combined across cities, explain the weighting. A simple average can let a city with few observations count as much as a city with broad coverage. Cross-currency comparisons also need a stated exchange-rate source, date and method. When that conversion adds no value, compare fee-burden percentages within each market instead.

Track change over time without assuming the cause

Fees can look different by time, location and customer context. A useful monitoring programme repeats matched scenarios on a schedule and records changes in the displayed components.

When a fee changes, the data establishes what the customer saw. It does not automatically establish why. Weather, demand, courier supply, a promotion, a subscription rule or a platform test may be consistent with the timing, but causation needs additional evidence.

A pricing team can act on a confirmed checkout gap without claiming to know the competitor’s internal rule.

What QSR and delivery-platform teams can decide from the benchmark

For a restaurant chain, fee benchmarking shows where the customer proposition becomes less competitive even when menu prices are aligned. It can reveal which cities, addresses, baskets or customer states need closer investigation.

For a delivery platform, the same method shows how its customer-facing fee ladder compares under matched local conditions. The result can support market reviews, customer-segment analysis and proposition design without reducing the market to one headline fee.

The central decision is not simply which app is cheapest. It is where each app is cheaper, for which customer, under which order conditions, and whether that pattern holds over time.

What delivery fee benchmarking cannot prove

One checkout does not represent a platform, city or customer segment.
A displayed fee difference does not reveal the platform’s internal pricing rule.
A change that appears during bad weather or high demand does not prove either condition caused it.
An unavailable restaurant is not evidence of a zero delivery fee.
A cross-city average is not meaningful unless currencies, coverage and weighting are stated.
A lower checkout total does not prove higher conversion or stronger customer retention.

These limits do not make the benchmark less useful. They define the decision it can support: where the customer-facing fee structure differs enough to investigate.

Frequently asked questions about delivery fee benchmarking

What is delivery fee benchmarking?

Delivery fee benchmarking is the repeated comparison of customer-facing charges for matched food delivery orders. A sound benchmark separates delivery, service and small-order charges, then compares them by platform, location, basket, customer state and time.

How can two users see different fees for the same order?

Displayed fees can differ when account state, membership, promotions or other conditions differ. The checkout alone does not explain the cause, so teams should record each condition and avoid treating one account as representative of every customer.

Can delivery fees be compared across countries?

Yes, but local currencies, taxes, fee labels, platform coverage and restaurant availability must remain visible. Use a documented currency-conversion method when comparing amounts, or compare fee burden within each country when conversion would obscure the local result.

How often should delivery fees be collected?

The schedule should match the decision. A one-off market review may use several tightly controlled collection windows. Ongoing competitive monitoring needs repeated observations at consistent times, plus targeted checks when the displayed fee structure changes.

The useful benchmark is the conditional one

A citywide average can tell you that one platform looked cheaper in the sample. A matched, conditional benchmark tells you where that answer changes. That is the level at which pricing and platform teams can make a defensible decision.

If your team needs to connect fee observations with menu-price monitoring across apps and locations, explore Getplace’s restaurant pricing intelligence.

About the evidence

This is a method-led article and does not introduce a new quantitative benchmark. It draws on three approved Getplace and Denis Chernobaev source posts about delivery and service fees, together with Getplace’s published restaurant delivery analytics framework. The posts identify relevant comparison dimensions, including platform, city, district, distance, basket value, customer state and time.

No numerical result from the posts is reproduced. The underlying datasets and collection methods were not supplied, and one customer-state example does not identify its market. Those gaps prevent the examples from meeting the publication standard for a material figure.

Sources

Getplace. What Is Restaurant Delivery Analytics? Pricing, Coverage and Visibility Explained. 16 August 2026.
Getplace. Menu and Price Comparison at Scale: A Guide for Multi-Location Brands and Delivery Platforms. 3 July 2026.
Denis Chernobaev. Same basket and restaurant, different Wolt service fees by user state. LinkedIn, 11 June 2026. Market and underlying dataset not supplied; figures not used.
Denis Chernobaev. Delivery-fee structures compared in Romania. LinkedIn, 2 June 2026. Underlying dataset not supplied; figures not used.
Denis Chernobaev. Delivery conditions and availability in Bucharest. LinkedIn, 17 June 2026. Underlying dataset not supplied; figures and causal claims not used.

How to Compare Delivery Fees Across Apps, Cities and Customer Types