Key Takeaways
- Restaurants are capacity you signed and customers are demand you influenced, but rider supply has to be re-created every hour in a specific place by people who owe you nothing.
- A rider counts as supply only when four conditions hold at the same moment: online, inside the zone, carrying nothing, and willing to accept the offer at the pay and distance shown.
- Counting rider hours delivered into a zone during a window, rather than counting registered riders, changes how you staff, forecast and pay for coverage.
- Demand arrives as two sharp peaks with a long trough between them, so a fleet sized for dinner is idle most of the day and the operator, the rider or the customer pays for those empty hours.
- You cannot promise riders total freedom and customers guaranteed coverage at the same time, so every operator is choosing a point on a line rather than solving the problem.
Hourly Supply Signals
- Report available riders per open order every five minutes per zone, and never as a citywide daily average.
- Convert every hiring target into a rider hour target for a named zone and a named hour of the day.
- Split online rider time into idle, riding to restaurant, waiting at restaurant and carrying, then attack the waiting bucket first.
- Track third and tenth completed deliveries per new rider instead of signup completions, and throttle intake to first-shift quality.
- Cap the incentive line deliberately so waiting-time and density work has to compete for the same budget.
Real Insights
- A roster only grows because nobody ever deregisters, which makes it pleasant to report and useless to plan a Friday evening with.
- Incentives buy a rented hour while fixing prep estimates at four slow restaurants buys every Friday from now on at no recurring cost.
- The reinforcing loop runs backwards with the same force it runs forwards, and an under-supplied peak is that spiral compressed into ninety minutes.
- Rider churn concentrates in the first two weeks, so a badly staged first shift converts acquisition spend directly into a rider who never opens the app again.
- Miracuves builds food delivery dispatch platforms with zone-scoped dispatch, rider telemetry and fleet oversight already in place, and eligible ready-made scopes follow a 6-day deployment path for the build itself.
It is 18:55 on a Friday. The dispatch console is showing one zone, four square kilometres of dense housing above a strip of restaurants. Orders are arriving at a pace that will nearly double in twenty minutes, and the map is the only thing on the screen that matters.
The database says one thousand one hundred and eighty riders are registered in this city. The zone map says nine are online here. Four of those nine are already carrying an order. One is riding back from a drop that took him outside the boundary. That leaves four.
Nothing in the roster number helps at 18:55. It cannot be dispatched or apologized with. The only figure that exists for the next hour is four, and the operator’s entire job between now and 21:00 is to make that figure larger, in this zone, using people who have no obligation to help.
That is the part of a four-sided marketplace almost nobody models correctly. Restaurants sign once and stay. Customers arrive on their own schedule and marketing nudges it. Riders have to be re-created every hour of every day, in a specific place, and a food delivery dispatch app lives or dies on how well it does that.
Grubhub does not count riders, it manufactures rider hours, and the difference decides whether orders move at all.
Signed Up Is Not Supply in Food Delivery Dispatch
A platform like Grubhub can have thousands of signed-up riders and no supply at seven on a Friday.
Most founder decks carry a rider number. It is almost always the wrong number, because it counts people who once completed a form rather than capacity available to a customer ordering now.
Image Source: AI-generated visual by Miracuves
The Roster Number That Means Nothing
A registered rider is a completed onboarding record. It does not tell you whether that person has opened the app this month, still owns the vehicle they registered, or moved to another city in March. Rosters also only grow, because nobody deregisters, which makes the number pleasant to report and useless to plan with.
Four Conditions, All Required at Once
A rider is supply only when four things are true at once. They are online. They are inside the zone, or close enough to enter before the food is ready. They are not already carrying, or are close enough to their drop to be chained onto the next one. And they will accept the offer at the pay and distance shown.
Those four filters multiply rather than add. A zone can hold plenty of logged-in riders and still have no supply, because they are all mid-delivery at exactly the moment a kitchen finishes a bag.
The fourth condition is the one founders forget exists. Acceptance is voluntary. A rider looking at an offer that pays poorly for the distance will simply not press the button, and no amount of engineering turns that into a technical problem.
The Ratio Worth Putting on a Wall
Track available riders per open order, sampled every five minutes, per zone. Available means online, inside the zone and carrying nothing. Open order means placed and not yet collected.
That single ratio explains almost every customer complaint you will receive. Comfortably above one, assignment is instant and cycle times match the estimate. Below one, orders queue behind riders rather than behind kitchens, and that queue is invisible to everybody except you. Publish it hourly and by zone, because a daily citywide average hides a catastrophic Friday inside a calm Tuesday.
Why Dispatch Treats Rider Supply as a Flow, Not a Stock
A stock is something you have. A flow is something that passes through. Restaurant supply behaves like a stock, since a signed restaurant is still signed next month. Rider supply behaves like water in a pipe, and the pipe is refilled or empty every single hour.
The Unit Is the Rider Hour, in a Place
Once you accept the reframing, the unit of account changes. You stop counting riders and start counting rider hours delivered into a specific zone during a specific window, the way a power company counts megawatt hours rather than generators.
Two hundred riders who each work an hour a week and three hundred riders who each work twenty are entirely different businesses with similar-looking rosters. The second has supply. The first has a mailing list.
What Changes in Planning
Hiring targets become hour targets. Instead of onboarding four hundred riders this quarter, you plan to deliver a number of rider hours into the two evening peaks in three named zones, and work backwards to how many people that requires at your current activity rate.
The Shape of Demand a Delivery Dispatch Operation Covers
Food demand is not spread through the day. It arrives in two sharp columns with a long flat valley between them, and a thin tail after the second column collapses.
Image Source: AI-generated visual by Miracuves
Two Peaks and a Long Trough
The lunch column is short, often ninety minutes wide, with tight expectations because people are on a break with a fixed end. The dinner column is taller, wider and more forgiving on time, and it is where most of the money and almost all of the failure lives.
Between them sits an afternoon carrying perhaps a tenth of dinner volume. It is not a smaller version of the peak but a different operating condition.
The Fleet Is Sized for the Tall Column
Coverage is set by the worst hour you intend to serve properly. If the dinner peak needs forty riders online to keep assignment instant, forty is what your supply engine has to be able to produce, even though the afternoon needs six.
A fleet sized for the peak is idle most of the day by construction. That is not a planning failure. It is the shape of the demand, and the only question is who carries the empty hours.
Somebody Pays for the Idle Hours
There are three payers. The operator pays, through guarantees or shift pay that runs whether orders arrive or not. The rider pays, sitting unpaid between drops and absorbing the variance personally. Or the customer pays, through fees high enough to fund coverage that is fully used twice a day.
Most operators do a blend without writing it down. Writing it down is worth an afternoon, because the blend decides which of your three sides leaves first. The fee and margin side of that question sits on the business model page.
What Makes a Rider Come Online at Seven in the Evening
A rider deciding whether to work tonight is making a fast, rational calculation. They are not comparing your platform with a job. They are comparing the next three hours with staying at home, and the input is expected earnings per hour, not per drop.
Predictable Hourly Earnings Beat a Good Headline Rate
A platform paying generously per delivery while supplying one delivery an hour is a bad place to work. A platform paying modestly while reliably supplying three is a good one. Riders work this out within a fortnight and behave accordingly, whatever the recruitment advertising said.
Predictability matters as much as the level. An hour that might return a lot or almost nothing is worth less to somebody managing rent than a lower hour they can count on, so variance costs you supply even when your average looks competitive.
Density Produces the Hourly Number
Deliveries per hour come from short distances between restaurants and customers, restaurants clustered rather than scattered, and enough volume that the next offer arrives before the rider has finished thinking about the last one. The rider does not experience your coverage map. They experience the metres between drops.
Dead Time and Waiting at Counters
Every minute a rider spends waiting for food that was promised ready is an unpaid minute, and riders account for it precisely even when platforms do not. A prep estimate that is consistently optimistic is a wage cut administered by your software.
The same goes for the long ride back from a drop at the zone edge with nothing to collect on the way. Respect for a rider’s time is the cheapest lever you have on supply, because it raises earnings per hour without raising your cost per delivery.
Measuring it needs real telemetry rather than guesswork, which is why location accuracy and update frequency belong in the architecture conversation early. The practical limits are in Sub-2 Second Tracking: Load-Testing GPS Delivery Updates on Flutter and Laravel.
Why Incentives Are the Costliest Way to Buy Dispatch Supply
Every operator eventually reaches for a bonus. It works, which is the problem. It works instantly, it works without fixing anything, and it goes on working only while it is paid.
A Bonus Is a Rented Hour
Paying extra for Friday evening coverage buys exactly that Friday evening. Next Friday costs the same, and the one after slightly more, because riders adjust their expectations to the highest recent rate rather than the average.
Fixing the prep estimates at four restaurants that habitually keep riders waiting buys every Friday from now on, at no recurring cost. One is an operations project, the other a payment, and the payment always happens first because it needs no meetings.
Patching a Bad Operation Compounds
When a bonus exists to compensate for long waits, poor density or unpredictable dispatch, it has to keep growing, because the underlying condition degrades while the money hides it. The bonus line stops being marketing spend and becomes maintenance on a fault nobody is fixing.
Incentives are defensible in three places: opening a zone with no history, covering a genuinely abnormal event such as a storm, and paying for a commitment rather than an outcome. Everywhere else, read a rising incentive line as a fault report about the operation.
The Loop Runs in Both Directions
The reinforcing loop in this business is usually drawn once, running forwards, on an optimistic slide. It is worth drawing twice, because the same arrows run backwards with exactly the same force.
Forwards, It Compounds
More riders online shortens the gap between an order being ready and a rider collecting it. Shorter waits produce better delivery times. Better times produce more orders from the same customers. More orders raise deliveries per rider hour, which raises earnings, which brings more riders tomorrow.
Every step in that chain is measurable and every step takes days rather than quarters, which is why density in a small area beats coverage across a large one in the first year.
Backwards, It Is a Spiral
Fewer riders online means longer waits before collection. Food sits and cools. Delivery times slip past the estimate. Customers order less often, which thins volume, which lowers deliveries per rider hour, which lowers earnings, which means fewer riders tomorrow.
An under-supplied peak is that spiral compressed into ninety minutes. It feels violent from the console because all four sides degrade at once: the customer is waiting, the restaurant’s food is dying on a shelf, the rider is earning badly in traffic, and you are refunding.
Recovery is not symmetrical. Falling out of the loop takes one bad week and climbing back takes several good ones, because rider habits reform more slowly than they break.
Utilization Explains Almost Everything Else
If you keep one operational number beside the availability ratio, keep utilization: the share of online rider time actually assigned to an order, from acceptance to handover.
Busy Is Not the Same as Utilized
A rider waiting at a counter for a late order is busy and is not earning. A rider riding six empty kilometres back from the zone edge is busy and is not earning. Both look like activity from outside and feel like unpaid work from the saddle.
Split online time into four buckets and report them separately: idle waiting for an offer, riding to a restaurant, waiting at the restaurant, and carrying to a customer. Only the last is unambiguously productive, and the third is the one you can shrink fastest.
Too High Is Also a Warning
Utilization near the ceiling is not a triumph. It means there is no slack, so one breakdown or a kitchen running fifteen minutes late pushes a queue of orders past their estimates with nothing to absorb it.
Run deliberate headroom at peak, and make its size a decision rather than an accident. A zone that hits its ceiling every Friday is one small failure away from a bad evening.
Churn Is Decided in the First Two Weeks
Rider churn is not evenly distributed across tenure. It concentrates at the beginning, and the people you lose in the first fortnight are the ones you paid most to find.
The Bad First Shift
A new rider’s first evening goes wrong in an ordinary way. They start in a quiet hour, because that is when they had time. They get two offers in three hours. One restaurant keeps them waiting twenty minutes and the staff are short with them, because nobody at that counter has met a rider from your platform before.
They go home having earned a fraction of what the recruitment message implied, and they never open the app again. Nothing broke. No support ticket was raised. The loss is invisible unless you are specifically looking for it.
Onboarding Is an Operations Problem
Most platforms treat onboarding as document collection. The documents are the easy part. The hard part is engineering a first shift that goes well: starting new riders inside a peak rather than a trough, in the densest part of the zone, on restaurants with reliable prep.
Measure completion of a third and a tenth delivery rather than of a signup form. Those two milestones tell you whether an acquisition cost turned into rider hours.
How fast an operations team can act on this depends on the tooling, part of what the dispatch and fleet feature set must cover before your first zone opens.
Founder Decision Signals
Speed
Supply cannot be bought ahead of time. Your launch date is set by how fast you can produce rider hours in one zone at one hour of the day, not by when the software is ready.
Cost
A rising incentive line is a fault report, not a growth cost. Before approving another peak bonus, check waiting time at your five worst restaurants and the empty distance riders ride back.
Scalability
Rider hours do not transfer between zones the way servers transfer between regions. Every new area re-creates its supply problem from zero, so plan capacity per zone and hour, never per city.
Market Fit
If riders in your densest zone cannot reliably complete two drops an hour at peak, the zone is too thin or too wide. Fix the geometry before spending on recruitment.
Flexibility Versus Reliability Is the Real Tension
Here is the contradiction at the centre of the model. You promise riders they can work whenever they like. You promise customers that food will arrive within a stated window. Those two promises cannot both be absolute, because the second requires somebody to be there at 19:30 whether or not they feel like it.
Two Promises That Contradict
Pure flexibility gives you a supply curve you observe rather than control. On an ordinary Tuesday that is fine, because habit produces a stable pattern. On the first cold, wet Friday of the season it produces a shortfall exactly when demand spikes, and no dispatch logic can assign an order to nobody.
Pure reliability means committed coverage you pay for whether it is used or not, and it drifts from the arrangement most riders joined for. Every operator ends up between the two poles, and the honest framing is that you are choosing a point on a line, not solving a puzzle.
How Operators Actually Reconcile It
Three mechanisms do most of the work in practice. Each buys reliability with a different currency, and none of them is free.
Buying Coverage Without Buying Certainty
| Mechanism | What it buys | What it costs |
|---|---|---|
| Open marketplace, no commitment | Maximum reach, zero fixed cost, the widest recruitment funnel | Coverage you observe rather than control, failing worst on abnormal evenings |
| Bookable shifts or slots | Known coverage for a known window, so a peak forecasts honestly | Administration, no-show handling, and a structure some riders will not accept |
| Priority access tiers | Better offers or earlier booking for riders who show up | Perceived fairness risk, and new riders find the first fortnight harder |
| Zone commitment for a block | Density where you need it, lifting everyone’s deliveries per hour | Riders lose route freedom, and enforcement needs judgement rather than rules |
Most mature operations run a mixed fleet: a committed core sized to minimum acceptable peak coverage, and an open pool above it that flexes with demand. The ratio between them is one of the few genuinely strategic decisions in the model, and the software has to support both from the first release. That balancing act runs through How to Keep Restaurants, Riders, and Customers Happy Simultaneously.
The Legal Question Belongs to Your Counsel
How commitment, scheduling and priority interact with employment status differs by country, by city and by year, and it moves. Nothing here is advice on that, and no software product can answer it for you.
What a platform can do is make the arrangement you chose visible and recorded: who committed to what, what was offered, what was accepted, and what was paid. Take the classification question to a lawyer in your own market before you design the commitment model, not afterwards.
The Restaurant Side Is a Different Problem Entirely
It is worth stating what the restaurant side is not, because the contrast carries the whole argument. A signed restaurant is fixed capacity that stays put. It does not need re-acquiring at 18:55. Availability is a switch somebody flips when the kitchen is overwhelmed, and that switch is the extent of the hourly supply question on that side.
The operational risk there is the prep estimate rather than the volume of supply. A kitchen that says twelve minutes and takes twenty-five is not failing to exist, but failing to predict, and that lands on riders as unpaid waiting and on customers as lateness. Restaurant work is accuracy work. Rider work is availability work. Conflating them produces an operations team that is busy in the wrong place.
What the Customer Is Actually Buying
The customer side is simpler than most product roadmaps assume, and misunderstanding it leads to building the wrong things.
They Are Buying the Elimination of a Trip
Nobody pays a delivery fee for food. They pay it to not get dressed, not drive, not park and not stand in a queue. The product is the removal of twenty-five minutes of their evening, and the meal is what arrives at the end of it.
That is why time is the only feature that competes with price here. A cheaper platform that takes an hour is not a cheaper version of the product. It is a worse one, because the trip it eliminated has been replaced by waiting.
Lateness Damages You, Not the Kitchen
When food arrives cold and late, the customer rarely blames the restaurant. They blame the name on the app, because the app made the promise, took the money and chose the rider. Attribution follows the interface, not the fault.
That is uncomfortable and it is also correct. You chose the estimate, so you own the estimate. It also means an under-supplied evening damages the asset you spent the most to build, which is the habit of opening your app first.
What the Platform Contributes That No Side Can
Given three participants who each run their own business, it is fair to ask what the platform is for. The answer is three things none of them can do alone, described feature by feature in Which Features Does a Food Delivery Dispatch App Need for Order Assignment, Rider Tracking, and Fleet Control?.
Matching Under a Clock, and a Record That Settles Arguments
Deciding which rider takes which order, in seconds, while food is cooling and vehicles are moving, is a genuinely hard problem no restaurant or rider can solve from their own position. It is also the part of the system that saturates first at volume.
Alongside it sits the record. Every transition gets a name and a time: accepted, ready, collected, arrived, handed over. When three parties remember the evening differently, those timestamps are the only neutral account. They are also how supply planning improves, because without them a long wait at a counter is an anecdote a rider told support.
Moving Money Between Four Parties
One order splits into a restaurant payout, a rider payout, a platform margin and, where cash is taken at the door, a float that has to be reconciled rather than trusted.
Payout timing deserves a specific mention on the supply side. Riders decide whether to work tonight partly on when they will see the money, so the settlement schedule is a supply parameter and not purely a finance one. How those lines are structured is set out on the platform build page.
Three Operator Shapes, and Which One You Are Building
Supply strategy is not universal. It depends on which of three businesses you are actually running, and founders often discover in month four that they are running a different one than they planned. The build-or-adapt side of that choice is covered in Ready-Made Delivery Food delivery dispatch app vs Custom Development: What Should Food Delivery Startups Choose?.
The Dense-City Marketplace
You hold demand, supply and the customer relationship. Rider supply is your hardest recurring problem and your deepest advantage, because density compounds and a competitor entering your zone has to out-earn you on a rider’s hourly maths first.
Strategy here is narrow and deep. Win one zone completely, then use its supply as the recruiting story for the next, which is the logic behind our food delivery solution.
The Delivery-as-a-Service Operator
You carry other people’s orders. Demand arrives from restaurant brands and other platforms, so you do not spend on customer acquisition, and your product is reliability sold to businesses rather than choice sold to consumers.
Supply strategy inverts. Because clients want guaranteed windows, you need more committed coverage and less open-pool flexing, and you price idle hours into a contract rather than absorbing them. Operators in this shape often start from a white-label delivery app so the brand on the rider bag is theirs.
The Multi-Category Fleet
You carry food at meal times and something else in between: parcels, pharmacy, groceries, documents. This is the only one of the three that directly attacks the trough, because the afternoon valley is filled with a different category rather than paid for.
It is also the hardest to run. Categories differ in handling rules, vehicle requirements, temperature needs and failure modes, and your rider needs competence in all of them. Category has to be a first-class concept from the first schema, which is a build decision rather than a configuration one, and worth raising with the team that builds these platforms before you commit.
Where Supply Planning Usually Goes Wrong
These six mistakes recur across operators of every size. They share one root: treating an hourly flow as a stock that can be counted once and relied on. The reporting that exposes them is what hosted builder products tend not to give you, an argument made in Migrating from SaaS to Owned Infrastructure: A Peak-Hour Performance Comparison.
Reporting roster size instead of rider hours
A growing registration count is compatible with falling coverage. Report available rider hours per zone per daypart, and leave the roster number in the recruitment dashboard.
Buying peak coverage instead of fixing dead time
Bonuses are instant and operations projects are slow, so the bonus wins every planning meeting. Cap the incentive line and make the waiting-time work compete for the same budget.
Onboarding faster than you can stage a good first shift
Recruiting two hundred riders into a zone that can give only sixty a decent opening evening converts acquisition spend into churn. Throttle intake to the quality of the first shift.
Treating the afternoon trough as a supply failure
Low coverage at 15:30 is usually correct behaviour. Either fill the trough with a second category or accept it, but do not pay peak-level incentives to staff an hour with no orders.
Using one acceptance target for every hour
A rejection rate that is healthy at lunch signals a pricing or distance fault at peak. Set expectations per daypart and zone, because a citywide threshold hides the failures and the wins.
Promising coverage nobody has committed to provide
Selling a guaranteed window to a business client while running an open pool transfers uncontrolled risk onto a contract. Match the commitment you sell to the one you hold.
Final Thoughts: Supply Is Made, Not Owned
Rider supply is a flow Grubhub produces hourly. A roster is not the same thing.
The asymmetry is the business model. Restaurants are capacity you signed. Customers are demand you influenced. Riders are supply you manufacture, hour by hour, in a named place, from people who owe you nothing and can close the app at any moment without telling you.
Once that is the organizing idea, the operating decisions follow. You measure hours rather than heads. You read a rising incentive line as a symptom. You size the fleet for the tall column and decide who carries the empty hours. You engineer the first shift as carefully as the first order. And you state the flexibility trade honestly instead of pretending it has been solved.
The software should make that visible rather than obstruct it, which is what our food delivery app development work is built around, with the delivery window itself explained on our facts page. If you are sizing a first zone, or trying to work out why your peak keeps failing, book a consultation and we will walk through the supply numbers before anybody writes code.
FAQs
How does the Grubhub business model manage rider supply?
Four conditions have to be true at the same moment. The rider is online. They are inside the zone, or close enough to enter it before the food is ready. They are not already carrying, or are close enough to their current drop to be chained onto the next one. And they will accept the offer at the pay and distance shown. Those filters multiply rather than add, so a zone full of logged-in riders can still have no supply.
Why is registered rider count the wrong dispatch planning number?
Because a registration record only proves somebody once uploaded a document. It does not tell you whether that person opened the app this month, still owns the vehicle they registered, or moved away. Rosters also only grow, since nobody deregisters, which makes the figure pleasant to report and useless operationally. Plan instead with rider hours delivered into a named zone during a named window, which is the quantity a customer can actually feel.
Which number should a delivery dispatch operations team watch?
Available riders per open order, sampled every five minutes and reported per zone. Available means online, inside the zone and carrying nothing. Open means placed and not yet collected. Comfortably above one, assignment is instant and cycle times match the estimate. Below one, orders queue behind riders rather than behind kitchens, and that queue is invisible to everyone except you. A daily citywide average will hide a failing Friday inside a calm Tuesday.
How large does a food delivery dispatch fleet have to be?
Large enough for the worst hour you intend to serve properly, which is almost always the dinner peak. That is a structural consequence rather than a planning error, and it means the same fleet is idle through the afternoon. Someone carries the cost of those empty hours: the operator through guarantees or shift pay, the rider by sitting unpaid between drops, or the customer through fees. Most operators blend all three without writing it down.
Why do incentives get more expensive every month?
Because a bonus rents an hour rather than fixing the reason the hour was empty. Riders adjust expectations to the highest recent rate, not the average, so next week costs the same and the week after costs slightly more. When the bonus exists to compensate for long waits at counters or thin density, the underlying condition keeps degrading while the money hides it. Treat a rising incentive line as a fault report about the operation.
What makes a rider choose to work tonight?
Expected earnings per hour, not per drop, and how predictable that figure is. A platform paying well per delivery while supplying one delivery an hour is a bad place to work. Deliveries per hour come from short distances, clustered restaurants and enough volume that the next offer arrives quickly. Waiting unpaid at a counter for food promised ready is the fastest way to lower the number without lowering your own stated pay rate.
Why do so many new riders quit inside two weeks?
Because the first shift usually goes wrong in an ordinary, invisible way. They start in a quiet hour, get two offers in three hours, wait twenty minutes at a counter where nobody knows your platform, and go home having earned a fraction of what recruitment implied. Nothing breaks and no ticket is raised. Measure third and tenth completed deliveries rather than signup completions, and stage first shifts inside a peak in your densest area.
Can you promise riders full flexibility and customers a guaranteed window?
Not absolutely, and pretending otherwise is the most common mistake in the model. Operators reconcile it with bookable shifts, priority access for consistent riders, or zone commitments for a block, and each one buys reliability with a different currency. Most mature operations run a committed core plus an open pool above it. How any of this interacts with employment status varies by market and changes, so take that question to your own legal counsel.
Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by any company or product named in this article.
Terms such as “X Clone” are used descriptively. It is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it.
The entire design and codebase of our products is built by our own team. Our products contain no code, design, graphics, or content originating from any third-party website or applications.
All third-party names and marks referenced in this article are the property of their respective owners, referenced solely to identify the services discussed.
