Multi-Site IT for Melbourne Businesses: Branches, Warehouses and Pop-Ups

Multi-Site IT for Melbourne Businesses: Branches, Warehouses and Pop-Ups

When a Melbourne SME opens a second site — a warehouse in Dandenong, a pop-up in the CBD, a branch in Geelong — IT complexity compounds fast. By the fifth site you are running thirty different NBN contracts and nobody knows where the spare switch lives. This is the practical playbook for keeping multi-site IT under control.

Identity first, network second

The single most important shift in multi-site IT thinking over the past five years is moving from a network-centric model to an identity-centric one. In the old model, a “site” was defined by its network — the same VLAN, the same domain controller, the same file share. Anyone connecting to that network was on the corporate LAN and had access to corporate resources.

In the new model, a “site” is largely a power and connectivity convenience. The corporate resources live in Microsoft 365, Azure, or other cloud services. Access is granted based on user identity, device compliance and conditional access policies — not based on which Wi-Fi the user happens to be on. This is the practical version of zero trust thinking, and it changes the multi-site IT problem from “extend the corporate network to each location” to “make sure each user has reliable internet and a compliant device, regardless of where they are”.

If you are still thinking in the old model, multi-site IT looks expensive and complicated — SD-WAN, MPLS, site-to-site VPNs, domain controllers at each branch. If you have already made the identity-first shift, it looks much simpler — good internet at each site, a sensible Wi-Fi standard, identity through Microsoft Entra ID with strong conditional access, and you are most of the way there.

For a 25-person professional services firm opening a second office in Hawthorn, the right answer in 2026 is almost never to extend the corporate network. The right answer is to put a business-grade NBN connection in, deploy a managed Wi-Fi system, and let identity do the rest of the work. We have done this transition for several Melbourne clients and it consistently reduces the per-site IT cost by 40 to 60 percent compared to the old model.

When SD-WAN is overkill

SD-WAN gets pitched aggressively to mid-market businesses by carriers and resellers because it is a high-margin product. For most Melbourne SMEs with one to three sites, it is overkill. Here is when it pays back and when it does not.

SD-WAN is overkill when:

• You have one to three sites and the WAN traffic is mostly to cloud services (Microsoft 365, Azure, Salesforce, etc.) rather than between sites.
• Site-to-site latency is not business-critical (you are not running real-time voice over a private WAN or replicating large databases between sites).
• Your existing internet links are reliable enough — business-grade NBN with a 4G failover usually is.
• You can solve specific site-to-site needs with point solutions (a managed site-to-site VPN for the one application that needs it, rather than SD-WAN for everything).

SD-WAN starts to pay back when:

• You have four or more sites with active site-to-site traffic.
• You are running voice or video that needs QoS guarantees you cannot get from the public internet.
• You have a real need for application-aware routing — sending Microsoft 365 traffic out the local internet break while sending finance system traffic back to head office, automatically.
• You have specific compliance or contractual requirements for traffic segregation that point-solution VPNs cannot meet.

The Box Hill construction firm we onboarded last year had three sites and was being quoted $4,200 a month for SD-WAN by their incumbent telco. The actual requirement was a reliable internet connection at each site, identity-driven access to cloud apps, and a managed VPN between head office and the warehouse for a legacy job costing system that did not have a cloud version. We delivered that for $1,150 a month all-in across the three sites and the legacy system was migrated to a cloud equivalent six months later, eliminating the VPN entirely.

The hardware standard kit

One of the unglamorous secrets of multi-site IT is that the per-site hardware should be boringly consistent. Same firewall model, same switch model, same access point model, same configuration template, every site. This makes troubleshooting fast, sparing strategy obvious, and refresh cycles predictable. We use a standard kit per site type, scaled to size.

The point is not the exact equipment choice. The point is consistency. Pick a vendor stack (we tend to favour Fortinet for SMB and Cisco Meraki for businesses where the simpler cloud-managed model is more important than the deeper feature set), document the standard configuration, and apply it everywhere. When the access point dies at the Geelong branch, a same-model spare ships overnight and a remote engineer can reconfigure it from the template.

The on-site support response time problem

This is the issue that bites every Melbourne SME the moment they open a second site, and it is almost never addressed in the original IT planning.

