Home / Resources / Blog / Details

In this article:

A Guide to How to Find the Beast The Mystery Behind No ROI on Innovation Bigfoot8217s Secrets Revealed The SoulSearching Questions You Should Be Asking Bigfoot Edition The Action Plan How to Make Innovation Better and Boost Your ROI BigfootStyle

Ready to take your Dynamics 365 further?

See how Bluefort helps Business Central and Finance teams build, bill and get paid with less effort. Talk to us today.

Let's Chat

Schedule a free, no-obligation discover call today!

Why Is My ROI on Innovation as Elusive as Bigfoot?

07.07.2023

Thinking

A Guide to How to Find the Beast

Ever felt like your return-on-investment (ROI) on innovation is playing a never-ending game of hide-and-seek?

Maybe it’s even harder to find- like Bigfoot. Feels like a legend that only a lucky few have seen.

And you’re strongly suspicious they’re all fibbing. They have to be!

Maybe every time you hear “boosting your ROI” you want to scream into a pillow in frustration. We don’t blame you. It’s soul-destroying pouring money into something that SHOULD be working, but isn’t.

So we thought it might be helpful to go through why you’re missing ROI on innovation, and some tips to finally find and tame that beast!

The Mystery Behind No ROI on Innovation: Bigfoot’s Secrets Revealed

So why are your innovative efforts not yielding big old heaps of cash?

There are lots of possibilities. Here are a few of the most common:

Misaligned goals

Does it feel like your innovation lacks focus? Have your priorities somehow been along the way?

And whose goal is it anyway – the business’s or the customers’? Does one compete against the other?

You don’t set out to find Bigfoot without knowing which forest he’s hiding in. That destination has to be lined up before you can figure out how to get there.

Lack of collaboration

Be honest – come on, now – how many silos does your company have?

Even the people in your office who can’t stand the sight of each other need to be able to share information. Innovation only succeeds where ideas are freely exchanged.

Teams have to work together. Imagine going after Bigfoot with a documentary team and no one has spoken to each other till you all meet for the search. Chaos ensues.

Inadequate measurement

Are you tracking the wrong metrics or using outdated methods to evaluate your efforts?

Look, when your innovation ain’t doing great, you probably would rather put your thumbs in a torture vice than look at the actual numbers. It’s hard. It’s wincy. It feels like “failure” right in your face (we don’t think anything is failure as long as we learn from it).

You have to measure the impact of innovation to understand your ROI. Otherwise, it’s like trying to capture Bigfoot using a Polaroid camera and a kids’ butterfly net—not gonna happen.

Asking the wrong questions

Do your innovations match what your customers want or need?

Sometimes companies don’t ask the right questions before they start- they just plunge into the idea without figuring out the parameters or fine details.

Innovation is always about solving a problem, even problems that will be important in the next year, three years, or five years. You’re not capturing anything about Bigfoot unless you have the right gear, and you won’t have the right gear if you don’t ask the right questions.

The Soul-Searching Questions You Should Be Asking: Bigfoot Edition

Speaking of asking the right questions, it’s time to rip off the proverbial bandaid and ask yourself some crucial questions (along the issues above) about your innovation programme:

1. Is my company culture conducive to innovation?

Everyone thinks they’re all about innovation but that’s not the case. If you want good innovation, you must give your people the TIME and RESOURCES they need to problem-solve.

2. Am I listening to (and actioning) my customers’ feedback?

Sometimes it’s frustrating having to listen to your customers. Especially when they change their minds, don’t know what they want, or are tempted away by your competition. But they do give insights into areas where your products or services could be improved.

3. Am I doing enough research on competitors?

Figuring out where your competition is awful is probably more helpful than where they’re doing well. Customer reviews, message boards, and social media account comment sections are GOLDMINES for information on what your competitors’ customers need. And they’re free!

4. Am I learning from past mistakes?

It’s such a cliche, but it’s true. The thing is, very few people do it. Mistakes are amazing learning opportunities, but only if you’re willing to do the deed and acknowledge them. Look at the missteps and patterns of your past actions.

