I led the pricing and customer value work for CostSentinel, and honestly, proving the financial value was much tougher than selling the concept of an early warning. A controller might get a highly accurate alert, but if a supplier order is already locked in or production has shifted, they cannot actually change the outcome. The timing of the intervention is everything.
We decided early on not to charge by data volume, as that would unfairly penalize companies simply for how they log their transactions. Two identical plants could have wildly different bills based entirely on their software setup. Instead, I pushed for pricing based on the monthly average of active daily jobs. It feels much fairer, avoids spiking the bill after one unusually busy day, and ties directly to the actual work being monitored. We landed on three monthly tiers: €690 for Monitor, €2,490 for Control, and €4,900 for Predict. While these numbers helped map out what the service needs to deliver, we still need to prove customers will accept them. There is also a disconnect we need to address: our evaluation used daily observations, but the Monitor tier only offers weekly scoring. We absolutely need to test that slower tier before making any performance promises about it.
Our financial model looks at the extra costs left over after a valid warning compared to standard month end reporting. We assumed that intervening saves 30% of that cost opportunity. That gives us a conditional benefit of about €191,000. After deducting roughly €43,000 for the Control subscription and the time spent reviewing alerts, the net benefit is around €148,000. The math is completely solid, but it hinges entirely on that 30% effectiveness rate holding true in the real world. Right now, we do not have hard customer data from this project to back that up, which remains a blind spot.
Response time is another big unknown in this equation. If it takes a busy controller two working days to review an alert, investigate, and act, our benefit to cost ratio drops from 4.4 down to 2.6. That calculation really highlights how the controller’s daily routine impacts our proposed value. A 2.6 ratio is still financially attractive, but it uses that same untested 30% assumption and would drop further if costs became unavoidable during that delay.
Interestingly, the basic phased rule model actually showed a higher conditional net value of around €211,000 under the same assumptions. However, it generated 23.7 alerts a week with only 14% precision. CostSentinel only sent 8.8 alerts but hit a much stronger 56% precision. Essentially, our paid model appeals to buyers who want less noise and more accuracy so they do not waste time chasing false positives. We just do not know yet how much a controller will pay for that convenience, especially since we have not priced out the setup and maintenance required for the simple rule. I definitely want to keep the rule based comparison in our next round of testing.
I also factored in the human cost of reviewing these alerts. Our prototype generated 442 CostSentinel alerts. Assuming half an hour per review at an internal rate of €60 an hour, that adds €13,260 in annual review costs straight on top of the base subscription fee. Tracking this down required matching the exact definition of an alert with the specific workflow assigned to a human reviewer, since a single active job can trigger multiple overlapping alerts. In the future, I would map those operational costs out much earlier before ever putting them into a final financial table.
Looking at our own internal costs, cheap API calls do not magically erase the heavy need for integration and ongoing customer support. We need to sell the Control tier to about 25 plants directly, or 34 through third party partners, just to reach a break even point. Partners take a cut of the revenue, but they can get us through the door faster than our own sales team. Those numbers are strictly steady state and completely exclude initial onboarding or the expense of building new connectors, so I will make sure to present them with those caveats clearly attached.
For the overall market size, we started with a base of 251,000 medium sized EU enterprises, but that number is filtered by our own assumptions. It does not actually tell us how many of those companies use the right job cost workflows or would even consider buying a product like ours. It is a good baseline for understanding the general scale of the venture, but I would not dare use it for a concrete sales forecast without gathering firmer evidence about exactly who we can serve and what it costs to reach them.
Ultimately, this entire process made me realize that refining our sales forecast is secondary at this stage. The real priority is testing whether customers can actually respond to our alerts in time to save real money. The financial model holds up well as a conditional example, but a live, real world pilot is the only way to validate our pricing structure and the assumed cost savings. Even if it makes the core subscription a tougher sell to management, we should absolutely keep comparing our product against the simpler rule based approach during those upcoming discussions.
