Your team prices and routes traffic from numbers that are already old. By the time an analyst has modeled one corridor in a spreadsheet, the demand they modeled has moved, and the carrier agreements underneath it have moved on their own schedule. Nothing is broken. The answers are still defensible. Margin is lost in the corridors nobody had time to re-price.
That is the threshold, and telecom optimization crosses it long before the models get good enough. It becomes an AI problem when the decision space outgrows the review cycle: when routing, pricing, and capacity decisions change faster than analysts and static rules can follow, and the gap between the decision the team would make with current information and the one they make with last week's shows up in monthly results.
Omar designed and built the ML routing platform for a top 10 global telecom company that was losing margin on international roaming: time-series models running on roughly 1TB of new traffic data a day, optimizing cost and routing across the operator's carrier agreements. The manual process it replaced was not incompetent; it was outrun.
Three Signals The Threshold Is Crossed
The decision surface is too large to search. Routing options, quality thresholds, pricing tiers, demand shifts, and capacity constraints interact in ways that look manageable one corridor at a time and become intractable across a portfolio. The process falls back to heuristics and periodic review, which is not optimization; it is triage with a spreadsheet.
The environment moves faster than the loop. A decision model built on weekly analysis loses its edge the moment demand, congestion, or pricing shifts inside the week. Once the environment is dynamic and multidimensional enough, the return comes from systems that update recommendations against live conditions, not from better static rulebooks.
The waste is visible at leadership level. Routing cost, capacity utilization, or planning inefficiency has to be material enough in order to justify changing the operating model around it, and the case for it is strongest when the same optimization pattern repeats across markets, so that one build serves many decisions rather than a single one.
What The Manual Process Was Missing
The signals that mattered on the roaming build were visible in the operator's data before the platform shipped. Margin per session was drifting down on corridors that had been profitable a quarter earlier, and the drift was masked in the aggregate because the high-volume corridors averaged it out. Quality complaints were rising on the paths where the cheapest carrier had been chosen and then degraded, because nobody had time to re-price the alternative. Agreement renewals were signed against pricing baselines built from stale traffic, optimized for the network the operator had six months earlier.
The cleared outcomes of that build are worth stating plainly, because they show where the value sat. The platform surfaced optimization opportunities across 128% more corridors than the original scope targeted, inefficiencies the manual analysis had never physically reached. Measured against the cost of the engagement, the optimization returned over 12x in the first year. The full account is the global roaming optimization build.
"Omar is one of the most skilled engineers I have worked with in 20 years of delivering technology. He led a program to build a custom ML platform for a top-10 global client. The work continuously exceeded expectations and became their foundation." — VP of Customer Success, Gigster
How To Pick The First Loop
The first way to get this wrong is to try to optimize everything at once, which creates enough scope to guarantee that no single decision loop is ever proven. The stronger path is narrower: pick the corridor or cost center where the current process is already visibly weak, work against live decision variables, and let one loop earn the right to expand.
The second way to get it wrong is to treat the optimization layer as a model-selection exercise. The model is one component. The harder problem is closing the loop end to end: ingesting fresh operational data, generating recommendations on a cadence that matters, presenting them to network operators in a form they will act on, and capturing the outcome of each decision so the system learns from production behavior rather than a backtest. Skip the closed loop and the result is a research project with a dashboard.
A good first loop has three properties; a loop missing any one is the wrong place to start.
- The decision recurs on a short cycle. A decision made once a quarter cannot be optimized on a continuous loop, no matter how expensive each instance is.
- The gap between a good and a bad decision is material. Where the options differ by little, the gains disappear under the overhead of running the loop.
- The current process is observably behind. If the manual process is already strong, the accuracy bar for replacing it is high enough to make the project a bad trade.
When A Rules Engine Is Enough
If the decision rules are stable and the manual process keeps up, a rules engine is the better answer, and an AI optimizer is an expensive way to buy the same outcome with more operational surface. The honest test is whether the operating environment moves inside the review cycle. If it does not, nothing about the decision requires a model.
The other blocker is upstream. If the operational data needed for routing or pricing cannot be reached in time to act on it, trapped in systems that export nightly or reconciled by hand across carrier partners, then fixing the data path is the first project.
Build One Loop, Then Widen
The pattern that works is one narrow optimization loop, built against live operational data, with explicit cost and quality trade-offs and one production decision surface, proven before coverage expands. It is a systems-integration problem before it is a modeling problem: the loop has to reach the carrier systems, the pricing data, and the operations team's own tooling, and every one of those boundaries is where the project actually lives.
That is the shape of the engineering partnership: prioritize one decision workflow at a time, agree on each release, and keep improving the system with continuous feedback from the people who are using it. Where the corridor has been chosen and the data path is the open question, how to know your data is build ready is the test to run first.