Same-business-day on-site support is easy to deliver in the Melbourne metro area. It is harder when the second site is in Ballarat, Bendigo, or further afield. Most national MSPs solve this by paying break-fix technicians on demand at country rates, which is fine for occasional incidents but expensive and inconsistent for ongoing operations.

The honest answer is that on-site response time is a zone-based pricing question. Our Tecoma headquarters and CBD office at 575 Bourke Street let us deliver same-business-day on-site support across the Melbourne metro footprint, and we are transparent about response times for outer-metro and regional locations. For a multi-site business, the right conversation is “what is your business tolerance for a Ballarat user being offline for 24 hours versus 4 hours, and what is that worth paying for?”. Often the answer is that day-to-day support is delivered remotely (which works for 90% of issues), and on-site is reserved for hardware replacement and physical incidents, with a defined hours-to-on-site SLA per site zone.

For an outer-metro warehouse where downtime costs $4,000 an hour, paying for 4-hour on-site response is good economics. For a regional branch with five staff doing administrative work where downtime costs $200 an hour, next-business-day on-site is the rational choice.

This is the conversation that should happen during multi-site planning, not after the first regional outage. Zone-based response SLAs need to be in the agreement, with the cost difference made explicit. Anyone who quotes you “same SLA at every site” is either charging you for outer-metro response everywhere, or going to disappoint you when the Geelong site goes down.

The three governance rules that stop site sprawl

Multi-site IT becomes a mess not because of any single bad decision, but because of dozens of small decisions made independently at each site over years. Three governance rules, applied from day one of multi-site operations, prevent this.

Rule 1: one ISP relationship, not thirty

The single biggest contributor to multi-site IT chaos is each site having its own ISP contract, billed separately, with separate account managers and separate support paths. By site five, you have five different ISPs, five different bill cycles, five different sets of router credentials, and an IT manager who is on the phone to a different call centre every week.

The rule: every site’s internet connection runs through one ISP relationship, ideally aggregated by a single business-grade provider that can deliver to all your locations. The cost is usually within 5-10 percent of buying separate connections, and the operational saving is enormous. When a site goes down, there is one number to call and one technical contact who knows your business.

This rule applies even when the underlying technology has to vary — NBN at one site, Enterprise Ethernet at another, 4G at a pop-up. The aggregator handles the underlying carrier; you handle one relationship.

Rule 2: every site has a documented sponsor

Each site needs a named business owner who is responsible for the IT environment there. Not the IT manager — the local business sponsor. They are the person who notices when something is broken, who escalates when remote support is not responding fast enough, who is the local point of contact for hardware replacement deliveries, and who signs off on local IT changes.

Without a sponsor, sites accumulate undocumented changes — the warehouse manager who hard-wired the printer to bypass print server policy, the branch manager who plugged a personal Wi-Fi extender into the corporate switch, the pop-up coordinator who set the firewall admin password to “password123” so the marketing agency could plug in their demo equipment. Each of these is a small problem. Cumulatively they are how site IT environments rot.

The sponsor does not need to be technical. They need to be accountable. We require this as a condition of taking on multi-site management contracts, because without it the support quality degrades over time no matter what we do.

Rule 3: hard quarterly site audits

Every site gets a documented audit every quarter. Equipment inventory, configuration check against the standard template, network performance baseline, security posture review, sponsor interview about what is working and what is not. This costs about two engineer-hours per site per quarter and is the single most effective control against drift.

The audit produces a list of variances from standard. Most are trivial and get fixed during the visit. Some surface real changes — a site has grown headcount and needs more capacity, the local landlord has changed the building’s electrical layout, a department has started a workflow that needs a different printer configuration. The audit is where these get picked up and handled deliberately, rather than being discovered during an outage.

This is part of how our managed IT services model works for multi-site clients — a structured operational rhythm rather than reactive break-fix.

Backup, disaster recovery and the multi-site twist

Multi-site businesses have an interesting backup and disaster recovery profile because the sites can serve as recovery locations for each other in many scenarios. A flood at the head office is bad, but if the warehouse has internet, power, and a few desks, head office staff can work from there for a fortnight.

The implication is that multi-site DR planning should explicitly identify each site’s potential role in a recovery scenario for each other site. Most of the time this just means making sure that staff from each site have credentials that work everywhere, that there is enough physical capacity to absorb displaced staff, and that critical applications are cloud-hosted and accessible from anywhere.