5. Are we actually getting the products out there?

If your innovative products or services never make it to the right market, you’ll never see an ROI. Make sure you have a good plan in place for launching and promoting your innovations.

The Action Plan: How to Make Innovation Better and Boost Your ROI (Bigfoot-Style)

So, with all these questions probably circulating in your head, it’s time to take action.

That ROI has been wandering the forest enough. It’s been hiding. Other people have been bragging about it and it’s time to take control and find it once and for all.

Though each business has its own circumstances, and you have a lot of choice, there are some basic steps you can take to make your innovation better and find that elusive ROI:

Establish clear innovation objectives:

Your plan needs specific, measurable goals that align with your overall business objectives.

Foster a culture of collaboration:

Break down departmental silos, offer cross-functional training, and do team-building activities. Make sure your innovators are creative problem-solvers who have the time to play with ideas. It’s not something that can be done crammed into 1-3 hours a week.

Implement a robust measurement system:

Don’t ignore those KPIs – look at revenue growth and cost savings, operational metrics (like process efficiency or time-to-market), and qualitative measures (customer satisfaction or employee engagement).

Continuously iterate and improve:

Innovation is an ongoing process that involves constant research, tests, experiments, etc. Keep going, keep trying, and take risks. Unconventional can be good, even in a conventional industry.

Consider a collaboration with a complimentary business:

Partnering with a trusted, complimentary business helps you pool resources, expand your reach, and drive innovation. Collaborate on new product development or share industry insights.

Be creative with getting the word out:

Promote your innovative products and services using a variety of channels, such as social media, content marketing, and events. Engage customers and partners who love your brand to help build buzz and drive interest.

Broaden how you decide to innovate:

Why focus just on developing new products? Maybe new applications for your existing offerings is a better move. This can cut down on investment and start bumping up the return.

No one said that good ROI on innovation was going to be easy. It’s an elusive thing.

But you’re not alone.

By asking yourself the right questions, addressing the underlying issues, and taking actionable steps to make innovation better, you can unlock the full potential of your efforts and finally achieve that sought-after ROI.

So, channel your inner Bigfoot hunter, unravel the mystery of your missing ROI, and make innovation the driving force behind your business success.

Get that proverbial Bigfoot, film it, and show the world that you’re capable of!Ready to streamline your processes, reduce errors, automate your subscription management operations, and finally focus on your customers?

Share on Socials:

Let’s chat further.

"*" indicates required fields

ARVO in Action: From Requirement to Working Business Central Solution, with Governed, Audit Grade-AI.

