Ask a CFO what the company spends on technology and you'll usually get a number within a few seconds. Something like $4 million a year, give or take. It's in the budget, it's been presented to the board, and it's roughly right.
Now ask a different set of questions. What exactly are we buying with that $4 million? Which of those dollars pay for services at locations we no longer operate? Which contracts renew in the next six months, and what would it take to exit them? Who supplies the network at our newest locations, and who inside the company owns that relationship?
The answers to the second set can take days or weeks. They involve several people, a few shared drives and at least one provider portal nobody has logged into for a while, and they still come back with gaps. Nobody did anything wrong. The questions were about what the company actually has, and the only thing anyone had to work from was a budget.
What the number doesn't tell you
A technology budget tells you what you expect to spend. It's organized by category, cost center and GL code, and it answers the questions finance needs answered: how much are we planning to spend, where does it land in the P&L, and are we tracking to plan? That's useful work, and I'm not arguing against it.
Your technology estate is something else. It's the actual collection of services, providers, contracts, assets, locations, commitments and dependencies the organization is responsible for: every circuit, license, device, managed service, phone line, cellular plan, cloud subscription and support agreement, plus the contracts behind them and the dates buried in those contracts.
That information doesn't live in one place. It's spread across the AP system, the contract folder, the asset register, provider portals, old email threads and the memory of people who have since left the company. Some of it lives nowhere.
The budget lets you say, "We spend approximately $4 million a year on technology." Knowing the estate means being able to answer:
- What exactly are we buying, and from whom?
- Which locations does each service support?
- Under what contracts, and until when?
- What would it take to exit them?
- What assets support it?
- What does each piece cost?
- Who owns the relationship?
- What evidence supports all of that?
- What's missing or uncertain?
- Why are we still buying it?
Those are very different levels of knowledge. The first is enough to plan a year. You need the second before you change anything.
Nobody decided to build it this way
I've never walked into a messy technology environment that got that way because of one bad decision. It happens because hundreds of reasonable decisions get made by different people, at different times, for different reasons, and nobody's job is to keep the whole picture current.
A new location opens on a tight schedule and needs connectivity now, so someone orders whatever the local provider can install fastest. A project brings in a new vendor and the old one never quite goes away. An acquisition closes with its own carriers, its own contracts and its own way of doing things, and the integration plan says "consolidate in year two." Year two has other priorities.
A location closes. The lease ends and the equipment gets pulled, but the circuit keeps billing because telecom disconnects weren't on anyone's closing checklist. A CIO leaves, and with them goes the only explanation for why there's a second provider on the backup line at headquarters.
Give that enough years and the same patterns show up almost everywhere:
- Invoices for services nobody can immediately identify
- Two or three providers delivering overlapping services
- Charges tied to locations that closed a year or more ago
- Contracts that take days to find, if they turn up at all
- Renewal and termination dates nobody is confident about
- Different standards from one region or brand to the next
- Asset records that don't match what accounting or IT shows
- Acquired locations still running on the seller's providers
- Services that have outlived several leadership teams, with nobody able to say why they're still there
None of this is incompetence. It's what years of normal business leave behind in a company with a lot of locations.
Multiply it by 200 locations
One location is manageable. A capable person could sit down and list everything that site depends on: the circuit, the firewall, the phones, the POS network, the Wi-Fi, the cameras, the support agreement.
Now take twelve categories of service and spread them across 200 locations. That's potentially 2,400 location-to-service relationships before you've opened a single contract or invoice. The categories are the ones you'd expect: circuits, managed network, voice, security, software, hardware, support, cellular, cloud, licenses and others. Each relationship has a provider, a price, a term and a history.
And the footprint doesn't sit still. Locations open, close, relocate and remodel. Regions end up with different vendors. Brands inside the same company grow up with different standards. Billing rarely matches how the business thinks about its locations: one invoice might cover forty sites, while one site might appear on five invoices from three providers. A master agreement gets amended, service orders get added under it with their own terms, and the auto-renewal clause is in the document nobody pulled.
At that scale, working harder doesn't close the gap. The problem is structural, and the record has to be built with that in mind.
Finance and IT see different parts of the same picture
This usually gets framed as finance and IT not talking to each other. I don't think that's accurate, and it doesn't help anyone.
The CFO sees invoices, budgets, commitments and financial exposure. The CIO sees architecture, operations, dependencies, security and technical requirements. Both views are legitimate, and neither one on its own shows everything.
Finance can see a $1,900 monthly charge from a carrier. Whether that's the backup circuit keeping the data center reachable or a line into a building the company vacated two years ago is an IT question. IT's network diagram may show every store on the new SD-WAN platform, while AP is still paying for the old MPLS circuits at a handful of them. Each side is accurate about what it can see.
A useful record connects the two. The invoice line ties to a service, the service to a location, the location to a contract, the contract to its dates and terms, the service to the equipment that delivers it, and all of it to a person who's accountable. With that in place, the CFO and the CIO are having one conversation. Without it, they're having two, plus a reconciliation meeting.
Perfect data is the wrong goal
Once a leadership team recognizes this problem, the first instinct is usually to clean up the data before doing anything else. I understand the instinct, but I think it's the wrong target. A perfect-data project doesn't finish, because the environment keeps changing while you count it, and the effort stalls long before the decision it was meant to support.
The better standard is a record that's clear about what it knows and what it doesn't:
- If something is verified, say so.
- If evidence supports it but doesn't prove it, say that instead.
- If something is assumed, name the assumption.
- If information is missing, call it missing.
- If two sources conflict, show the conflict rather than quietly picking one.
Unknown information is manageable. You can assign it, investigate it and weigh the risk of it. Unknown information presented as fact is dangerous, because nobody knows to question it.
Picture a spreadsheet with a renewal date in every row. It looks complete. Some of those dates came from signed contracts. Some came from a provider rep's email. Some were typed in by someone making a reasonable estimate against a deadline. In the cell they all look the same. If the estimated one happens to be the contract that auto-renews for another thirty-six months, nobody will know to check it, because the spreadsheet never said it was a guess.
I'd rather work from a record that shows its gaps than one that hides them, even if it looks less finished.
Where the gaps get expensive
Most of the time, gaps like these cost money quietly, one unidentified invoice at a time. They get expensive when the company tries to change something.
That might be an RFP, a provider consolidation, a cost reduction effort, a modernization program, a major contract renewal, an acquisition integration, a new wave of locations, an outsourcing decision or a move to a managed service provider. In every case, the starting information shapes the outcome.
If the RFP scope is missing thirty locations, the bids aren't comparable, and the cheapest one may simply be the one that priced the least. An MSP handed an incomplete inventory will price what it's shown, and everything else turns up later as change orders. Cost reduction tends to go after the spend people can identify, so the spend nobody can explain survives another budget cycle. An integration plan built on the acquired company's records inherits every gap in them.
A company can run a sound process with good people and a careful analysis, make a perfectly rational decision, and still get the wrong outcome because the picture it started from was incomplete. That's hard to catch, because the decision looks right, and on the information available it was.
Why the baseline comes first
NarrowGateX was built around the belief that before you benchmark providers, negotiate contracts, consolidate, modernize or change anything significant, you need a trustworthy understanding of what exists today.
We work in a sequence: Baseline → Benchmark → Decide → Execute → Govern. Each step depends on the one before it. A benchmark is only as good as your knowledge of what the provider actually delivers to you, and a decision is only as good as the comparison behind it.
The baseline is the step most often rushed, usually because it gets treated as an inventory exercise. Building a spreadsheet isn't the point. The point is to tie invoices, contracts, services, assets, locations and providers together into one record, and to be explicit about how much weight each part of it can bear: what's verified, what's supported by evidence, what's assumed, what's missing, where sources conflict, and what needs investigating before anyone relies on it.
Done properly, a baseline is worth having even if you never change a provider. You know what you're committed to and until when, and you know where the evidence is thin and which open questions would matter most if a decision came due next month.
The question before the question
When technology spend comes up at the executive level, the conversation usually starts with direction. Are we spending too much? Should we replace this provider? What should we modernize next? Should we consolidate, or hand more of this to an MSP?
Those are fair questions, and every one of them depends on a more basic one that rarely gets asked out loud: what do we actually have?
Most leadership teams can answer that approximately. The harder part is saying how much of that answer they can prove.