How We Work
Automation consulting has an incentive problem: most firms are paid the same whether the system works or not. On projects with a measurable return, we take a share of the gain instead of a large upfront fee. On projects without one, we say so and charge a fixed rate.
The split is not a sales tactic, it is a consequence of what can be measured. Some work produces a number you can point at. Some work is the foundation that makes those numbers possible later. Pretending the second kind has a direct return would mean inventing one.
When the project has a measurable financial outcome, reduced scrap, recovered throughput, avoided downtime, reallocated labor, we take an agreed share of the value generated instead of a large fee up front.
Instrumentation, sensor integration, and data infrastructure rarely carry a directly attributable profit number on their own. They are what later projects stand on, so we scope them and bill a fixed, predictable rate.
A profit-share only works if both sides trust the number. That trust is built before deployment, not argued about afterward. Before we start, we agree in writing on:
The exclusions clause matters more than people expect. It is what keeps the arrangement credible when something good happens on the line for reasons that have nothing to do with us.
The test is simple: can we point at a number in your systems, before and after, and agree on what caused the difference? Work that usually passes that test:
Work that usually does not, and gets quoted fixed-rate instead: instrumenting a line that has no reliable data today, building the historian and labeling infrastructure, and exploratory studies where the answer might legitimately be "automation will not pay here."
A fixed fee gets paid whether or not the system survives contact with your floor. That creates a real incentive to declare victory at handover and move on. A profit share does the opposite: if the system drifts, gets bypassed by operators, or quietly stops being used after three months, we feel it.
It also changes what we are willing to tell you. When our return depends on a measured gain, we have every reason to say early that a project will not pay for itself, rather than selling it anyway. That conversation is cheaper for both of us in week one.
Then our share is small or nothing, which is the point of the structure. That risk is priced into the share we agree on, and it is why we are selective about which projects we take on this basis.
Not always. Hardware still has to be bought, and some engagements carry a reduced fee alongside a smaller share. What the model removes is a large fee paid before anyone knows whether the automation works.
For whatever term we agree on at the outset. Some engagements run for a set number of years, some run for as long as the system stays in production and keeps generating the gain. Both are reasonable structures, and which one fits depends on the size of the investment, the share, and how long the improvement can be expected to hold. It is a conversation we have before anyone signs anything, not a surprise later.
That is the intent. Tolerance bands, recipes, and process settings are meant to be changed by your engineers in the course of normal operation, without a call to us and without touching model code.
Describe the problem and what it currently costs you. If it is measurable we will propose a share, and if it is not we will tell you that and quote it fixed.