AI can already write code. The real challenge for a Business Central partner is turning a customer's requirement into a solution they can confidently sell, deliver and maintain. That is the problem we built ARVO to solve, and today we're sharing a short video that shows it in action. In just four minutes, it follows one customer requirement through ARVO, from the document a consultant writes to a working solution running inside Business Central. Watch the video Why we built ARVO Business Central partners are moving away from billable hours toward fixed-price and outcome-based work. Customization is the hardest part of that shift to price, because its cost depends on who analyzes the requirement, who builds it and who tests it. Give the same requirement to two teams and you get two different projects. ARVO takes every customization through one governed path, from intake to production, so the work is delivered to the same standard whoever does it. AI does the repeatable work: analysis, design drafts, code, tests and documentation. Your consultants and developers set the standard and approve the work at each stage. Every step is recorded, and the expected AI cost of each stage is shown before anyone commits to it. The requirement we chose We didn't want an easy demo. So we built the video around Peachtree Pump Manufacturing, an illustrative family-owned maker of industrial pumps with a single plant in Atlanta, Georgia. Its lines run just in time, so one late truck can stop production. Its dispatchers and planners need to see every inbound truck, what it carries, and whether the parts will reach the line in time. Its Microsoft partner captured that need in a six-page functional requirement for a custom control inside Business Central that: shows trucks on a real road map links each load to its purchase order tracks material from Requested to Available flags supply gaps against released production orders The requirement also sets the business rules, such as "GPS never posts inventory" and "stale tracking shows as Unknown, never as on time", and defines eight acceptance checks. This is the kind of request that usually becomes an open-ended integration project. What you'll see Project setup: the requirement attached to a new ARVO project, with the expected AI cost reviewed before work begins. Analysis and design: the gap analysis, the people who will use the solution, the functional and technical designs, the training manuals and the test cases, all defined before the code exists. Build: the extension built against the target environment and deployed to a Business Central sandbox. The finished control: six trucks on the map, and a selected truck linked to its cargo, purchase order and production demand. A delay widens the supply gap from 30 to 50 minutes and updates the replenishment request for the planner to review. A warehouse receipt then makes only the received quantity available. The path to production: testing, approval by named people, and a gated promotion to production. What this means for your practice The working control is the visible result, but the real value is everything around it. Every ARVO build comes with the evidence a customer's finance team, auditor or next consultant will ask for: design documents traced to each requirement, a user guide for every role, the full test record, and a record of who approved what and when. It is all packaged under your brand and stored in the customer's own Business Central environment. ARVO is also bring-your-own-AI. You connect your own Microsoft Foundry deployment or Anthropic subscription, choose the model, and pay the provider directly. We never resell or mark up AI usage, and there are no per-user fees: one subscription covers your whole delivery team. And because every build starts from the customer's own requirement, you can show them a working extension before the work is even sold. Bring us your hardest requirement We'd love to show you what ARVO can do with a real requirement from one of your customers. Here's how to take the next step: Apply for the Founding Partner Edition. Business Central partners can apply at bluefort.io/arvo. The program includes favorable commercial terms and runs until 29 October 2026. See ARVO live at Directions EMEA. We'll be in Paris from 27 to 29 October at Stand S33, with a 45-minute session on Tuesday 27 October at 16:15 in Room 153. Read the executive brief. Quote the Customization explains the full governed path and the economics behind it. Download the brief. Bring your hardest Business Central requirement →

15.10.2026 AI

AI Made the Build Faster. Governed Delivery Makes It Priceable.

Today we're publishing Quote the Customization, a new executive brief for Dynamics 365 Business Central partners. It looks at why customization has always been the part of a project that resists a fixed price, and how a governed, AI-driven delivery path can finally make it predictable enough to quote. The question every partner is asking Business Central partners are moving away from billable hours. Fixed-price and outcome-based offers are easier to sell, easier to buy, and let a partner keep the value of the work rather than be paid for the time it took. But customization doesn't fit. Configuration and data migration can be estimated from experience; custom work can't, because its cost depends on who analyzes, builds and tests it. So packaged offers include little or no customization, and the work customers most want ends up quoted separately, billed by the hour, or turned away. AI has made the build faster, but speed alone doesn't solve this. A partner still has to answer the questions a customer's finance team will ask: What exactly was built? How was it tested? Who approved it? Will it still work after the next update? Billed by the hour, the time AI saves becomes a smaller invoice. Delivered without governance, it becomes risk the partner carries alone. What's inside the brief We wrote Quote the Customization for partner leaders, practice managers and delivery heads. In it, you'll find: Why customization breaks fixed-price models, and why faster code alone isn't the fix One governed path from requirement to production: the seven gated stages every ARVO customization follows Six principles that make custom work priceable, from locked scope to gates that can't be routed around Where the time goes: our estimate of effort, workstream by workstream, on a major customization Control over the economics: knowing the AI cost before a build starts, and our bring-your-own-AI model An illustrative case study: Peachtree Pump, with a link to our 4-minute demo video Download the executive brief A preview: what makes custom work priceable At the heart of the brief are six principles built into every ARVO build: Scope is locked before anything is generated. A change becomes a new, visible request, not silent rework. The AI cost is known before it starts. The expected cost of every build is shown before anyone approves it, so it can go into the price. Documentation comes with every build. Designs, the test record and a user guide for every role are generated alongside the code. Tests are defined before the code exists. The suite is frozen from the approved design, so it can't be shaped by the code it examines. Testing happens as the user. Every build tests real Business Central permissions, proving users can work and that unauthorized actions are blocked. A gate that can't be routed around. Nothing reaches production except through a server-side gate, and what arrives is identical to what passed. A preview: where the time goes On a major Business Central customization of about 30 days of human effort, we estimate ARVO brings that down to about 5 days, roughly six times the throughput per consultant with the same team. Workstream Typical With ARVO Functional analysis & design 5 days About 2 days AL development 12 days About 1 day Testing & acceptance scripts 6 days About half a day Documentation 4 days Generated with the build Project management, review & sign-off 3 days About 1 day Total human effort About 30 days About 5 days Our planning estimates for a major Business Central customization of about 30 days. Effort only; not a quotation. These are planning estimates, not a quotation. The five days that remain are the ones that need people: judgment, review and approval. Because ARVO records every step, you can check the figures on your own projects. Why now Microsoft now sets the pace of change in Business Central. From version 29, older SOAP connections to Microsoft's standard pages stop working. Version 30, in 2027 release wave 1, does the same for OData connections and changes how custom apps are deployed. Every customer with an affected integration needs the same fix: find it, rebuild it, prove it works. That's work a partner can price once and deliver many times, with every fix running through the same governed path, whether it's the first customer or the fiftieth. Get the full brief The brief goes deeper on all of this, including the full seven-stage path, the evidence pack every build produces, and the complete Peachtree Pump case study. Download Quote the Customization → Want to go further? Business Central partners can apply for the ARVO Founding Partner Edition at bluefort.io/arvo, with favorable commercial terms until 29 October 2026. And if you're at Directions EMEA in Paris, come and see ARVO run live at Stand S33, or join our 45-minute session on Tuesday 27 October at 16:15 in Room 153.

