Vending Route Management Software
Vending routes planned around what each machine actually needs.
Your operators drive the same rounds, count cash by hand, and reconcile card payments in spreadsheets after a long day. We turn that route work into one system: stock alerts before a machine runs dry, cash and card matched per machine, and a clear profit figure for every machine on the route.
Bring one route problem. Leave with a build, buy, repair, or wait recommendation.
Trusted by
The brief
Start with what is not working.
Good software decisions begin with the constraint, not a list of features or a preferred technology.
Cash counts and card-reader reconciliation stitched together in spreadsheets after a long route day.
No warning before a machine runs dry, so the empty machine is found by an unhappy customer, not by the system.
Fixed rounds that visit full machines and miss the ones that needed attention yesterday.
Plain answer
Vending route management software plans each operator's day around what machines need. It reads sales and stock data per machine, flags machines that will run dry, builds the day's route and pick list, and reconciles cash counts against card payments. The result is fewer wasted trips, fewer empty machines, and a clear profit figure for every machine on the route.
What to remember
- Plan the day from machine need, not from a fixed calendar: visit the machines that will run dry, skip the ones still full.
- Reconcile cash and card per machine, not per month: differences get flagged while the visit is still fresh.
- Profit per machine is the decision number: it ranks machines, routes, and host locations by what they actually return.
- The first release should complete one route end to end: data in, route out, reconciliation out.
- A system earns its keep when the route team uses it at the machine, not only when the office reviews it.
- Code, data, and accounts stay under your control, so another capable team can operate the system.
The first decision is whether software is the answer.
It is not which features to buy. We use four possible recommendations before discussing a development scope.
- 01
Buy
Choose a maintained vending product when it handles the core workflow and the remaining gaps can be solved with setup, a connector, or a small process change. Paying for software you do not have to maintain is often the better trade.
- 02
Repair
Keep the existing product or spreadsheet system when the route team still gets value from it and the gaps are narrow. Start with evidence: where the records live, how cash and card are matched, which machines report data, and where the day actually breaks down.
- 03
Build
Own the system when the route operation itself shapes margin: unusual host terms, mixed connected and unconnected machines, several warehouses, or a profit model no maintained product expresses. Start with one complete route and the connections that route cannot work without.
- 04
Wait
Do not turn changing host terms or an unsettled product range into permanent software. Stabilise the terms, name the route owner, and measure the cost of the current route process before paying for a system.
Not sure which path is yours? Bring it to a 30-minute call. Leave with the answer in writing.
Fit
Vending software should earn its maintenance burden.
A feature list is not enough. The case is real when the same constraint shows up in wasted trips, empty machines, or month-end reconciliation.
Routes are planned by calendar while machines run dry between visits and full machines get visited anyway.
Cash counts and card payments are matched by hand, and differences surface weeks after the visit.
Nobody can say which machines, routes, or host locations actually return money.
A maintained vending product fits with reasonable setup and your routes fit its planning model.
The team wants software to settle unresolved host terms or an unsettled product range.
The brief is a feature list with no route, machine, or money result attached.
Not sure which side you are on? Use the first call to make that decision. A useful answer may be to buy, connect, repair, or wait.
Start with the route, not the software.
A vending route problem usually starts as a driving problem. The operator leaves the warehouse with a fixed round, visits machines that are still nearly full, and learns about the empty machine from the host location's phone call, not from any record. Back at the end of the day, cash bags are counted and card reader exports are opened. The two are stitched together in a spreadsheet while the details of each visit are still fresh enough to argue about and too stale to verify.
The visible complaint may be "we need route software." The real cost sits in three places. Trips that did not need to happen come first: fuel, driving time, and warehouse picking spent on machines that could have waited. Lost sales come next: the machine that ran dry on a Friday and stayed empty until Monday. Unexplained money completes the picture: cash counted against card payments with no per-machine record, so a shortfall has no visit, no machine, and no amount attached to it.
A second product hides inside the first. The customer sees a full machine. Your team lives in another set of screens: routes, pick lists, cash counts, card matching, faults, host terms, and a record of who did what at which machine. Quotes that squeeze all of that into one line item are where budgets most often break. On a real route system, your team's screens are routinely the most underestimated part of the work, so we quote them as their own job, with their own users, from the start.
How the system learns what each machine needs
Some machines report their own activity. They send sales and stock data through the standard data formats the vending industry uses for machine reporting, known as DEX and MDB, or through the card reader platform that already processes their card payments. When a machine reports, the system knows what sold, what is left in each slot, and how much cash is sitting in the machine, without anyone driving to it.
Many machines report nothing. That is normal, and the system is designed for it. On those machines, the operator records the visit on the phone at the machine: cash counted, products refilled, faults noticed, meter readings taken. The phone entry becomes the machine's record, in the same shape as the reported data, so connected and unconnected machines sit in one picture.
From either source, the system learns the same three facts per machine: what sells and how fast, what is left, and what money came in. Sales speed turns into days left for each product. Days left turn into the visit list. The visit list turns into the route. Nothing in that chain depends on every machine being connected. It depends on every visit being recorded, by machine or by phone, in the same record.
The system, in five parts.
The interface is only one part of the job. The real scope includes the data each machine sends or gets counted, the rules that turn that data into a route, the money matching, who can see and change what, and who runs it after release.
Routes planned from need, not from calendar
The day's route is built from machines that need attention: low stock, a fault, a scheduled inspection, or a cash collection. Machines still full are left alone. Routes respect driving time, host access hours, and service windows, and they adjust during the day when a new fault alert or a cancelled visit arrives. A route that passes near a machine due for service within days can cover it now, instead of triggering a separate trip later.
Stock alerts and refill forecasting
Each product in each machine has a minimum stock line and a sales speed from its own history. The system works out how many days each product has left and flags machines before they run dry, not after. The pick list for the truck is built from the same numbers: exact products and quantities per machine, organised for warehouse picking, with product expiry dates visible so short-dated stock goes out first.
Cash counts that match the truck
Cash is counted the way it is counted: bag by bag, in the order the notes come off the stack, with a dictated note where a count needs explaining. The count is entered on the phone at the machine, attached to that machine and that visit, and kept as the machine's cash record. No recount from memory at the end of the day, and no cash figure that belongs to no machine in particular.
Card reconciliation without the month-end drag
Card payments arrive as an export from the card reader platform and are matched to machines automatically. Cash counts are matched against the same sales record. Only the differences worth chasing get flagged, with the machine, the visit, and the amounts attached. Everything else is filed. Month-end stops being a reconstruction exercise and becomes a review of exceptions.
Profit per machine, per route, per location
Each machine carries its own money picture: sales in cash and card, product cost, visit cost, and expenses for that machine. That gives a profit figure per machine, which rolls up to a profit figure per route and per host location. The ranking answers the operating questions: which machines earn their visits, which routes carry dead weight, and which host locations deserve attention or renegotiation.
Which part hurts most on your routes?
Bring it to a 30-minute call. Leave with a build, buy, repair, or wait recommendation in writing. Free, whether or not we ever work together.
Several routes, one picture
One route is the first release. Several routes are where the system pays for itself a second time. The failure mode changes: it stops being "one operator's spreadsheet" and becomes "several spreadsheets that disagree."
Every route draws from the same machine, location, product, and money records. A substitute operator can run any route from the phone app on day one, guided by the route, the pick list, and the machine's own history, instead of learning one operator's private system. Pick lists are built per route from the warehouse that serves it, so a route served by two warehouses does not pick from the wrong one. Host locations keep their own terms in their own record: access hours, service windows, product rules, and commission terms, respected by every route that visits them.
The office picture follows the same rule. All routes, all machines, and all money sit in one place, with task completion reported per operator, per machine, per region, and per period. When a route deviates from the plan, the deviation is visible: planned visits against driven visits, with reasons attached. That is what makes a second route, a third warehouse, or a new host location a matter of adding records, not rebuilding the system.
Let the working day pick the shape.
The way the work happens should decide the form of the software. Start with where the user works, which device they have, whether the signal drops, what data they need, and how fast the system must respond. Those facts tell us what belongs in the first release.
Mobile app
Work at the machine: cash counts, refill confirmation, fault notes, photos, and route progress, with entries saved on the device when the signal drops and sent on when it returns. When in doubt, this is the surface that decides whether the route team uses the system at all.
Web app
Work done across roles and locations. The office plans routes, reviews exceptions, watches money per machine, and manages host terms in a browser: no installs, no versions, no device limits.
One product may need several surfaces. Each one should support the same complete workflow, not start another feature list.
How it works
Each stage removes one risk before the next opens.
Each stage answers a buyer question and leaves behind a decision you can inspect. The next stage only opens when the expensive uncertainty in the current one is small enough to accept.
- 01Understand
Trace one real route
Where is the cost or failure actually coming from?
Follow one operator and one route from warehouse to last machine. Include the workarounds, the manual judgement, the recounts, the waiting, and the failure paths that a tidy process diagram usually misses. The baseline is measured here, so the new system has something to beat.
Decision produced
A map of one route: machines, locations, host terms, cash and card flow, and the baseline cost of wasted trips, empty machines, and reconciliation time.Risk closed
Paying to automate the visible symptom while the expensive constraint remains. - 02Shape
Choose the first useful release
What needs to exist together for one useful result to work?
Choose the shape from the way the work happens, not from a preferred technology. Name the user, the device, the data, the system connections, who can access what, the exceptions, and the result the first release must complete. Service visits and extra routes are named as later phases, not smuggled into the first one.
Decision produced
One route end to end: machine and location records, sales and stock data in, a daily route and pick list out, cash and card reconciliation out, and a profit figure per machine, with a clear definition of done.Risk closed
A small-looking feature list that quietly depends on several interfaces, systems, and owners. - 03Prove
Review working software
Will it hold up outside a controlled demo?
Review the product against the agreed route, not a tour of finished screens. Record changed assumptions and test what happens when data is missing, access is wrong, a machine reports nothing, or a connected system fails. The route team tries it on a real route before anyone calls it done.
Decision produced
Working checkpoints tested with realistic data, real user types, system connections, recovery plans, and the people who will use or run the system.Risk closed
Discovering the important gaps during migration or after operators depend on the release. - 04Transfer
Release, measure, and hand over
Did the new workflow improve the original constraint, and can another capable team operate it?
Move a controlled set of routes or records first. Compare wasted trips, empty machines, reconciliation time, or another agreed measure with the starting point before adding the next route.
Decision produced
A controlled release, comparison with the baseline, operating notes, account ownership map, and a recommendation for what should happen next.Risk closed
Measuring development activity instead of the business result, or depending on the original vendor to keep the system running.
What stays out of the black box
These are operating conditions to put in the engagement, not claims to take on faith.
The scope names one complete route
The user, the trigger, the decisions, the data, the exceptions, and what 'done' looks like. A screen list is not enough.
Progress is visible in working software
Reviews against the product at agreed checkpoints, while there is still time to act.
A scope change has a price before it has code
A new route, warehouse, or system connection shows its effect on cost and timing before anyone approves it.
Ownership exists throughout, not only at handover
Code, cloud, data, and provider access stay visible and under your control from day one.
The work is checkable without being technical
Checkpoints are working software you use yourself, reported in plain language.
Buy or own
| Buy an existing product | Build custom software | |
|---|---|---|
| Best fit | Handles your routes with reasonable setup, and its pricing makes sense | The way your routes work is itself the advantage |
| Manual work | Setup and process changes can remove the constraint | Repeated manual matching of cash and card has a measurable cost |
| Connections | Existing connections to your card readers and machines work with reasonable setup | A critical connection to your machines or warehouse cannot be done cleanly any other way |
| Route model | Your routes fit its planning model: standard machines, standard host terms | Unusual host terms, mixed connected and unconnected machines, or several warehouses break the template |
Which route is costing you the most right now?
Bring it to a 30-minute call. Leave with a build, buy, repair, or wait recommendation in writing. Free, whether or not we ever work together.
Work with us
Bring one route problem. Leave with a decision.
In a 30-minute call, we will help you decide whether to buy, connect, repair, build, or wait. If custom software is not the sensible next move, that is still a useful answer.
- One named route owner and one complete route for the first phase.
- Scope, what 'done' looks like, and exclusions agreed before paid work starts.
- Code, cloud, data, and provider access remain under your control.
- Post-launch warranty cover for defects in the agreed scope.
Common questions
It plans each operator's day around what machines need. It reads sales and stock data per machine, flags machines that will run dry, builds the route and the pick list for the truck, and matches cash counts against card payments. The office sees the same picture the route team sees, and every machine gets a profit figure.
No. Machines that report their own sales and stock data feed the system automatically. Machines without that connection are covered by counts entered on the phone at the machine: cash counted, products refilled, faults noted. The system works on the mix you actually have, and improves as more machines get connected.
Each machine keeps one money record. Cash counted on the visit goes in, card payments from the card reader export go in, and the system matches the two against recorded sales. Only the differences worth chasing get flagged, with the machine, the visit, and the amounts attached. The rest is filed without anyone retyping it.
By need, not by calendar. Each product in each machine has a minimum stock line and a sales speed from its own history. The system works out how many days each product has left, then groups the machines that need attention into routes that respect driving time, host access hours, and the operator's workload. Machines still full are left alone.
One route, end to end. Machine and location records, sales and stock data in, a daily route and pick list out, cash and card reconciliation out, and a profit figure per machine. Service visits, extra routes, and warehouse connections come after the first route is running and trusted.
Yes, because a route is never only refills. Faults, jams, cleaning, inspections, and meter readings ride on the same route plan, with their own tasks and time allowances. A machine that needs a repair visit does not wait for its next refill day, and a refill visit near a machine due for inspection can cover both in one trip.
Every route draws from the same machine, location, product, and money records. Pick lists are built per route from the warehouse that serves it, and a substitute operator can run any route from the phone app on day one. The office sees all routes, all machines, and all money in one place, instead of one spreadsheet per route.
Buy one when it handles your core workflow with reasonable setup: standard machines, standard card readers, and routes that fit its planning model. Build when your operation breaks the template: unusual host terms, mixed connected and unconnected machines, several warehouses, or a profit model the product cannot express. The first call gives you that answer in writing.
You do. Code, cloud accounts, data, and provider access stay visible and under your control from day one, with operating notes that let another capable team run the system. Ownership is agreed before paid work starts, not negotiated at handover.
The location record carries its own terms: access hours, service windows, product rules, and commission terms. Routes respect those terms when they are planned, so a location that only admits visitors before opening is never scheduled mid-morning. When terms change, the record changes once and every future route follows it.