The legacy file server at head office becomes a single point of failure that breaks this model. So does the on-premises application that only works on the head office LAN. Modern backup and DR design for multi-site SMEs explicitly identifies these single points of failure and either eliminates them (move to cloud) or designs around them (replicate to a second site, document the recovery process). We have rebuilt backup and DR for multi-site Melbourne businesses where the original design pre-dated the second site by years and was still treating head office as the only thing that mattered.

The cloud-first multi-site stack

For a Melbourne SME starting fresh, or for one going through a multi-site refresh, the cloud-first stack is now the default. It looks like this:

• Identity: Microsoft Entra ID with phishing-resistant MFA and Conditional Access policies. No on-premises domain controllers anywhere.
• Devices: All endpoints enrolled in Microsoft Intune. Compliance policies enforced as a precondition for accessing corporate resources. Wipe capability for lost devices.
• Productivity: Microsoft 365 with SharePoint and OneDrive as the canonical document storage. No file servers.
• Line of business: Cloud-hosted wherever possible. SaaS for accounting, CRM, ERP. Where on-premises is unavoidable, hosted in Azure or AWS, accessed via published web app or Azure Virtual Desktop.
• Networking per site: Business NBN or Enterprise Ethernet, managed firewall, managed Wi-Fi, 4G failover. No site-to-site VPN unless required for a specific application.
• Voice: Microsoft Teams Phone or a comparable cloud PBX, with handset standards documented per site type.
• Print: Cloud print or per-site MFD with direct printing from Intune-managed endpoints.

This stack is genuinely site-agnostic. Adding a new site means provisioning internet, deploying the standard hardware kit, and confirming identity policies apply. The business systems do not change. The “cutover” for a new site is hours, not weeks.

This is also where cloud services design matters more than network design. The cloud stack is the thing the business runs on. The network is the dial tone.

Common multi-site mistakes we see

A few patterns come up repeatedly in multi-site engagements. Worth listing.

Buying the wrong internet at the new site. Going for the cheapest available NBN connection at a warehouse where 30 staff need to use cloud services is false economy. The right line at the right speed costs maybe $80 a month more and removes a category of frustration.

Not standardising on switch and access point models. Different equipment at each site means different troubleshooting, different sparing, different configurations. Pick one. Live with it for the refresh cycle.

Letting each site choose its own SaaS. The Geelong branch using a different scheduling tool than head office because “it works better for our team” is fine until a customer interaction crosses sites and the tools cannot talk to each other. SaaS standards are a head-office decision.

Forgetting the physical security of the comms cupboard. A switch in an unlocked corner of the warehouse is a security incident waiting to happen. Lock the rack, log access.

Not having a sponsor at each site. Already covered, but the most common failure mode.

Underestimating the support cost of regional sites. Same-business-day on-site in regional Victoria is genuinely more expensive than in Hawthorn. Build it into the budget honestly rather than hoping nothing breaks.

How TechAssist supports multi-site clients

We support multi-site Melbourne businesses across construction, manufacturing, logistics, professional services and healthcare. The model is per-user fixed monthly pricing with zone-based on-site SLA tiers, which means a client knows exactly what each user costs to support regardless of which site they sit at, and the on-site response commitment matches the business value of each location.

Our 24/7 NOC in Tecoma handles monitoring and remote response across all sites for all clients. Same-business-day on-site is available across the Melbourne metro area from our two offices — Tecoma and 575 Bourke Street CBD. For outer-metro and regional Victorian sites, the SLA is set during onboarding based on the business risk profile and is honest about response time and cost.

Founded in 2014, we have 13 Australian-employed engineers and run an Essential Eight aligned, ISO 27001 capable operations practice. The reason that matters for multi-site clients is that consistency across sites is a security and audit problem as well as an operational one. The same standards, the same monitoring, the same documentation, every site, every time.

If you are about to open a second site, or are managing three sites that have grown organically into a mess, we have done this enough times to know where the traps are. Have a look at our MSP Melbourne page for the broader service description.

Frequently Asked Questions

Do we need SD-WAN for our second site?

Almost certainly not. SD-WAN is a real product with real use cases but for most Melbourne SMEs with two to three sites running mostly cloud applications, a managed business NBN at each site with 4G failover is the better answer. SD-WAN gets pitched hard because it is high margin for the seller.