05.10.2026 AI

Fixed-price Business Central projects leave customization out. ARVO puts it back in.

Bluefort launches ARVO, governed build and delivery AI for Microsoft Dynamics 365 Business Central, so partners can quote custom work and deliver it the same way every time. Malta, 5 October 2026. Bluefort today launched ARVO, governed build and delivery AI for Microsoft Dynamics 365 Business Central. Bluefort estimates that on a typical Business Central customization of around thirty consultant-days, ARVO brings the human effort down to about five: roughly six times the build throughput from the same team. And it does it the same way every time, with every customization designed, tested before the code exists, signed off by a named person and delivered with the evidence. That makes custom work predictable enough to price, the part of a Business Central project that fixed-fee offers usually leave out. How to deliver fixed-price services work has become one of the most debated questions among Business Central partners. AI has made the build faster, but billed by the hour, that speed goes to the customer. Fixed pricing lets a partner keep the value, and it only works when delivery is predictable. Custom work rarely is. Its cost depends on who analyzes the requirement, who builds it and who tests it, which is why packaged fixed-fee offers typically include little or no customization. “AI can already write code. The real challenge is turning a customer’s requirement into a solution a partner can confidently sell, deliver and maintain,” said Edward Borg Grech, Chief Executive Officer of Bluefort. “ARVO connects analysis, design, build, testing and deployment in one governed process, with evidence and human approval throughout. It gives consultants greater delivery capability and partners a way to take on work they previously had to turn away. That means pricing with greater confidence and growing delivery capacity without growing headcount at the same rate. Partners can charge for the value they deliver and keep the productivity gains AI creates, instead of giving them away through fewer billable hours.” [caption id="attachment_6212" align="aligncenter" width="1030"] A Supply Chain Control Tower for Business Central, built with ARVO in about an hour.[/caption] One governed path A partner’s consultants, architects and developers define the standard and approve the work. ARVO takes every customization from requirement to production in one governed path, to that standard: Scope is locked before anything is generated, so a change becomes a new, visible request rather than silent rework. Standard Business Central is configured first, existing IP is reused second, and new AL is generated last. The design is approved, and the test suite is written from it and frozen before the code exists, so the test cannot be shaped by the code it examines. Every build is compiled, analyzed and tested, including under the real Business Central permission sets of each user role. Every stage ends in a gate, seven in all, and named people approve at four of them. Nothing reaches production except through a server-side gate, and what arrives is byte-identical to what passed. Each build produces a partner-branded evidence pack, a user guide for every role that will use the extension, and a tamper-evident Build Receipt the client can keep. The five days that remain are the ones that need people: judgment, review and approval. And because every step of every build is recorded, with who did what and when, a partner can measure the difference on their own work rather than take Bluefort’s word for it. Know the AI cost before it starts Before anyone approves a build, ARVO shows its expected AI cost, worked out on the model the partner has chosen and set out as a range from minimum to maximum. The partner knows what the AI will cost before committing to it, and can build that into the price. Your AI, your model, your bill ARVO is bring-your-own-AI by design. It runs on the frontier models from the major AI labs, deployed in the partner’s own Azure AI Foundry. The partner picks the model, and usage is billed by Microsoft to the partner’s own Azure subscription. Bluefort never resells, marks up or absorbs AI usage, and never stores AI credentials. ARVO works in a Business Central sandbox and never tests in production. Bluefort holds no Business Central credentials or business data, and its runtime is hosted in the European Union. “A partner putting their name and price on a solution needs control over the economics behind it,” said Borg Grech. “With ARVO, partners see the expected AI cost before approving a build, choose their model and pay Microsoft directly through their own Azure subscription. ARVO’s subscription has no per-user fees or additional AI charges from Bluefort. That separation matters: partners can see what they are paying for, decide where to spend and change their model choice as AI evolves. They can build their commercial offering around decisions they control.” Show it before you sell it Because every build starts from the client’s own requirement, a partner can show a client a working extension before the work is sold. The client sends the requirement today; the partner shows them a working extension tomorrow. [caption id="attachment_6213" align="aligncenter" width="1030"] Compass, the ARVO dashboard that guides a consultant from requirement to a working extension.[/caption] Why now Change in Business Central no longer waits for a partner’s schedule. From version 29, rolling out this month, a Microsoft page can no longer be exposed as a SOAP endpoint. Version 30, due with 2027 release wave 1, extends that to OData and ends PTE uploads through Extension Management. Each is the same change repeated across every affected customer: the kind of work a partner should be able to price once and deliver many times. One subscription, no per-user fees ARVO Studio is available from today as a free install on Microsoft AppSource. Bluefort charges one subscription and nothing on top: no per-user fees and no AI charges. Partner Edition serves a partner’s delivery practice across its customer environments, with unlimited seats for the whole delivery team. Customer Edition serves Business Central customers with their own development teams. Founding Partner Edition Business Central partners can apply for the ARVO Founding Program at bluefort.io/arvo until Directions EMEA. Partners accepted into the program join on the Founding Partner Edition, with favorable commercial terms. Get in touch today to find out more. Full details of ARVO are at bluefort.io/arvo. See it live in Paris Bluefort will run ARVO live, end to end, at Directions EMEA in Paris from 27 to 29 October, at Stand 33 and in its 45-minute session "Governance for ERP-Grade AI: Scale Clients, Not Consultants" on Tuesday 27 October at 16:15 in Room 153. About Bluefort Bluefort is a Microsoft ISV for Dynamics 365, headquartered in Malta. Its products run natively inside Dynamics 365 across three pillars: Revenue Model Management, covering every commercial model with IFRS 15 and ASC 606 recognition built in; Payment Orchestration, a native multi-provider payment layer from invoice to reconciled cash; and BC Intelligence, governed, ERP-grade AI for building and testing Business Central extensions. Governed AI agents and a clean, connected data foundation complete the portfolio. Dynamics. Taken Further. bluefort.io

