From Fragmented Signals to
Commercial Intelligence
Pricing and customer targeting decisions made on fragmented inputs — market data, competitor activity, and local market insights that existed only in people’s heads, never captured or combined.
The organisation could observe the market in pieces but had no system to combine those pieces into a single, decision-ready picture. Decisions depended on who had the best local insight that week.
A predictive commercial intelligence model, delivered through a PowerBI dashboard for two key stakeholders, with a PowerApps interface that captured a local market insight value as a direct input to the prediction formula.
Built for the Europe market, validated through a pilot in Budapest, Hungary — designed with multi-region scale-up in mind. This case documents the build and the pilot.
A major global energy company — within the Trading and Supply division, on the commercial side of the business. Pricing and customer targeting decisions were being made across a competitive market, influenced by campaign activity, competitor behaviour, and the kind of local market insight that experienced sales teams carry but rarely have any way to record.
Two key stakeholders needed a better basis for these decisions. The model was built for the European market, with a pilot run in Budapest, Hungary, and was designed from the outset with scale-up into other regions in mind.
The problem was not that the organisation lacked market insight. It was that the insight lived in fragments — in spreadsheets, in regional habits, in the heads of people who had been doing the job for years — with no system to bring those fragments together into something a decision could be made from with confidence.
Where This Started —
Three Kinds of Signal, No Way to Combine Them
Two questions sat at the centre of commercial decision-making in this environment: what is the right price for a given market, and which customers or segments deserve priority attention. Both questions depended on combining several different kinds of information — and that combination was not happening systematically anywhere.
The first kind of signal was structured but disconnected: internal market campaign data and historical sales performance, sitting in systems that were not designed to talk to each other or to feed into a forward-looking decision.
The second kind of signal was external and harder to capture systematically: competitor campaign activity at a city or area level. This existed — competitors’ moves were visible to people on the ground — but there was no structured mechanism for capturing it consistently and feeding it into a decision process.
The third kind of signal was the hardest of all: local market insight. The specific, ground-level read that an experienced regional team carries on their own patch — how the local market is currently behaving, what the competitive temperature in a specific area actually feels like right now. This read was real and valuable. It was also entirely informal — it lived in instinct and conversation, never captured anywhere, and therefore never available to anyone who was not already in that regional team’s network.
The consequence was visible and consistent: different regions developed their own interpretation of market conditions, pricing decisions were made reactively or from individual experience rather than from a shared picture, and the quality of a commercial decision depended heavily on which specific person happened to be involved in making it.
This was on the business side of Trading and Supply, where I was working as Technical Product Manager. The model and supporting tools were built in close collaboration with data scientists, for two key business stakeholders who needed a better basis for pricing and targeting decisions across the European market.
The Real Constraints —
What Made This Hard to Build
The difficulty in this case was specific to the nature of the signals involved — particularly the signal that did not exist in any system at all.
Local market insight — the regional team’s read on current conditions in their own patch — was arguably the most valuable input to a pricing or targeting decision. It was also the input with no existing format, no existing field, no existing system of record. Before this signal could be used in a model, it had to be reduced to something a formula could actually take as an input — which meant deciding what that input would be, and what should happen when nobody provided it.
Competitor campaign activity was known — but it was known informally, by people in specific regions who happened to notice it. There was no consistent mechanism for capturing this at the level of detail that would make it useful for a model: city or area level, tied to a specific time window, comparable across regions.
Historical sales data and campaign data were structured and could be processed conventionally. The local insight value was a single number, entered manually, carrying none of the statistical confidence behind it that the structured data had. Designing a model that could meaningfully combine a large, clean, structured dataset with one subjective, manually entered figure per market — without one type of input dominating or distorting the other — was a genuine design problem, not just a data engineering one.
The model needed to serve two key stakeholders whose markets did not behave identically. A model tuned too closely to one market’s patterns risked producing recommendations that did not hold in another. The European scope, with Budapest as the pilot market, meant the model had to be designed for variation from the outset — not retrofitted for it later.
A model output is easier to trust when its inputs are visibly objective. This model’s output depended partly on a single manually entered figure — a person’s assessment of current local conditions, reduced to one number. Stakeholders needed to trust both the structured data and the judgment behind that number, and trust that the model combined them sensibly rather than letting one undermine the other.
The Architecture Decisions —
What Was Built and Why
Each decision in this system was a response to one of the constraints above — particularly the challenge of making informal, human insight usable without losing what made it valuable in the first place.
Rather than treating local market insight as something too informal to use, the decision was to capture it as a single value — a number representing the current state of the local market, entered through an interface built in PowerApps by the people who actually had that read. The value depended entirely on current local conditions, which meant it had to be re-entered as those conditions changed, not captured once and reused indefinitely.
The harder design question was what the model should do when nobody provided that value. The answer was a constant: if no local insight value was entered, the formula used a fixed default rather than failing, returning a blank, or silently treating the missing input as zero. The model always produced a result — and the quality of that result improved when a real local read was available to replace the default.
The model’s multi-signal input layer combined internal market campaign data, competitor campaign signals at a city or area level, historical performance data, and the local insight value captured through the PowerApps interface. The structured inputs were large, clean datasets. The local insight was one number per market, carrying real but informal judgment.
Designing the model to weigh these inputs sensibly — so that a confident historical pattern was not overwhelmed by a single subjective figure, and so that a strong local read was not diluted into irrelevance simply because it could not be independently verified — was the central modelling challenge.
The model’s recommendations — pricing ranges, customer and segment prioritisation — were delivered through a PowerBI dashboard built specifically for the two key stakeholders who would act on it. The design intent was for the dashboard to support a decision conversation, not to function as a static report reviewed after the fact.
This meant the dashboard needed to show not just the recommendation but enough of the reasoning behind it — which signals were driving a given price suggestion, and what role the local insight value had played in shifting it from what the structured data alone would have suggested — for a stakeholder to evaluate the recommendation rather than simply accept or reject it blindly.
Rather than building for the full European scope and rolling out everywhere simultaneously, the decision was to pilot in a single market — Budapest, Hungary — before any claims were made about the model’s broader applicability. The pilot was the place to find out whether the multi-signal approach, and specifically the local insight value and its fallback default, actually behaved the way it was designed to in a real market with real stakeholders using it.
What Changed
The shifts visible during the build and the Budapest pilot were concentrated in how decisions were prepared and discussed — not in claims about results beyond what the pilot scope covered.
For the first time, local market insight had a defined place in the decision process rather than living only in conversations between people who happened to be in the same room. The two stakeholders could see a single recommendation that had already accounted for signals that previously had no shared home.
Pricing and targeting conversations in the pilot market started from a shared reference point — the dashboard’s recommendation and the reasoning behind it — rather than starting from scratch with whichever combination of people and informal insight happened to be available that week.
The PowerApps interface meant that a regional contact’s read on current local conditions could be entered as a number that fed directly into the prediction — and when nobody provided it, the model fell back to a fixed default rather than breaking or ignoring that part of the formula entirely. The model always ran. It simply ran better when a real local read was available.
What This Revealed
Most discussions of predictive intelligence focus on the modelling technique — the algorithm, the accuracy, the sophistication of the prediction. This experience revealed a different bottleneck. The structured data — historical sales, campaign performance — was the easy part. It already existed in a usable form. The genuinely hard work was deciding how to represent something informal and human — a person’s current read on their own market — as a single number a formula could use, and what the formula should do on the days nobody provided one.
This also revealed something about the nature of trust in a hybrid human-and-model system. Stakeholders did not need the model to be fully automated to trust it. They needed to see that their own teams’ read on the market had genuine influence on the recommendation — and to understand what happened to that recommendation on the days when no one had entered a current local insight.
What This Taught Me
Local market insight was harder to capture than any structured dataset in this system — and it was also the input that most clearly differentiated the model’s recommendation from a generic statistical forecast. Reducing it to a single number, rather than a detailed structured assessment, was the decision that made it usable: a busy regional contact can provide one number consistently. They would not have reliably provided a detailed structured form. The instinct to capture more detail is often wrong. The instinct to design for a sensible default when the number is missing is what made the simplicity safe to rely on.
Designing the dashboard to show the reasoning behind a recommendation — rather than presenting a number stakeholders either accepted or rejected without context — meant the model became something stakeholders could reason alongside, using their own experience. The goal was never to make the human judgment unnecessary. It was to give that judgment a better-structured starting point.
The Budapest pilot was designed to answer a specific question: does this combination of structured data and a single human-entered local insight value actually produce a usable recommendation in one real market. It answered that question. It did not, on its own, prove that the model would behave identically across every other European market it was designed to eventually serve — and the honest account of this work reflects that distinction rather than extending the pilot’s results further than the pilot itself reached.
Where this case sits in
the Signal → Perception loop.
This case sits primarily at the Insight stage — with the foundational work of integrating fragmented inputs belonging to the Signal stage beneath it.
At the Signal stage: three distinct signal types existed before this system was built — structured historical data, informally known competitor activity, and entirely uncaptured local market insight. None of them individually constituted usable signal for a commercial decision. The work of designing a way to capture the previously uncaptured signal — reducing it to one number, with a constant fallback when it was absent — was Signal-stage work: creating the conditions under which a previously invisible input could exist as data at all.
At the Insight stage: the real work of this case was combining multiple signal types — of different reliability, different format, different origin — into something that produced a usable interpretation. This is Insight in its clearest form: not more data, but a better-structured way of reading the data that already exists, alongside the data that has never existed anywhere before. The dashboard was the interface where that insight became visible and actionable for the stakeholders who needed it.
The organisation described in this case is a major global energy company. Specific identifying details have been kept general deliberately — this is standard practice when documenting real operational work.
This case documents the build phase and the Budapest pilot specifically. My involvement with this programme concluded at the pilot stage, and this account does not extend claims beyond what that scope covered. Systems in Practice exists to document real systems honestly — including the honest boundary of what was directly observed.
The insight your
best people carry —
but your systems don’t.
If your organisation is navigating a version of this — commercial decisions that depend on who happens to be in the room, valuable local or market insight that lives only in individual heads, or a predictive model that needs to combine clean data with judgment that has never been captured before — this is the problem space I work in.