Should we have a domain controller at each branch?

No. If you are still thinking in those terms, the broader architecture probably needs a refresh. Identity should live in Microsoft Entra ID, devices should be Intune-managed, and the branch becomes a power-and-internet location rather than a network outpost.

How do we handle internet failover at a regional site?

4G or 5G failover through the firewall is the standard answer. The throughput is lower than the primary line but enough to keep cloud applications running while the NBN fault is being resolved. Telstra and Optus business mobile data plans are the usual carriers; choose the one with better coverage at the specific site.

What happens when a site needs urgent hardware replacement?

If the equipment is standardised across sites, we usually have a spare ready to courier the same day for Melbourne metro and next business day for regional. For sites where downtime is critical, we recommend keeping a cold spare on-site, configured and ready to swap. The cost is the price of a backup access point or switch, and it is cheap insurance.

Can we use the same Wi-Fi network name across all sites?

Yes, and we recommend it. Same SSID, same identity-based authentication (typically WPA3-Enterprise via Entra ID), automatic roaming for staff who move between sites. This is part of the identity-first design — the user does not need to know they are at a different site.

How do we budget for multi-site IT?

The two main components are per-user costs (which scale with headcount and are largely site-agnostic in a cloud-first stack) and per-site costs (which cover internet, hardware, on-site support response). A reasonable rule of thumb is to budget the equivalent of one month’s per-user fee per site per quarter for ongoing site-specific costs, plus the standard kit cost for new site setup.

What to do next

If you are about to open a second site, the right conversation is identity-first design, business NBN with failover, standardised hardware kit, and a documented site sponsor. Skip the SD-WAN pitch unless you are at four-plus sites with real site-to-site traffic.

If you are already running three or more sites and feel like the wheels are coming off, start with a site audit. Inventory what is at each location, who the sponsor is, what the ISP relationship looks like, and where the variances from a sensible standard have crept in. The list itself will tell you the priority order for cleanup.

If you want a hand designing or untangling multi-site IT for a Melbourne business, get in touch. We will give you a frank assessment and a realistic plan.

If you need an engineer physically standing in your server room or next to a user’s desk, the honest answer depends on which suburb you’re in. For most of Melbourne metro we’ll be on-site same business day, and for inner-CBD and inner-east clients we’re usually there within two hours of a P1 call.

This post lays out the actual numbers — suburb by suburb — rather than the usual “we cover all of Melbourne” line that every MSP website carries.

Why suburb-level honesty matters

Every Melbourne MSP claims metro coverage. Most of them operate from a single office, usually somewhere in the inner east or the CBD fringe. That’s fine if you’re in Richmond or South Yarra. It’s a problem if your warehouse is in Dandenong South, your shopfront is in Werribee, and your head office is in Hawthorn — because the same engineer can’t realistically reach all three in a day from a single base.

For on-site IT support Melbourne wide, response time is a function of three things: where your engineer starts the day, how Melbourne’s traffic behaves at the time you call, and how many other tickets are already in the queue ahead of you. The first one is the only variable an MSP actually controls, and it’s the one that gets glossed over in sales conversations.

TechAssist runs two offices on purpose. Our main workshop is in Tecoma in the Dandenong Ranges foothills, which puts us inside the east and outer-east catchment. Our second office is at 575 Bourke Street in the CBD, which covers the city, inner north, inner west and bayside. With 13 Australian-based engineers split across the two, we can actually answer the question “how fast can you get to my suburb?” with a real number instead of a marketing platitude.

The two-office model, briefly

We’ve written about the reasoning behind inner Melbourne versus outer-east MSP office location in a separate post — that one is about the strategic call. This one is about the operational consequence: where each office gets to first, and how the two catchments overlap.

Quick summary of the geography:

• Tecoma office — sits on the Burwood Highway / Belgrave train line corridor. Natural catchment runs from Box Hill out through Ringwood, Croydon, Lilydale, Mooroolbark, Mount Evelyn, Wonga Park, the Dandenongs themselves and the Yarra Valley. Also covers the south-east through Glen Waverley, Mulgrave and Dandenong with reasonable times.
• 575 Bourke Street office — sits in the legal/finance precinct of the CBD. Natural catchment runs through the CBD itself, Docklands, Southbank, South Melbourne, Port Melbourne, then inner north (Carlton, Brunswick, Northcote), inner west (Footscray, Yarraville, Williamstown), inner east (Richmond, Hawthorn, Camberwell) and bayside (St Kilda, Brighton, Sandringham).

