Budget season is when next year's rollouts are conceived, and the conception conditions matter. Programs sketched as a line item in November, "POS refresh, 280 sites, H2", have a way of arriving in July still shaped like a line item, whereupon they collide with lead times, freeze dates and field capacity that were all knowable eight months earlier. The difference between a 2027 program that lands and one that limps into 2028 is mostly decided now, in how the year is laid out before it starts.
Every estate's year contains fixed geometry. The pre-Christmas change freeze closes the deployment window somewhere in October or November. Easter, end of financial year, back-to-school, and each vertical's own peaks carve out further no-go zones. Lease events, store openings and compliance deadlines add hard dates of their own. Plot these first, because they are not negotiable, and what remains is the real deployment year: usually seven to nine workable months, not twelve. Programs sized against twelve months are late at birth.
With the freeze as the terminus, a national program walks backwards through four phases:
Procurement threads through the whole line: hardware lead times remain long enough that devices for an autumn pilot need ordering in summer, and a program that waits for budget sign-off in April to start buying has already donated its buffer.
The quiet constraint in every planning cycle is field capacity. Skilled national deployment crews are a finite pool, and every retailer's backwards plan converges on the same winter-to-spring corridor. Providers are scheduling 2027 programs now; capacity reserved in December is a plan, capacity requested in June is a queue. The same logic applies internally, project management, store communications and training all book against the same calendar.
None of this is complicated. It is simply early, and early is the one advantage that costs nothing. A 2027 program with its audit booked, pilot scheduled, waves mapped against the freeze and field capacity reserved, all before February, has spent almost no money and eliminated most of the ways rollouts fail.
Want your 2027 program mapped before the queue forms? Speak to an expert.
Some of Australia's fastest-consolidating store networks are not quite stores. Veterinary groups, optical chains, dental and audiology brands all run the same hybrid: a retail business at the front of the room and a clinical practice at the back, sharing one network, one premises and one anxious practice manager. The hybrid format has quietly produced some of the most demanding multi-site IT in the country, because every site carries the obligations of both a shop and a clinic, and a deployment must respect the two simultaneously.
At the front: POS, payments, retail merchandising screens and stock systems, everything a retail chain runs, in miniature. At the back: practice management systems booking every appointment, clinical records with privacy obligations, and diagnostic equipment, imaging, testing and lab devices, that connects to the network and predates most of it. The two halves have different vendors, different change tolerances and different failure costs. A POS outage loses sales; a practice management outage cancels a day of consultations and re-books it into a calendar that was already full.
The deployment consequence is scheduling with two clocks. Retail logic says work overnight. Clinical logic says the diary is sacred: equipment moves and system cutovers must land in the gaps the appointment book allows, coordinated site by site with people whose day job is patients, not projects. Wave plans in this vertical are negotiated with practice managers, and the deployment partner either carries that coordination or the program office becomes a call centre.
Consistency at chain scale, care at clinic scale. Groups built by acquisition inherit a different system in every practice; the whole point of consolidation is standardising the estate without stopping it. That means staged kit, piloted playbooks and rigorous per-site verification, delivered by crews who understand that the strange beige box in the consult room is a diagnostic device, not e-waste.
Sensitivity about data and downtime. Clinical records put these estates closer to healthcare deployment discipline than to general retail: privacy handled properly during migrations, old devices sanitised on decommissioning, and downtime windows honoured to the minute because the 2pm consult is not movable.
A support model that knows the difference. Post-deployment, a failed retail screen and a failed clinical workstation deserve different priorities from the same provider, tiered support that reflects what each device does for the site's day.
We have deployed across both halves of this hybrid at national scale, for Greencross on the veterinary side and Luxottica in optical retail, and the lesson repeats: the vertical looks niche until you count its sites, and then it looks like what it is, hundreds of small critical facilities that deserve deployment treated as seriously as any hospital and any flagship store, at the same time.
Consolidating a clinic-retail network? Speak to an expert.
Fuel and convenience is retail with the difficulty settings raised. The estates are enormous, hundreds of small sites rather than dozens of large ones, strung along highways as much as through suburbs. The sites never close, so there is no quiet hour to work in. The store is a compressed technology stack, POS, payments, fuel integration, food service, CCTV, digital price signage, in a footprint with no back office, no IT-literate staff, and a store room the size of a wardrobe. And half the estate sits somewhere regional, where the nearest field engineer is a planning question rather than a dispatch one.
The convenience format hides its criticality well. Each site is modest, but each site is also totally dependent on its technology: when the POS or payments fail, a fuel site does not degrade, it stops, at 11pm, with cars on the forecourt. There is no second register to fall back on and no duty manager who can troubleshoot. Everything about deployment and support has to assume the site is technology-critical and expertise-free, which is the exact inversion of the office environments most IT models grew up in.
The forecourt adds its own layer: work near fuel infrastructure carries hazardous-zone rules, induction requirements and permit disciplines that generalist IT crews have never met. A field partner in this vertical either arrives knowing those constraints or becomes a story the site manager tells.
The rollout playbook adapts in three specific ways. First, waves get denser: with sites this small, a crew can complete several per day if staging has been done properly and the run plan respects geography, which turns route planning into a first-class scheduling input. Second, night work is relative: the site trades through the night anyway, so installs are choreographed around fuel deliveries and trade patterns rather than a closing time. Third, regional coverage is not the program's tail, it is half the program, and providers whose coverage thins past the metro boundary reveal it here faster than in any other vertical.
Our work with fuel and convenience networks, including Reddy Express, runs on exactly that pattern: dense waves, staged kit, crews inducted for forecourt conditions, and the same result at site three hundred as site three.
After go-live, the estate needs a support model shaped to its reality: 24/7 cover because the sites are 24/7, preventive maintenance because unmanned technology accumulates neglect, swap-based fixes with spares positioned along the network's actual geography, and remote diagnostics that resolve what they can before a vehicle moves. The retail support principles all apply, tuned for distance and density.
Fuel and convenience rewards the same things every distributed estate rewards, discipline, staging, coverage, evidence, just with less forgiveness. Which is another way of saying it is a good vertical for judging a field partner quickly.
Running technology across a fuel or convenience network? Speak to an expert.
Put a national rollout to tender and three different species of company will bid, often at three very different prices. The managed service provider you already know. The on-demand technician marketplace with impressive coverage maps. And the deployment specialist you may not have heard of, because the category is quieter than its work. All three can produce a plausible proposal. They are built for different jobs, and the mismatch costs are paid in the field, months later.
A good MSP knows systems deeply and knows your environment personally, which is exactly what ongoing operations need. What most MSPs lack is a field organisation: their strength concentrates where their engineers sit, and a 400-site national program needs consistent execution in places no MSP has ever visited. The common result is an MSP running the project layer while subcontracting the field layer at margin, sometimes to the very marketplaces below, leaving the client paying twice for one accountability. MSPs belong in the rollout as the design authority and the receiving support organisation; asking them to also be a national field force is asking a surgeon to run the ambulance network.
Technician marketplaces solve one problem brilliantly: a competent stranger at almost any postcode, tomorrow. For single visits, that is the product, and it works. For programs, the model's economics work against you: each job is priced and accepted individually, each technician arrives fresh with no playbook, no staging feeds the visits, and no one in the chain owns the outcome across sites. Consistency, the entire point of a standardised estate, becomes a per-visit lottery. Marketplaces are capacity, not capability. Programs need both.
A deployment specialist is constructed around the program shape: integration centres that stage and kit hardware, field crews rehearsed on piloted playbooks, wave scheduling, exception management, and governance that reports weekly in a form a steering committee can act on. The specialist's weakness is the mirror of the MSP's: they will not manage your servers or answer your users on Tuesday. They exist for the multi-site deployment itself, plus the field support that keeps the estate running afterwards.
Fewer than a dozen sites, or work concentrated where your MSP is strong: let the MSP run it. Genuine one-off visits with no consistency stakes: a marketplace is efficient. A program, dozens to hundreds of sites, hard deadlines, one required outcome everywhere: a specialist, with your MSP as design partner and the selection rigour any national commitment deserves. The in-house option rounds out the table for organisations with standing field teams, which is to say, few.
The failure pattern to avoid is choosing by familiarity or by price alone. The MSP is familiar; the marketplace is cheap; the program does not care about either. It cares about who has done this shape of work before, and can prove it.
Choosing between three proposals right now? Speak to an expert.
A deployment RFP has one purpose: to make vendors reveal how they actually work before you are contractually married to one. Most RFPs fail at this. They ask for capability statements, which every vendor passes, and methodologies, which every vendor copies from the same textbook, and they end up selecting the best bid writer in the market. The fix is to write the RFP so that only operators can answer it well.
Vendors price uncertainty, so an RFP built on vagueness buys either padded quotes or optimistic ones, and the optimistic ones are worse. The document should carry the truth you have: a site list with locations, formats and known oddities; access windows and trading constraints; the scope per site as best you know it; the timeline's hard edges (freeze dates, lease events, compliance deadlines); and what you do not know, stated as what you do not know. Declaring the uncertainty invites bidders to tell you how they would resolve it, an audit and pilot, if they are any good, and lets you compare how each handles risk rather than how each hides it.
Capability grids reveal little. These reveal plenty:
Score responses the way partner selection should always run: evidence of comparable delivery first, coverage proven against your actual map second, method and governance third, price fourth. Price matters, but as the tiebreaker among credible bids, not the filter that eliminates them; the pricing decomposition belongs in the RFP so quotes arrive comparable. And leave room for reference calls where you ask one question: would you run your next program with them?
A good RFP process also tests something no question can: how the vendor behaves under mild pressure. Late clarifications, scope wobbles, an awkward site added mid-process. The bidder who handles procurement gracefully generally handles delivery the same way. The one who needs managing before the contract is signed is showing you the future, free of charge.
Want an RFP response with artefacts instead of adjectives? Speak to an expert.
A field services SLA is a promise with a stopwatch, and most of the negotiation happens in the definitions rather than the numbers. Two contracts can both say "four hours" and deliver experiences a day apart, because everything depends on four hours of what, measured from when, at which sites, during which hours. Buyers who read SLAs as marketing get the marketing. Buyers who read them as engineering get service.
The oldest trick in the schedule: response time is when someone acknowledges or attends; restore time is when the site works again. A four-hour response SLA is compatible with a three-day outage, honoured throughout. Trading businesses should anchor on restore, because the store does not sell acknowledgements. Restore commitments force the provider to solve the whole chain, technician, skills, parts, since arriving without the right spare restores nothing. Which is why restore SLAs are rarer and more expensive: they are promises about logistics, and only providers with real spares strategies can keep them.
When does the clock run? Business-hours measurement converts a Friday 6pm failure into a Tuesday fix while meeting a "four-hour" SLA. Estates that trade evenings and weekends need cover shaped to trading hours, and the SLA should say so in writing rather than imply it in a sales deck.
Where does the SLA apply? Every national SLA carries a geography schedule, and the schedule is where regional sites quietly become second-class: metro four hours, regional next business day, remote "reasonable endeavours". Sometimes that tiering is honest physics; the question is whether it matches your estate's reality and revenue. Ask for the SLA per site on your actual site list, not per tier on theirs, and check which tier your twenty most valuable non-metro sites landed in.
An unmeasured SLA is a mood. The contract should specify the reporting: per-incident timestamps (logged, dispatched, arrived, restored), monthly performance against SLA by region and severity, and a review cadence where misses are explained rather than averaged away. Averages hide precisely what matters, one catastrophic week disappears inside a good quarter. Ask for exception-level reporting, and for the data itself, not just the provider's summary of it, the same discipline branch network support models depend on.
On penalties: service credits keep providers honest, but nobody ever traded their way out of a bad support relationship one credit at a time. Treat credits as instrumentation, and the real remedy as the exit clause. A provider confident in their coverage will accept measurement without flinching; reluctance to be measured is itself a measurement.
Ask what an SLA visit costs when it happens. Time-and-materials support turns every incident into an open invoice, with travel, and regional sites suffer most. Our break/fix model prices per incident, fixed, travel included, anywhere in Australia, which makes the SLA conversation refreshingly short: the promise is the price.
Want an SLA you can actually audit? Speak to an expert.
Hypercare is the deliberately intensive support period that follows a go-live: elevated staffing, faster response, senior engineers close to the front line, and daily attention on everything the new environment does. The name is honest. For two to six weeks after a deployment, the estate gets more care than normal, because that is precisely when it needs it and precisely when opinions about the whole program are formed.
Issue volumes always jump after go-live, and it is worth being unsentimental about why. Real usage exercises paths no test did. Users meet unfamiliar systems and generate tickets that are questions wearing incident clothing. Edge cases surface at whichever sites are most unusual. And genuine defects, the ones that survived every review, choose this fortnight to introduce themselves. None of this means the deployment failed; all of it is the deployment finishing. Hypercare exists because pretending the spike will not happen does not prevent it, it just ensures the spike lands on a support desk staffed for an ordinary Tuesday.
The stakes are larger than ticket counts. The first weeks decide whether site staff trust the new kit or start building workarounds, and workarounds calcify into the support debt failed rollouts are made of. Hypercare is confidence engineering as much as fault fixing.
A dedicated intake. Post-go-live issues bypass the general queue and reach people who know the deployment, with the project team and support desk sharing one view of what is happening.
Daily triage. A short, disciplined meeting: what came in, what patterns are forming, what gets fixed today, what goes on the defect list. Patterns matter more than instances; five sites with the same symptom is a program issue, not five tickets.
Floor presence where it counts. For site-heavy deployments, roaming engineers covering each go-live wave's first days convert frustration into resolution before it becomes reputation.
Honest reporting upward. Hypercare metrics belong in the same governance rhythm as the rollout itself: volumes, trends, top issues, fix rates, published on schedule.
Hypercare without defined exit criteria is just expensive support with a nicer name. The discipline is agreeing, before go-live, what stable looks like: ticket volumes at or below baseline for a set period, no open critical defects, known issues documented with workarounds, and the receiving support organisation formally accepting the environment with the knowledge transfer done. Then hypercare ends, on evidence, and the estate moves to business as usual. Programs that skip the definition drift: support quietly carries project problems for a year, and nobody can say when the deployment actually finished, a governance failure project management should never permit.
How long should hypercare run? Typically two to six weeks per go-live wave, scaled to deployment complexity. Time-boxed with exit criteria, extendable on evidence, never open-ended.
Who staffs it? A blend: project engineers who know what was built, support engineers who will inherit it. Hypercare is also the handover.
Is it included in deployment contracts? It should be explicit: duration, staffing, response levels and exit criteria. "Post-implementation support" without numbers is a gap wearing a phrase.
Want go-lives that stay lived? Speak to an expert.
Every rollout budget conversation eventually arrives at the same question: what does this cost per site? The honest answer is that per-site pricing is an output, not an input. Two programs installing identical hardware can carry per-site costs that differ by a factor of three, and both prices can be correct. What a buyer actually needs is not a number to anchor on but a map of what the number contains, because that map is what separates comparable quotes from theatre.
A credible per-site price rolls up six layers: the field labour for the install itself; travel and logistics to get crew and kit to the door; staging, imaging and kitting done before dispatch; the project management and governance overhead that keeps three hundred sites honest; scheduled revisit and rectification allowance, because some percentage of sites always needs a second touch; and the provider's risk margin, which expands or contracts with how much uncertainty the contract asks them to absorb. Quotes that look remarkably cheap have usually amputated one of the six, most often staging, governance or rectification, and the amputated layer reappears later as variations, at variation prices.
Time and materials looks cheaper at the quote stage because the buyer is holding all the risk without pricing it. Fixed-price-per-site models move estimation risk to the party best placed to control it, the provider running the crews, and convert a budget hope into a budget fact. The precondition is definition: fixed pricing rewards programs with proper audits, piloted playbooks and agreed scope, which, not coincidentally, are the programs that go well anyway.
Ask every bidder for the same decomposition: labour, logistics, staging, governance, rectification, risk, per site type, per region. Refusals are informative. Then weigh the spread against what failure costs: the gap between the cheapest and the best quote on a national program is usually smaller than the trading loss of one bad wave. Cheap rollouts are a luxury good; most businesses can only afford good ones.
Want a per-site price built on evidence? Speak to an expert.
Every unreliable business Wi-Fi network shares an origin story: somebody guessed. Access point counts guessed from floor area, placement guessed from ceiling convenience, capacity guessed from optimism. Radio does not respect guesses. It respects concrete, steel shelving, refrigeration, neighbouring networks and the strange physics of a full stockroom, none of which appear on a floor plan. The survey is where the guessing stops, and it costs a fraction of the rollout it protects.
Predictive surveys are desk work: floor plans, wall materials and coverage requirements go into modelling software, and a design comes out, AP counts, placements, channel plans. Predictive work is fast, cheap and scales across a large estate, and for standardised site formats it carries most of the load. Its weakness is its inputs: the model believes the floor plan, and floor plans lie.
Onsite surveys put an engineer in the building with a survey rig, the AP-on-a-stick, measuring how radio actually behaves in that space. Onsite work catches what no model sees: the mezzanine that became a faraday cage, the fridges installed since the drawings, the neighbouring tenant's network shouting across the party wall, the mounting points that turn out to be solid concrete. A post-install validation survey then proves the built network matches the design, which is the step most quietly skipped and most often missed.
Surveying three hundred sites individually is unaffordable; surveying none is how estates end up with Wi-Fi as the permanent excuse. The professional pattern samples intelligently:
The blend gets survey-grade confidence at a fraction of survey-everything cost, and it is how multi-site wireless programs hold quality across hundreds of buildings.
Sequence matters commercially. A survey done before procurement sizes the order correctly; one done after the complaints arrive explains money already misspent. Under-provisioned networks fail loudly, but over-provisioning wastes budget just as reliably, APs bought for coverage the walls provide free. The survey pays for itself in both directions, which is why it belongs in the project plan as a gate, not in the contingency column as a hope.
Wireless is infrastructure now, the network the store runs on, not a convenience layered over it. Infrastructure gets engineered. Measure first, mount second.
Estate-wide Wi-Fi that needs to just work? Speak to an expert.
Ask who provides national IT field services in New Zealand and the answers go vague quickly. The big local players are systems integrators and MSPs with field capability attached; the specialist field workforces mostly serve telco and infrastructure, not IT estates; and the on-demand marketplaces thin out sharply past the main centres. For a business running branches, stores or clinics across both islands, the honest market answer is that nobody obviously owns the category. That gap is felt most by two groups: NZ multi-site businesses, and Australian companies whose estates cross the Tasman.
New Zealand compresses a familiar problem into sharper geography. Auckland, Wellington and Christchurch account for a large share of sites and nearly all of the technician market. Beyond them, the estate thins into towns where the nearest capable IT field engineer may be hours away, and the South Island's West Coast or the far north turn a routine visit into a logistics plan. Cook Strait adds a hard freight and travel boundary through the middle of the country, and weather closes mountain passes with a regularity Australian schedulers never plan for.
The result mirrors regional Australia: metro SLAs that look national on paper, and a long tail of sites where response times quietly triple. Any provider claiming NZ coverage should be asked the same question we recommend in Australia: name the technician arrangement for our three worst sites, specifically.
A local MSP per island or region gets competence but fragments accountability; two or three providers, two or three standards, and the head office becomes the integrator.
On-demand technician marketplaces solve the easy postcodes and leave the hard ones, with no playbook, no staging and no accountability for outcomes, workable for one-off visits, unworkable for programs.
A trans-Tasman field partner runs NZ as part of one ANZ structure: one playbook, one project office, one reporting line, with NZ crews executing locally. For Australian businesses extending across the Tasman, this is usually the difference between NZ sites being first-class citizens of the program and being its permanent exception column.
The test of an NZ field services arrangement is boring and specific: both islands properly covered, with named response arrangements outside the main centres; local crews who clear customs, freight and site-access realities without head-office intervention; staging that handles GST, shipping and DOA replacement inside NZ rather than round-tripping to Sydney; and one accountable owner when something goes wrong in Gore at 4pm on a Friday.
We run New Zealand as a full part of our ANZ coverage, with the same playbooks, staging discipline and reporting as the Australian estate, detailed on our New Zealand page. One project, two countries, no exception column.
Sites on both sides of the Tasman? Speak to an expert.
The ordering kiosk has done to quick service what self-checkout did to grocery: moved the transaction to the customer and moved the queue off the counter. In Australian QSR the kiosk is no longer an experiment, it is the front door, often taking the majority of in-store orders where deployed. Which makes the deployment question commercial rather than technical: how do you put kiosks into hundreds of restaurants, fast, without interrupting a single lunch service?
The two get lumped together and deploy quite differently. Supermarket self-checkout is a weighing, scanning, loss-prevention machine with legal-for-trade obligations. The QSR kiosk is simpler in hardware, a screen, a payment terminal, a printer, and harsher in environment: grease-laden air, sticky fingers, peak-hour crowds, and a direct integration into the kitchen display and POS estate that must not wobble during service. No scales, so no NMI verification, but payments certification, mounting stability and accessibility rules all apply, and a kiosk that fails open, taking orders the kitchen never sees, is worse than one that fails closed.
QSR gives a deployment team almost nothing to work with: restaurants trade from early until late, franchisees guard every trading hour, and the kitchen cannot host contractors during service. Kiosk programs therefore live or die on the overnight window. The working pattern is familiar from POS conversions and it transfers directly:
Most Australian QSR is franchised, which multiplies stakeholders: every install needs the franchisee's consent, scheduling and sign-off, and the brand needs every restaurant to land identically regardless of who owns it. The deployment partner absorbs that coordination or the program office drowns in it. It is the same discipline that runs national QSR technology programs generally: wave scheduling built around franchisee agreement, exceptions surfaced early, and a reporting line the brand can read weekly.
Kiosk fleets also commit the estate to a support model on day one. Screens in public hands fail in public ways, and the spares, cleaning and payment terminal arrangements deserve contracting alongside the install, not after the first failure.
Rolling kiosks into the estate without losing a service? Speak to an expert.
Payment terminals are the one device fleet a retailer does not fully control. Refresh cycles arrive on the acquirer's schedule: compliance standards expire, certifications lapse, network sunsets strand older hardware, and suddenly a fleet of thousands of terminals needs replacing by a date somebody else chose. The refresh is mandatory, the deadline is external, and every terminal touched sits in the exact spot where the business takes its money. It is the highest-stakes routine swap in retail.
A terminal swap looks like five minutes of work and hides a chain of dependencies. New units must arrive configured for the right merchant and site, security provisioning and key management must be handled through approved processes, the terminal must pair correctly with the POS or stand alone with the right settings, and the first live transaction must be proven before the engineer leaves. Skip that last test and the failure surfaces at the worst moment available, in front of a paying customer, with a queue.
Then there is the return path. Old terminals are not e-waste, they are security-controlled assets the acquirer usually wants back, tracked, and accounted for. A national swap program without disciplined reverse logistics ends with a reconciliation exercise across hundreds of sites, chasing devices that are variously in drawers, in transit and in landfill. Serial-level tracking out and back is not administration, it is the contract.
National terminal programs succeed on the same shape as POS rollouts, compressed:
Acquirers and payment providers run these programs across other people's premises, banks refresh branch fleets, and retailers absorb the disruption either way. The field partner in the middle needs national reach into every postcode the fleet trades in, crews who treat payment devices with the paranoia they deserve, and reporting granular enough to satisfy a bank's reconciliation. That combination, coverage, discipline, evidence, is exactly what we build for POS and payment installations nationally, and it is the difference between a refresh that finishes and one that trails exceptions for a year.
Terminal fleet on a deadline? Speak to an expert.