Process AI / telecommunications

Three systems, one screen, and a route that used to be drawn by hand

Every enquiry starts the same way: can you serve this address, and what should we charge? Answering it honestly meant assembling four things by hand, from systems that do not talk.

The problem

A salesperson could not answer a customer's first question without opening three systems and a map.

For a business-connectivity provider, every enquiry begins the same way: can you serve this address, and what should we charge? Answering it honestly meant assembling four separate things by hand.

What does this customer already buy, and at what price? That lives in the ERP — Microsoft Dynamics NAV — as ten years of invoice lines, with the service location typed into a free-text field.

Have we quoted at this address before? That lives in the CRM, Intrix. And often it simply could not be answered: fewer than two thirds of quotes carry a precise service address at all, so the question frequently had no findable answer even though the answer existed.

What infrastructure is actually in that street? That lives in iObčina, the municipal public GIS portal — a separate web application, looked up address by address.

And if the customer wants a private link between two of their own buildings, someone had to work out a physical path for the fibre. Cable does not run in straight lines. It follows ducts, poles and trenches owned by different companies — the transmission operator, the regional electricity distributors, the telecom itself. Planning a route means chaining those networks together, deciding where you hand over from one owner to the next, and producing something you can send to each owner to ask permission and price.

That was drawn by hand, across maps.

Assembled by hand, that took up to a month. A month between a customer asking what a connection would cost and receiving an offer — spent not on negotiating or engineering, but on looking things up in three systems and drawing a line across a map.

And a step that slow gets skipped. A quote made without checking what the customer already pays, or what is already in the ground, is a guess.

What Red Bumerang built

One screen. Type an address.

Back comes everything that used to be assembled by hand: existing customers near that address with their services and monthly prices, historic quotes at that location, a price-by-speed comparison, and the public utility infrastructure at those coordinates — drawn on a live map over aerial imagery, with a one-click branded PDF for the customer.

And a second mode that plans the route.

Give it two addresses and it proposes up to three physical fibre routes between them across the mapped networks of eight infrastructure owners — the national transmission operator ELES (1,454 km mapped), the regional distributors Elektro Ljubljana (1,066 km), Elektro Maribor (847 km), Elektro Celje (267 km), Elektro Gorenjska (98 km) and Elektro Primorska (95 km), the generator DEM (135 km), and the client's own fibre (587 km). It offers the shortest route, the one crossing the fewest owners, and the one with the fewest single points of failure. Each hand-over between two owners' networks is flagged, because in reality each one is a splice: a cost, a permission, and a place the link can break.

The route exports as a Google Earth file with one folder per infrastructure owner — so the client sends each owner exactly the stretch that crosses their network, and nothing else.

What that took

Ten years of billing history, made searchable by location for the first time. 138,019 invoice lines across 51,503 invoices, back to 2016. The service address was never a structured field — so 165,853 service endpoints were parsed out of free text that previously could not be searched geographically at all, and link speeds were recovered from 77,454 hand-typed lines.

Eight owners' infrastructure, made routable. 20,721 network features, including 5,644 lines totalling roughly 4,549 km, unified into a single graph the router can cross.

What changed

From up to a month, to minutes.

The data a salesperson needs now reaches them in minutes rather than being assembled over weeks — and the offer goes out to the customer in minutes too. The month did not become a week. It became the time it takes to type an address.

That is the whole return on the project, and it is worth being precise about where it came from: not from doing the same work faster, but from not doing it at all. Nobody looks anything up in three systems any more. Nobody draws a route by hand. The lookups happen because an address was typed.

Where the AI actually is

At runtime, there isn't any — and that is the right answer.

Finding a route across 4,549 km of other people's infrastructure is a shortest-path problem over a graph, not a judgement call. Deciding which customers are near an address is a spatial index. Both must be exact, fast and explainable, and a model would make all three worse.

The AI was the build engine, and without it this system does not exist.

Two of the three systems had no way in.

Getting data out of Dynamics NAV normally means engaging a NAV development partner. That is the supported path, and anyone who has priced it knows what it costs and how long it takes. No partner was engaged here; a read-only bridge was built instead, running on the client's own Windows server behind an API key and an IP allowlist.

iObčina has no public API at all. It is a browser application talking to undocumented endpoints, and the data that matters — the utility report for a set of coordinates — sits behind a login.

Both were opened the same way: watching the real traffic, working out the contracts, and rebuilding them as documented clients. Those contract documents are now the authority for both integrations — which is the difference between a script that happens to work and an integration somebody else can maintain.

The third system needed none. Intrix ships a documented export interface, so it was simply used as intended. Two of three, not three of three — and saying so matters, because the reverse engineering was a last resort, not a first move.

This is the whole thesis in one project. The hard part was never the algorithm. It was getting the data out of systems that were never meant to give it up.

The part the client did not ask for

The most valuable deliverables were reports about their own data.

Making ten years of records routable meant reading all of them, and reading all of them surfaced things nobody knew:

  • 233 Intrix accounts carrying another company's NAV customer number — which had been

quietly opening the wrong customer record.

  • 3,001 gaps in their own infrastructure map — 264 places where a cable simply stops with

nothing within splicing distance, the largest a 903-metre hole, and 2,737 places where two of the same owner's lines pass within 60 metres and never join.

Both were handed over as working files: a spreadsheet, and a Google Earth layer. Neither was in scope. Both may be worth as much as the application.

Method

What the numbers count. All volumes were measured by direct query of the production database on 6 September 2026 and are cumulative since first sync. 138,019 invoice lines cover 2016-01-01 to 2026-07-31 — all of it, not a sample. 4,549 km is the summed length of mapped line features across eight owners. 165,853 endpoints and 77,454 speeds are the counts successfully parsed; the remainder are deliberately left unparsed, because that same free-text field also holds fibre-pair counts, kilowatts and rack areas, and the parser refuses to guess.

Where the before-and-after comes from. "Up to a month" and "minutes" are Red Bumerang's and the client's own account of the sales process before and after — not a timed study. No formal measurement of the manual process was made before the build, which is stated plainly rather than dressed up as one.

What is not claimed. No usage figures are published: the search log cannot separate real sales activity from automated testing traffic, so no adoption or volume number is offered.

Scope. One client, one country, in production since July 2026 and under active change.

---

Bring us a process, or a market.

Every system here started as a conversation about work that was already happening — how it actually runs, where it costs the most, and what the order underneath it looks like. That is the first meeting.

Book a 30-minute meetingSee the case studies