The two catchments overlap heavily through the inner east — Camberwell, Hawthorn and Kew can be served quickly from either office depending on traffic and who’s free. That overlap is deliberate. It’s also where most of our managed services clients are concentrated, so it tends to be the busiest patch.

Response-time table by suburb cluster

The table below shows realistic same-business-day arrival times for a P1 (production-down) ticket logged before 3pm on a normal weekday. Times assume the closer office has an engineer available — which is the case roughly 90% of the time given the team size. P2 and P3 tickets follow the same routing but are scheduled rather than rushed.

A few things worth calling out:

• P1 response is sub-15 minutes — that’s the time to a human engineer on the phone or remote session, not the on-site arrival. The table above is specifically about feet-on-the-ground times once we’ve established remote work won’t fix it.
• About 70% of what gets logged as “needs on-site” turns out to be solvable remotely once an engineer actually looks at it. The on-site numbers above are for the genuine remainder.
• Traffic in Melbourne is what it is. Burnley Tunnel between 7:30am and 9am, Monash between 4pm and 6:30pm, Westgate basically any peak — these can push the headline numbers out by 30 to 45 minutes. We dispatch from whichever office has the better run at the time.

A concrete example: multi-site retailer

Last year a homewares retailer with six shops came to us after their previous MSP — a single-office shop based in Mount Waverley — kept missing on-site SLAs on the western stores. Their footprint:

• Head office and warehouse in Box Hill
• Flagship in the CBD (Bourke St Mall)
• Shopfronts in Doncaster, Chadstone, Highpoint (Maribyrnong) and Werribee Plaza

The previous arrangement had every on-site call dispatched from Mount Waverley. Box Hill, Doncaster and Chadstone were fine. The CBD store got served eventually. Highpoint and Werribee routinely waited four to six hours, because the same engineer had to clear the eastern tickets first and then drive across town in afternoon traffic.

We took it on under a split-routing model: Box Hill, Doncaster and Chadstone get served from Tecoma. The CBD, Highpoint and Werribee get served from 575 Bourke Street. The Werribee store, which used to be a six-hour wait, now sees an engineer inside two and a half hours. Highpoint is usually under 90 minutes. None of it required us to hire extra staff — just to dispatch from the office that was actually closer.

This is the kind of thing that doesn’t show up in a tender response, but it matters a lot once you’re three months into a contract and your Werribee store manager is calling head office for the fourth time that week.

Where we’re slower — and why we’ll tell you

There are parts of Melbourne metro where we are not the fastest option. We’d rather be upfront about it:

• Frankston / Mornington Peninsula — we cover this for existing clients who have a head office inside our normal catchment and a satellite site down south. We don’t take on standalone Frankston-only clients because we can’t promise sub-three-hour on-site, and there are good local MSPs who can.
• Outer north (Craigieburn, Mickleham, Wollert) — covered, but expect two to three hours on-site rather than 90 minutes. Same applies to Sunbury and Diggers Rest.
• Geelong and the Bellarine — not in scope. We have clients with Geelong branches that we service via remote-first plus pre-booked monthly site visits, but it’s not a P1-response area for us.
• Bendigo, Ballarat, Latrobe Valley — same as Geelong. Project work and managed services yes, urgent on-site response no.

That’s a list of about a dozen postcodes out of the hundreds we cover. The vast majority of Melbourne metro — and certainly the postcodes where most SMEs sit — falls inside the same-business-day window.

What “same business day on-site” actually requires

The reason most MSPs can’t honestly commit to same-business-day on-site across all of Melbourne metro comes down to maths, not effort. To consistently hit it you need:

1. Enough engineers — if you have three field techs covering 200 clients across 50 suburbs, you’re going to miss. We run 13 engineers (most of whom do both remote and on-site work) split between the two offices, which keeps the load per engineer reasonable.
2. Geographic spread of those engineers — one engineer who lives in Berwick, another in Footscray, another in Eltham, and so on. We deliberately hire across the metro rather than concentrating in one area, because home-base proximity matters for early-morning P1s.
3. A dispatch process that actually looks at the map — not “next available” but “next available who’s closest to the site”. This sounds obvious but plenty of helpdesks still dispatch on availability alone.
4. Two physical bases — so that morning starts and stockpiled spares don’t all originate from the same postcode.

