What we'd have had to buy
A small operator's procurement exercise · Chaparral Wireless Networks · 2026-08-02
We built an operations agent for our own network instead of buying one. People keep asking what we'd have bought instead, so we went and priced the alternative — not as a sales argument, because we have nothing to sell, but because we could not find this map anywhere and we would have wanted it.
What follows is a shopping list, and it is honest in both directions. Several of these vendors do their one job better than we do ours. Say so out loud or the rest isn't worth reading.
The exercise
We took every function our agent performs day to day, and asked: if we started over tomorrow with a budget and no code, what would we sign?
We restricted the first pass to the AI vendors in our own buying co-op's supplier programme, because that is the shortlist a member would actually work from. Then we widened it, because the co-op list ran out fast.
The result
| What it does for us | Closest co-op vendor | Verdict |
|---|---|---|
| Monitoring, alarm triage, root cause | Aispire | ✅ Real overlap. Genuine AIOps, aimed explicitly at operators with small teams. They would do this well. |
| Answering the customer phone line | Ozmo | ⚠️ Partial. Ozmo is device/app support content plus agent assist and a self-serve assistant. It does not pick up the phone. A separate voice platform is required. |
| Field dispatch and routing | PeakView | ⚠️ Partial. Covers scheduling, work orders, matching tech and parts to job. Nothing for a tech-facing assistant or per-tower climb weather. |
| Point-of-sale recommendations | Actifai | ✅ Does this, well — but it isn't something our agent does. Listed for completeness. |
| Video middleware and discovery | Minerva | ❌ Different layer. Middleware and recommendation, not production. |
| Aerial survey → CAD | AirWorks | ❌ Unrelated to operations. |
| Remote PC management, staff and customer | — | ❌ Nothing in the co-op list. Buy a separate RMM. |
| Subscriber provisioning, RADIUS, DNS/IPAM | — | ❌ Nothing. That's your BSS/OSS stack. |
| Change control: pre-review → ticket → journal → verify | — | ❌ Nothing — and we could not find this anywhere in the wider market either. |
| Monitoring that tests itself | — | ❌ Nothing. |
| Local channel production | — | ❌ Not middleware. Origination is a different category, and it's human-produced. |
The count
Six-plus contracts. Six-plus integrations. Four functions with no vendor at all.
And the part that matters most: none of those products talk to each other. The reason a single agent is useful on a small network is not that it does ten things — it's that the same context reaches all ten. The alarm knows which customer, the customer record knows which device, the device knows what changed last Tuesday and who approved it. That continuity is not a product you can buy. The two platforms that come closest both require you to standardise on their equipment and their cloud first, which is precisely what an operator with fifteen years of accumulated mixed gear cannot do.
Where the vendors beat us, plainly
If this section is missing, the rest is marketing.
- Aispire has seen hundreds of networks. We have seen one. Their pattern library is better than
ours by construction, and no amount of cleverness closes that. An anomaly detector trained across a fleet will beat one trained on a single plant, every time.
- Ozmo has device and application support content for thousands of models. We have none. If your
call volume is "my router light is orange," they have solved a problem we have not touched.
- PeakView has been doing dispatch optimisation since 2007. Ours is a tech assistant, not an
optimiser. Real routing maths is not something we have written and probably shouldn't.
- Minerva has middleware you would genuinely need to run modern IPTV. We do not compete with that
and would likely be a customer.
- The co-op's own platform comes with procurement, legal, a support desk and an ROI model. We are
one engineer and an agent. If you need someone to call at 2am who isn't us, buy theirs.
And the honest summary of our own position: what we built is differentiated architecturally — one agent, spanning, operator-owned, governed, running on gear we didn't choose. It is behind commercially in every way that matters to a purchasing department: no pricing, no third-party security attestation, no data processing agreement, one reference site, and no capacity to support anyone but ourselves. Those are exactly the things a procurement process tests, and none of them are fixed by better positioning.
Why we're publishing a shopping list instead of a price list
Because we don't have a price list, and we would rather say that than imply otherwise.
We are an operator. We built this because we had someone who could, and because the alternative was six contracts and four gaps.
What we can do is publish what we learned, including the parts that make us look worse:
- How we govern it — what the agent may do, what it may not,
and which limits are enforced in code versus which are process we follow. Including a section on what we don't claim, and one on where the build still falls short of the document.
- This list.
Method, so you can check us
- Vendor capabilities are taken from each vendor's own public material and from their listing in the
co-op's supplier directory, as of 2026-08-01.
- "Closest" means closest functionally, not commercially. We have not requested quotes, run a bake-off,
or trialled any of these products. Nobody here has been tested against anything. This is a capability map, not a review, and a vendor who thinks we've mischaracterised them is probably right to say so — we'd correct it.
- We have no financial relationship with any vendor named, and none of them knew we were writing this.
- Where we say "nothing in the market," we mean we looked and could not find it. That is not the same
as it not existing, and we would genuinely like to be corrected.