25.08.2026 Manufacturing

The Two Silent Killers of Dynamics 365 As-a-Service Transformations

Ask a manufacturer why their As-a-Service transition stalled, and you rarely get “we didn’t want it enough.” Leadership signed off. The strategy made sense on paper. The market case was real. And yet, across the more than 500 industrial As-a-Service transitions P2S Management Consulting has studied, most transformations stall anyway. That’s the uncomfortable part of this work: the failure point is almost never visible on the plan. It’s not a missing line item or a skipped approval. It’s something that looks fine in the deck and quietly sinks the model anyway. And here’s the detail most executives miss when they’re bracing for it: that failure point isn’t fixed. It moves, depending on what stage of the transition you’re in. Watch for the wrong one, and you’ll have your eyes on last quarter’s risk while this quarter’s is compounding. Killer #1: Leadership buy-in, early on The first silent killer shows up at the very beginning, while the model is still being designed, and it has almost nothing to do with strategy. It’s about incentives. Here’s how it plays out. Everyone in the room agrees the As-a-Service model is the right move. The pitch deck is compelling. The pilot gets approved. But the sales team is still being paid, in practice, the same way it always was: commission on machines sold. And if your best rep still earns more for pushing a CAPEX deal than for closing an outcome-based contract, the strategic intent at the top of the business never survives contact with the sales floor. Nobody has to sabotage the model. It’s enough that nobody’s incentives changed. This is why “leadership buy-in” has to mean more than a mandate from the top. It has to show up in the compensation plan, because that’s the only place a sales organization actually listens. Killer #2: Billing and the platform underneath, once you scale The second killer doesn’t show up at the start. It shows up later, once the pilot has proven itself and the business starts pushing volume through the model, and it’s a completely different kind of failure. This one is operational, not cultural. A handful of outcome-based contracts is manageable on almost anything, including a spreadsheet and a diligent finance person reconciling usage against invoices by hand. It works, right up until it doesn’t. Somewhere around the tenth contract, for reasons we’ve unpacked in more detail elsewhere, the manual effort behind the billing stops scaling with contract count and starts scaling faster than it. What looked like a proven, repeatable process on paper starts eating headcount instead, and a strategy that was genuinely sound starts looking, from the outside, like it isn’t working. For a Dynamics 365 manufacturer specifically, this killer has a name and a location. Standard D365 Finance and Supply Chain Management (and Business Central) handles core invoicing well, but it doesn’t natively track what a customer is entitled to receive against what they’ve consumed, doesn’t automatically catch overage, and doesn’t give a portfolio-level, governed view of what each contract actually promises. Those gaps are exactly where the manual effort piles up, and exactly where the second killer lives. The killer moves, so your attention has to move with it The practical implication is that “watch for the silent killer” isn’t a single, fixed piece of advice. It’s a sequencing problem. Early in a transformation, the thing worth interrogating hardest is whether sales incentives have genuinely changed, not just whether leadership has said the right things in a town hall. Later, once the model is scaling, the question shifts entirely to whether the platform underneath, inside Dynamics 365, specifically, can run the commercial model at real volume without absorbing headcount as it grows. Transformations that hold up tend to share one habit: they don’t treat these as one problem solved once. They check both, at the point in the journey where each one actually bites, rather than assuming that clearing the first means the second won’t arrive. We unpacked both silent killers in more detail, including a real, anonymized case of a mid-market manufacturer that hit exactly this pattern, in a recent joint session with P2S Management Consulting. Watch the on-demand session: Why Manufacturers Struggle to Grow Service Revenue in Dynamics 365, and How to Fix It Read the full research: From Products to Outcomes: The Dynamics Manufacturer’s Guide to Winning with Service-Based Models, Download the eBook