We’ve had the two-office model in place since the Bourke Street office opened. Before that we were Tecoma-only, founded in 2014, and we genuinely couldn’t make the same response promises for the western suburbs that we make now.

How the dispatch decision actually gets made

When a P1 ticket comes in, the dispatcher looks at three things in order:

1. Postcode of the site (which office is geographically closer)
2. Current location of available engineers (one of them may already be near the site for another job)
3. Time of day (a 4pm Westgate Bridge run from the CBD to Werribee is worse than a 4pm Tecoma-to-Glen Waverley run, even though the latter is technically further)

It’s not complicated, but it does require the dispatcher to know Melbourne. Our service desk team is all based in Australia — that’s not an idle boast, it’s a functional requirement, because someone in Manila isn’t going to know that the Burnley Tunnel just shut and the Eastern is the better call.

Where this fits with remote support

This post is about on-site response specifically. The broader question of when on-site is the right answer at all is covered in our piece on remote IT helpdesk versus on-site support — short version: most issues should and do get fixed remotely, and the value of on-site is that it’s there for the issues that genuinely need hands-on work.

What’s worth saying here is that fast on-site coverage doesn’t make remote support less important. The two work together. A good MSP triages remotely, fixes what it can remotely, and dispatches an engineer only when a remote fix isn’t viable. The on-site response time matters precisely because by the time we’re driving to your office, we’ve already established the issue can’t be resolved any other way.

What we cover in each direction

If you want a more detailed look at how we handle the eastern suburbs in particular — which is where the bulk of our outer-metro client base sits — we’ve written that up separately under IT support eastern suburbs. The general overview of our delivery model is under on-site technical support and the broader managed services context is under managed IT services Melbourne.

For the office locations themselves: Melbourne (575 Bourke Street) office, Tecoma office, and the full list of locations with maps and hours.

FAQ

Do you cover regional Victoria?

For existing managed services clients with regional branches — Bendigo, Ballarat, Geelong, Albury, Shepparton — yes, on a planned-visit basis combined with remote-first daily support. For standalone regional businesses where the head office and the only site is regional, we generally won’t be the best fit, because we can’t promise same-day on-site at the prices that work in those markets. Happy to refer you to MSPs we trust in those areas.

What about the Mornington Peninsula?

Covered on a planned basis for clients whose primary site is within our normal metro catchment. Mount Eliza and Mornington itself we can usually reach in around 90 minutes from 575 Bourke Street; Rosebud and the southern peninsula will be closer to two hours. We don’t actively target Peninsula-only businesses because the response times don’t compare favourably with local MSPs based in Frankston or Mornington.

Do you offer after-hours on-site?

Yes, for clients on a managed services agreement that includes after-hours coverage. The on-site response window outside business hours is longer — typically two to four hours rather than the daytime targets above — because we’re calling out an on-call engineer rather than dispatching from a staffed office. P1 phone and remote support is 24/7 for all managed services clients.

What’s the difference in response time between a P1 and a P2?

P1 means production is down — a server has fallen over, the internet is out, no one can log in, an attack is in progress. P1 phone response is under 15 minutes, on-site is per the table above. P2 means a meaningful problem but the business is still running — one user can’t print, a non-critical system is slow, a backup didn’t run. P2 on-site is same business day but scheduled around other work rather than rushed.

Can I get a faster response by paying for a premium SLA?

The targets above are what we deliver under standard managed services agreements. For clients with unusually high uptime requirements — typically those with revenue tied directly to a single point of failure — we’ll sometimes agree custom SLAs that include on-site standby arrangements. Those are uncommon and we’ll only quote them honestly when we can actually deliver, which usually means the client’s site is close to one of our two offices.

A reasonable next step

If you want to know specifically what we can promise for your suburb — or your collection of suburbs across head office and branches — the easiest thing is to send through the postcodes. We’ll come back with the realistic on-site numbers from each of our two offices and tell you straight if we’re not the right fit. Reach us via the contact page or call 1300 028 324. We’re also listed under our main IT support Melbourne page for general enquiries.

The fundamental question — “how fast can you actually be here?” — deserves a specific answer, not a vague metro-coverage claim. The table above is ours.