Multi-site design, segmentation, carrier requirements you can put out to bid, and wireless that survives the service bay. We design it, then hand it back to your team.
Where we fit
Dealer groups rarely arrive at their footprint on purpose. A store is acquired, then another, and each one comes with whatever network its previous owner signed off on.
That means a different switch vendor at each site, a different address plan, and a different idea of what the guest wifi is for. On paper it is one brand. On the wire it is several unrelated designs sharing a logo.
That holds up until something has to be true at every location at once: a payment device standard, a service-bay tablet rollout, a carrier contract, or a security requirement that arrives from outside.
The question then stops being how each store works. It becomes which design the group standardises on, and what the next acquisition gets pointed at. That is a design question, and it is the one we take.
The engagement
A documented reference architecture for a multi-site dealer or shop network: addressing, routing, switching and as-built diagrams your team can standardise on. Reuse it at the next acquisition instead of inheriting a sixth design.
Customer guest wifi, payment and point-of-sale (POS) devices, service-bay tablets and back-office systems all share one physical plant. We write the virtual LAN (VLAN) and trust-boundary plan that keeps them apart. The reasoning is recorded, so the next engineer can see why the boundary sits where it does.
A written requirements set every carrier answers the same way, so the responses can be compared on equal terms. It also covers redundancy for the stores that cannot write a ticket or take an order when the line is down.
Metal, concrete, roll-up doors, outdoor inventory lots, and tablets that follow technicians from bay to bay. Modelled against the building first, then validated on site with the readings handed over. Not walked through and guessed at.
Design choices that reduce how much of the estate falls inside the cardholder-data environment in the first place, because the cheapest way through an assessment is to have less in scope. Advisory only: we are not a PCI assessor, and we will say plainly where that line sits.
Why independent matters
Vendor-neutral by design. We are not tied to one vendor’s stack, so the design starts from what the site actually needs. If the design in front of you is already sound, we’ll say so and go home.
Work is attributable to IZT TECH and never white-labelled. That matters here. The deliverable usually gets read by somebody else: a client, a board, an auditor. An anonymous document carries no more weight than the opinion of whoever is holding it.
Where we hand off
We design the network the stores run on and stay out of the software business. Integration with a dealer management system (DMS) or a shop-management platform, the Tekmetric-style tools, belongs to our sister division IZT APPS. Dealership phone systems belong to IZT CLOUD. IZT TECH advises and the sister divisions provide: separate divisions, separate contracts. We name the handoff in writing rather than fold it quietly into our own scope, and that is part of how we scope every engagement. If your group also runs production or fabrication sites, our manufacturing page covers the same segmentation problem on a plant floor.
IZT APPS open_in_newIZT CLOUD open_in_newHow we work arrow_forwardManufacturing consulting arrow_forward
Tell us the decision you’re trying to make. We’ll tell you whether it’s an engagement, a referral to one of our sister divisions, or something you don’t need us for.
We’re here for you, so you can focus on what matters.