20.08.2026 Manufacturing

Why Now? The Four Forces Ending Product-Only Growth in Manufacturing

If you build or sell industrial equipment, you've heard the pitch before: sell the outcome, not the machine. It's not a new idea; manufacturers have been hearing some version of it for over a decade. And yet, walk the floor of almost any industrial trade show today, and the majority of the market is still selling machines. So the interesting question isn't whether outcome-based, service-led revenue models work in theory. It's why so many capable manufacturers who try them stall , and why, despite that, 2026 is a genuinely different moment to make the shift than 2016 was. The answer comes down to four structural forces. None of them is speculative. All four are visible in the market right now. 1. The margin has left the machine Start with where the money actually is. Look across the manufacturing sector and a consistent pattern shows up: aftermarket and service revenue tends to run at roughly 25% margin, while new equipment sales sit closer to 10%. That's not a rounding difference; it means the bulk of the profit in an asset's life increasingly sits in the service relationship that follows the sale, not in the sale itself. That has a sharper implication than “services are nice to have.” It means a manufacturer who competes purely on shipping units is, in effect, competing to win the low-margin third of the value an asset will generate over its life, and handing the other two-thirds to whoever services it, finances it, or operates it afterward. Sometimes that's a competitor. Increasingly, it's a third party with no stake in the equipment at all. 2. Buyers are procuring outcomes, not equipment The second force is on the demand side. Procurement teams are changing what they ask for. Recent research puts outcome-based purchasing at roughly a quarter of manufacturing procurement decisions today, with buyers expecting that figure to climb toward half within the next decade. This isn't buyers being difficult. It's buyers applying the same logic to industrial equipment that they've long applied to mission-critical infrastructure: they want guaranteed performance, predictable cost, and one accountable party, not a piece of capital equipment and a warranty card. In sectors that made this shift early - construction equipment, aircraft engines, HVAC , service revenue already accounts for somewhere between 50% and 65% of total revenue. That's not an emerging trend in those categories anymore. It's simply how the market works now. 3. The measurement barrier is gone For a long time, the honest objection to outcome-based models was practical, not strategic: you can't bill for what you can't measure. Guaranteeing uptime, output, or efficiency requires knowing, continuously and verifiably, whether you're delivering it. That constraint has largely dissolved. With something in the order of 21 billion connected devices now in operation, the infrastructure for continuous performance monitoring is no longer a bespoke engineering project; it's increasingly standard on the equipment manufacturers already ship. The question has quietly shifted from “can we measure this?” to “have we built the commercial and contractual structure to act on what we're already measuring?” For most manufacturers, the honest answer is: not yet. 4. The early-mover gap compounds The fourth force is the one that punishes hesitation specifically. Outcome-based contracts don't just carry higher deal values; they run for years and renew, rather than resetting to zero at the start of every sales cycle. Every multi-year outcome contract a competitor signs takes that customer off the market for the length of the contract, often the better part of a decade. That's a fundamentally different competitive dynamic than product sales, where this quarter's loss is next quarter's opportunity. In outcome-based markets, the provider who signs first doesn't just win a deal; they remove a competitor's future opportunity to bid at all. The gap between early movers and everyone else doesn't stay flat. It compounds, one contract at a time. So why now, specifically? Put the four together, and the picture is less “outcome-based models are a good idea” and more “the market has moved, whether or not you've moved with it.” The margin has already relocated to service. Buyers are already asking for outcomes. The technology to measure and bill for them is already in place. And the manufacturers who acted on this earliest are already several contracts into locking up their addressable market. None of that means every manufacturer should attempt this transition, or that it's simple once you decide to. In our experience, and in the more than 500 industrial As-a-Service transitions behind the research this piece draws on, the harder and more common problem isn't deciding whether outcome-based revenue makes sense. It's that most transformations stall on operations, not strategy: pricing that finance can't account for, contracts that legal can't govern, and billing that the underlying systems can't actually run. That's the part worth getting right before the first contract is signed, not after. It's also exactly what we unpacked, in more practical detail, in a recent joint session with P2S Management Consulting, including the two “silent killers” that quietly sink most transformations, and where a standard Dynamics 365 environment can and can't carry an outcome-based model without help. Watch the on-demand session: Why Manufacturers Struggle to Grow Service Revenue in Dynamics 365 , and How to Fix It Read the full research: From Products to Outcomes: The Dynamics Manufacturer's Guide to Winning with Service-Based Models, Download the eBook

18.08.2026 AI

The BC Implementation Opportunity Nobody Is Talking About Yet

Every BC implementation partner knows the pattern: margin absorbed, timelines extended, client expectations managed downward. The opportunity to change that is arriving, and most of the ecosystem has not yet looked up from the current process long enough to see it. There is a process at the centre of every Business Central implementation that has remained essentially unchanged since the platform was first deployed at scale. A client describes a business requirement. A functional consultant interprets it. A developer translates the interpretation into AL code. Someone tests the result manually. Feedback comes back. The cycle repeats. The number of tools available to support this process has grown considerably. The process itself has not. The requirement-to-production cycle in BC customisation is still, at its core, a handmade process. Each extension is built from scratch or adapted from a prior project. Each test is run by a person following a test script. Each deployment is managed by a developer who understands the specific configuration of this client's BC environment. This is not a criticism of the people doing the work. BC implementation teams are, in many cases, operating at the limit of what the current process allows. The problem is the process, and the process has structural characteristics that make it resistant to improvement within its existing design. Why the cycle is so hard to compress The requirement-to-production cycle in BC is long for reasons that are interconnected and mutually reinforcing. The first is the translation problem. Business requirements are expressed in operational language. The person describing the requirement understands what the business needs, but not necessarily how BC's data model, permission architecture, or extension framework will accommodate it. The developer understands the implementation constraints, but not necessarily the business context that makes one approach preferable to another. The functional consultant sits between them, translating in both directions. This translation layer adds time, introduces interpretation errors, and creates a feedback loop that is difficult to short-circuit. The second is the testing problem. Manual testing of BC customisations is time-consuming, inconsistent, and incomplete. Test scripts capture the scenarios the tester anticipates. They do not capture the scenarios the tester did not think to test, which are precisely the scenarios most likely to surface as production issues after go-live. Automated testing in BC environments exists but is not yet standard practice across the partner ecosystem, and implementing it adds a layer of upfront investment that many projects cannot absorb. The third is the knowledge problem. Every BC implementation accumulates environment-specific knowledge, configuration decisions made early in the project, integrations added at different points, customisations that interact with each other in ways that are not always fully documented. This knowledge lives primarily in the heads of the people who built the system. When those people are not available, or when a new requirement touches a part of the environment they did not build, the investigation work required before a new extension can be safely developed adds time that the project timeline did not anticipate. What this costs The cost of the handmade build process is distributed across three places. Partners absorb it in margin. Projects that were scoped on the assumption of a linear, well-understood build process encounter translation delays, testing rework, and knowledge investigation work that was not in the estimate. The additional effort comes out of the project margin rather than the client's budget, because raising a change request for work that should have been part of the original scope is a conversation nobody wants to have. Clients absorb it in timeline. The requirement that was described in week three of the project is tested in week eleven. By week eleven, the business context has shifted. The person who described the requirement has moved to a different role. The urgency that justified the customisation has either intensified or resolved without the system's involvement. The relationship absorbs it in trust. A client who expected a three-month implementation and experienced a five-month one, with a final result that only partially matches what was described, does not approach the next project with the same confidence. The gap between what was promised and what was delivered is the gap where partner-client relationships erode. Why this is a structural problem, not an execution problem The instinctive response to the build problem is to improve execution within the existing process. Better project management. Better requirements documentation. More experienced developers. More thorough testing. These improvements help at the margin. They do not change the structural characteristics of the process. The translation layer is still there. The manual testing is still there. The environment-specific knowledge is still concentrated in individuals rather than systematically captured. The build problem in Business Central is not a problem that can be solved by doing the same thing better. It requires a different approach to how requirements become extensions, how extensions are tested, and how environment knowledge is captured and reused. That different approach is beginning to arrive in the Dynamics ecosystem. Microsoft's announcement of Project MIA at DynamicsMinds in May 2026, aimed initially at F&SCM partners, signals that the ecosystem's direction of travel is toward AI-assisted implementation. What that means for BC, and on what timeline, has not yet been confirmed. What is clear is that the build problem is recognised at the highest level of the ecosystem, and that the current process is not the destination. The partners and clients who understand the structural nature of the problem now will be better positioned to evaluate and adopt what comes next. The ones who attribute it to execution will keep trying to fix the wrong thing.