The field questionnaire is closed: 4 of 5 sellers answered and the answers are already working material.

The biggest objection I hear is, "We already have a controller, SCADA system, or monitoring platform, so why do we need EKU?"

My response is that we are not competing with a controller. We are solving a fleet management problem. Most customers have assets from multiple OEMs, multiple generations of equipment, and often multiple sites. They end up with fragmented data, inconsistent visibility, and limited ability to manage the fleet as a whole. EKU gives them a single platform to monitor, manage, optimize, and control mixed-brand generator fleets regardless of the OEM. We explain that while individual engine or generator controllers handle localized run signals, our universal automation platform (Maximus) and cloud analytics (Sophia) deliver site-level automation, automated load sharing, dynamic sequencing, and high-frequency signal diagnostics across all connected units. Instead of navigating separate, disconnected OEM portals for Caterpillar, Waukesha, MTU, or Jenbacher assets, operators gain a unified, vendor-agnostic control and data layer.

Customers sometimes sharpen this objection by saying, “We already have Ignition, Hitachi, Deep Sea, ComAp, or an internal Power BI tool. Are you asking us to add a third SCADA system?” Our answer is no. EKU can operate at the asset, balance-of-plant, site-controller, or cloud layer and interface through protocols such as Modbus TCP, DNP3, MQTT/Sparkplug, CAN, and J1939. We can preserve the customer’s existing SCADA, controllers, operating procedures, and data flows while adding the orchestration or diagnostic capability that is missing. In installed fleets, the right approach is often a staged overlay or hybrid architecture, not a disruptive rip-and-replace.

A related objection is vendor lock-in: “Will EKU create another proprietary wall, and will we still be able to modify or support the system ourselves?” We address this by defining control ownership, configuration access, interfaces, data access, training, and long-term support during the discovery phase. The goal is to leave the customer operationally self-sufficient while EKU remains available for higher-level engineering, software, and optimization support.

The second objection is ROI. Customers often say, "Everything is running today, why should I spend money on this?" My answer is that the cost of one generator outage, one failed black start event, one unnecessary site visit, or one engine failure is significantly higher than the cost of implementing proactive monitoring and analytics. We help customers reduce downtime, improve maintenance planning, optimize fuel consumption, and increase asset availability. In our commercial discussions, we quantify this by demonstrating how DAQ troubleshooting eliminate unnecessary run hours, reduce fuel burn and emissions, and prevent thermal or mechanical stress during rapid restarts. We also address capital expenditure constraints directly by offering flexible commercial structures, including site Hub subscriptions, structured Customer Service and Reliability Programs (CSRP), and phased proof-of-concept pilots that demonstrate measurable payback before a full fleet rollout.

The ROI case has to match the economics of the person buying. In some applications, the operator supplies the fuel, while the service company bears the maintenance, labor, downtime, and capital-replacement costs. In those cases, fuel savings alone will not close the deal. We quantify the outcomes the buyer actually owns: fewer engine hours, longer overhaul intervals, lower R&M expense, fewer emergency callouts, less critical inventory, improved utilization, and the ability to operate the same workload with fewer redundant assets.

We also avoid asking customers to accept a theoretical fleet-wide ROI on day one. We can baseline a fleet or site, deploy the initial controls without advanced automation, and then introduce idle management, sequencing, or rate automation in measurable stages. That gives the customer evidence from its own operations and turns a large capital decision into a controlled proof-and-scale process.

A good example is what we see in the data center and power generation markets. Many operators are investing millions in new generation assets while still lacking the visibility to maximize the assets they already own. The conversation is not about buying more equipment. It is about extracting more value from existing equipment.

In data centers, the objection is often more specific: “Can this architecture actually survive AI-driven load transients, and do you have proof at our scale?” We answer by separating controller response from equipment response, modeling the complete system, including generators, batteries, flywheels, switchgear, and loads, and validating the operating philosophy before commissioning. The value is not simply faster data collection; it is maintaining reserve, coordinating mixed assets, preventing cascading trips, and determining how much storage or spinning capacity is actually required.

The third objection is execution risk. Customers want to know whether EKU has the experience and capability to support critical power infrastructure. I explain that we support applications ranging from oil and gas and mining to utility, industrial, and data center power generation. We provide controls integration, monitoring, power management solutions, remote operations capability, UL-certified panel manufacturing, and engineering support. We are not a software startup. We understand generators, engines, switchgear, controls, and plant operations. We address operational risk by emphasizing our field-hardened pedigree and multi-tier engineering support structure, ranging from dedicated on-site field technicians to senior controls engineers. Furthermore, we clarify our architecture's strict three-layer safety hierarchy: hardwired relay-to-breaker safety circuits and independent functional safety protection always take priority, ensuring that remote commands or advanced cloud automation can never override local emergency stops, physical protection limits, or on-site operator authority.

This objection often appears as, “EKU may have the technology, but are you large enough and bankable enough for a critical project?” The best answer is not a generic statement about company size. It is a concrete execution plan: named engineering ownership, completed reference applications, hardware-in-the-loop or software-in-the-loop testing, commissioning milestones, training, cybersecurity documentation, escalation procedures, and a defined long-term service structure. For critical infrastructure, technical proof must come before the customer is asked to take commercial risk.

Local support and spare-parts availability are frequently part of the same objection. Customers compare EKU with controllers and components they can obtain from a local distributor and ask what happens at 2:00 a.m. if an EKU-configured component fails. We answer with preconfigured plug-and-play spares, defined regional inventory, rapid-swap procedures, remote diagnostics, trained local partners, and service agreements that clearly assign responsibility after commissioning or a trial. Where local coverage is still developing, we need to acknowledge that directly and build the coverage plan into the proposal rather than treating it as an afterthought.

Finally, some customers worry that the project is bespoke R&D rather than a repeatable deployment. We address that through a paid discovery and definition phase, a written control philosophy, clear interface boundaries, simulation and factory testing, and staged commissioning. We distinguish between standard platform components and the project-specific integration work so the customer understands exactly what is proven, what must be configured, and what, if anything, requires new development.

In power generation, there is rarely a single decision maker.

The operations team is usually the champion because they live with the downtime, alarms, maintenance issues, and performance challenges every day. Field supervisors and plant operators want intuitive HMI interfaces, streamlined standard operating procedures, and automated restart sequences that prevent nuisance trips and manual operator error under harsh site conditions.

Operators also have an effective veto over adoption. If they do not trust automatic shutdown, restart, load sharing, or remote-control behavior, they will work around it. That can reduce the measured ROI and make a technically successful installation look unsuccessful. Operator involvement, hands-on training, and clear manual-override rules therefore matter before, not after, deployment.

The engineering group validates the architecture, cybersecurity requirements, integration approach, and overall technical feasibility. Electrical, controls, and balance-of-plant engineers look closely at communication protocols, wire harness integration, protection coordination with medium- and low-voltage switchgear, and safety layer isolation.

The controls or SCADA specialist is often the first formal gatekeeper. This person determines whether EKU becomes an unnecessary additional system or a useful orchestration layer within the existing architecture. Their approval depends on protocol compatibility, data ownership, controller responsibility, source or configuration access, redundancy, latency, simulation results, and whether the proposed solution can be maintained without permanent dependence on EKU.

Maintenance managers want to understand how the solution will improve reliability and reduce emergency repairs. They focus on root-cause diagnostic capabilities, scheduled preventive maintenance workflows, critical inventory availability, and rapid-swap component programs to keep mean time to repair as short as possible.

Maintenance can also become the strongest champion when the business case is built around outcomes it owns: fewer wearable hours, longer overhaul intervals, standardized controls, simpler troubleshooting, reduced emergency work, and fewer unique parts. In several discussions, maintenance leaders were the people collecting the technical and economic case before presenting it to their boss or capital approver.

Continuous improvement and digital transformation teams frequently participate as internal sponsors, seeking fleet-wide standardization, automated operational reporting, and carbon reduction metrics across both off-grid and hybrid installations.

IT or OT teams are increasingly involved, especially when remote monitoring, cloud connectivity, or cybersecurity requirements are part of the project. They evaluate cloud gateway connectivity, secure remote telemetry, network segmentation between field equipment and corporate networks, and user access permissions.

They may also evaluate hosting location, multi-tenancy, penetration testing, data retention, APIs, integration with historians or enterprise systems, and whether remote control is segregated from monitoring. Their questions need documented answers; broad assurances are generally not enough for enterprise or critical-infrastructure buyers.

Procurement gets involved once the commercial discussion begins and often focuses almost entirely on price and contractual terms. They evaluate long-term service level agreements, spare parts replenishment lead times, field service hourly rates, per diem terms, and software licensing tiers.

Procurement also tests commercial predictability: what is included in the base scope, what is custom engineering, when subscriptions begin, how pricing changes as the asset count grows, who owns trial consumables and replacement parts, and whether the customer is committing to a lease, purchase, or multiyear service term. Configuration or pricing ambiguity can create friction even when the total price has not changed.

EPCs, packagers, OEMs, and channel partners may be equally important because they determine who is specified into the project and who carries integration responsibility. They can be advocates when EKU completes their solution, but they can also resist if they believe EKU is competing for the same customer, controlling sensitive data, bypassing the channel, or reducing their aftermarket revenue. Getting the technical solution accepted without aligning partner incentives does not guarantee a win.

Banks, financiers, and ownership groups enter when the project depends on external capital or an unfamiliar technology. They look for installed-base evidence, product references, warranties, local service, replacement-part commitments, certification, and confidence that the equipment and supplier are financeable. A technically strong solution can still lose if the lender cannot de-risk the project.

Legal and commercial teams may also become gatekeepers around NDAs, intellectual property, data rights, warranties, limitations of liability, exclusivity, and the customer’s right to maintain or modify the system. Regulators, utilities, or certification bodies can influence the decision when CSA, UL, grid-code, emissions, or interconnection requirements apply.

The final signature usually comes from plant management, asset management leadership, operations executives, or ownership groups responsible for capital allocation and operational performance.

In practice, the decision often proceeds in sequence: the operator or maintenance team identifies the pain; engineering and IT determine whether the solution is acceptable; the project or operations leader validates execution; finance and procurement test the economics; and an executive, owner, or board releases the capital. We need a champion at each critical stage rather than relying on one enthusiastic contact.

The most successful projects are the ones where operations understands the value, engineering trusts the solution, and management clearly sees the business case.

We lose deals when we enter the conversation too late and are forced to respond to a specification that was written around another supplier's solution. When an RFP is locked around proprietary OEM hardware before we can demonstrate the benefits of an open, fleet-wide architecture, customers default to legacy component-level procurement.

We also lose when the EPC, packager, OEM, or controls engineer has already selected the architecture. By that point, EKU is evaluated as an exception or additional interface rather than as the system-level solution. Getting specified early allows us to shape the operating philosophy, protocol boundaries, testing plan, service model, and commercial scope before those decisions become expensive to change.

We lose deals when customers view the project as a controls purchase instead of an operational improvement initiative. If the discussion becomes only about hardware pricing, we have already lost part of the value conversation. When our scope is evaluated merely as an individual control box rather than an integrated site automation, remote diagnostics, and fleet intelligence platform, the true operational return on investment is lost in component comparisons.

We also lose when our differentiation is unclear. If Sophia is presented as another dashboard, or Maximus as another controller, customers compare us with lower-cost monitoring vendors, familiar controllers, or tools they can build internally. Our position must be tied to a specific operational outcome: mixed-fleet orchestration, standardized controls, actionable diagnostics, automated sequencing, improved utilization, or lower lifecycle cost, not simply collecting and displaying more data.

We lose deals when customers underestimate the cost of downtime and overestimate the cost of prevention. This is especially true when organizations lack centralized visibility into their historical maintenance losses, fuel waste during unmanaged idle periods, or production losses caused by recurring field communication faults.

We can also lose when we build the business case around savings the buyer does not receive. A service company that does not pay for fuel may care more about engine hours, R&M, utilization, critical inventory, and capital replacement. If we do not understand who owns each cost and benefit, a technically valid ROI model may still fail to persuade the economic buyer.

We also lose deals when the incumbent OEM is viewed as the safest option. In many cases, customers continue adding OEM-specific platforms and create an increasingly fragmented fleet environment. The short-term decision may look safer, but it often leads to higher long-term operating costs, reduced visibility, and less flexibility.

Incumbency is reinforced by switching costs, operator familiarity, local parts, published certifications, established warranties, lender confidence, and relationships with dealers and service organizations. To overcome it, EKU has to make migration low-risk through overlays, hybrid architectures, staged deployments, customer training, and preservation of existing operating workflows. “Better technology” by itself is not enough.

We lose deals when we do not adequately relieve customer anxieties regarding local field service readiness, operator training, and spare parts availability. Industrial operators operate under zero-downtime tolerance, and if they perceive any uncertainty around rapid on-site technical response or critical inventory turnaround, they hesitate to transition away from familiar legacy systems.

This is not hypothetical. We have seen opportunities move to alternatives after customers concluded that local support was insufficient, and we repeatedly hear concern that a common controller can be sourced from a distributor in town while an EKU replacement may require configuration. We need the inventory, training, escalation, and rapid-swap model defined before the customer asks, not after deployment.

We lose deals when the product appears unproven, overly custom, or difficult to deploy at scale. Excessive installation downtime, incomplete documentation, uncertain interface requirements, changing hardware configurations, unresolved certifications, or field trials conducted before the product is ready all increase perceived risk. In mining and other high-utilization applications, a solution that requires ten days of equipment downtime will not scale even if the underlying technology works.

We lose deals when we are slow to turn customer feedback into visible proof. Delayed demonstrations, incomplete brochures, unresolved dashboard requests, missing technical documentation, or uncertainty over basic integration questions reduce credibility. A fast mock-up, working demo, written interface definition, or customer-specific simulation can be more persuasive than another presentation.

We lose deals when customers perceive EKU as too small or insufficiently bankable for the project. That concern becomes stronger as the application moves toward large data centers, utility-scale systems, or zero-tolerance critical loads. We answer it through references, tested architecture, named engineering resources, milestone-based delivery, cybersecurity and certification evidence, local support, and contractual service commitments, not by dismissing the concern.

We lose deals when channel incentives are misaligned. Dealers may resist solutions that reduce overhaul and parts revenue. OEMs or packagers may worry that EKU will approach their customer directly. Customers may distrust a supplier that also appears to compete with them or control sensitive operational data. Clear account ownership, data rights, exclusivity, referral economics, and service responsibilities are therefore part of winning the deal.

We lose deals when we pursue the wrong opportunities or overcommit before technical scope is proven. Selling first and figuring it out later may create short-term momentum, but rushed deployment, resource constraints, and an unfinished support model can damage the reference account and affect the next several opportunities. We need to distinguish confidently between what is already proven, what is configurable, and what requires engineering development.

Most importantly, we lose deals when we fail to quantify the business impact. When customers clearly understand the financial consequences of downtime, stranded data, inefficient maintenance practices, and underutilized assets, the conversation changes dramatically. The discussion is no longer about buying a monitoring system. It becomes a discussion about improving reliability, availability, and profitability across the entire fleet.

The strongest close is a customer-specific proof plan: establish the baseline, agree on the KPIs, assign ownership for implementation and support, validate the technology under real operating conditions, and define the conditions for fleet expansion. That converts broad claims into evidence and gives every stakeholder, from the operator to the capital approver, a reason to move forward.

“Our current system already works.”

We position EKU not as a replacement for everything the customer already has, but as an optimization layer. MAXIMUS integrates automation, pump health monitoring, remote control and operational visibility to improve the performance of the existing fleet and reduce dependency on manual intervention.

“We need proof before deploying it across the fleet.”

This is probably one of the most common objections. Our answer is to start small: pilot installations, limited fleet deployments, or rental models that allow the customer to validate performance in real operating conditions before making a larger commitment.

“Integration with our existing equipment could be complicated.”

Frac fleets are heterogeneous, with different engines, transmissions, pumps and control systems. We address this through engineering support, field testing and integration experience across different equipment configurations. The objective is to minimize disruption to existing operations.

“What happens if the system fails during an operation?”

Reliability and support are critical in frac operations. We address this through local technical presence, remote support, monitoring capabilities and defined service levels. We also emphasize that the technology is designed around operational continuity and safe fallback strategies.

The decision process can follow two very different paths depending on the customer.

In some cases, innovation starts from Operations or Technical teams.

Technical and operational teams identify an opportunity to improve performance and are interested in testing new technologies. They can become strong internal champions for EKU.

However, when the discussion moves up to Management, the process can become more difficult. Management may focus more heavily on cost, ROI, implementation risk and the organizational impact of changing established processes. In these cases, the challenge is turning technical enthusiasm into a strong business case that justifies the investment and the change.

one customer was a different case.

The project was strongly pushed by Senior Management. There was some resistance to change at the operational level, but Senior Management had a clear vision regarding technology, automation and the future of the operation. That vision was critical to overcoming internal resistance and moving the project forward.

This shows that EKU can face two opposite dynamics:

• Bottom-up: Operations/Technical teams push innovation → Management challenges cost, ROI and change.
• Top-down: Senior Management pushes technology and automation → Operations may resist changing established ways of working.

We lose deals when the customer sees our solution as a cost rather than as a business improvement initiative.

We also lose deals when we are unable to reach the right decision makers early enough in the sales process. Automation and digitalization require alignment between operational teams and executive leadership. If we stay too low in the organization, resistance to change can slow adoption; if we only engage at the executive level, operational concerns can become a barrier later.

Previous experience and track record are also major factors. Both Oil & Gas and Mining are conservative industries where customers frequently require proven experience, references and successful field deployments before adopting a new technology or approving a new supplier. For a relatively new technology or a new market entrant, this can create a significant barrier: customers want evidence of previous success before becoming the first adopter.

Timing is another challenge. Customers may recognize the value but postpone decisions due to budget cycles, competing priorities, capital constraints or uncertainty around future activity.

Ultimately, we lose deals when we cannot simultaneously prove the technology, demonstrate the ROI, reduce the perceived risk of change, show a credible track record, and align operational and executive stakeholders.

Precio: “the perception of our value can be misunderstood at first… so it feels worth the price we're asking”.

CEO firma (a veces inicia y a veces bloquea)
· The operations manager uses the tools
· Engineering Manager empuja o bloquea “sometimes without us even knowing”
· Engineers start the search.

“Our customers don't fully understand the value”
· “The customer can't afford the solution, even with the savings”.

ESC/Vulcan: “drastically reduce our idle time… especially in the colder months”
· O&G: “We're burning fuel for nothing while we wait on the wellhead”
· Gen: “Multiple generator types, difficulty synchronizing the island”.

In-house engineering
· Controladores nativos OEM
· "No movement": customers that have not quantified their idle ratio.

"Hard to say": customers ask things that are already answered, so the message is not clear or is not read; reorder by importance.

Solid figures for Power Generation (like the ESC simulator)
· Video 3D
animated diagram, one per type of audience
· “A few big brand name customers that we can display”.

“EKU is the automation enabler, minimizing downtime and easing the operators' workload” – all industry.

Human risk from equipment failure or operator error
· Cost risk (maintenance, efficiency)
· Redundancy and data logging.

“Money, time, lowering the risk/human risk”.

Power Gen: los OEM (“we don't have to deal directly with the end-customer”)
· Mining: integrators
· Oil and gas: field operators.

Deep Sea Electronics
· In-house engineering (temporal)
· Engine makers with proprietary controls and lock-in.

When they understand the flexibility and freedom we offer
· When they understand the savings.

Wants to see numbers that back the promised savings (for example, lower maintenance).

“The only OEM-agnostic control platform”.

“That the product is ready to use anytime. No energy wasted in idle time”.

1) “Site management doesn’t have the time or staff” → mostrar que no crea trabajo extra, EKU instala. 2) “We already have a generator rental company
power connection" → ask about connected load and bottlenecks with cranes.

Starts: in-house mechanical engineers
project management (they justify outage and diesel costs)
· Blocks: electrical planning and safety (VDE/DIN EN IEC 61439-4)
· Frena: Compras (contratos marco)
· Aprueba: Compras central
Management.

“Customers want to buy from an OEM, not from an engineering firm” (no hay producto terminado en serie)
· “If we can't explain the ROI”
· “If the customer doesn't have the numbers to quantify it”.

“We cannot relocate construction sites because we cannot get an electrical connection”
· “We are no longer allowed to operate generators in city centers”
· “Tower cranes are responsible for all peaks”
· “We don't know how much diesel… until the bill arrives”
· “Every crane speaks a different language”.

"Do nothing" (manual management) is the most common on small sites
· Makers of site power distribution: Merz/iBSV, Jaeger/SIROX, Walther Werke, Liebherr
· HELIOS: Hartl, Mobil Hybrid, Faber, Endress, IonHub Solardrive.

“Is there a real reference project in our region that we can visit? Who can I call?”
· “How exactly does compatibility work with our existing cranes and power units?”

“Presence of more than one reference”
· Two or three key customers open to technology.

“An engineering services provider that offers energy and power management systems”
· turns a "hodgepodge" of generators, batteries, renewables and engine-maker controls into one controllable system
· “EKU is a startup”.

Unnecessary idling that nobody notices
· No central view when equipment comes from several brands
· Load peaks and bottlenecks (cranes)
· No data for sustainability and cost reports.

Mining: idle reduction and diesel savings per haul truck (figures pending sign-off)
· Construction: fewer engine hours → longer life, less maintenance (figures being compiled)
· Less dependence on the grid and on generators.

Large international construction groups with mixed fleets
· Rental companies with 500+ units
· Role: construction or fleet management with a budget.

Makers of site power distribution (Merz, Jaeger/SIROX, Walther Werke, Liebherr)
· Engine-maker controls (cranes, gensets)
· Software/SCADA puro o in-house de grandes constructoras
· “nothing at all”.

Independent of the manufacturer, retrofit without replacing everything
· Hardware + software + integration from one source
· “Startup spirit and entrepreneurial boldness: very fast… can adapt immediately”.

LIKE: documented return outside construction, subscription model, capex avoidance
· CONCERN: EKU is small next to the large rental-power companies
grandes OEM
· CONCERN: no validated cases in construction.

The gap between engine-maker software (one brand only) and pure IT/SCADA platforms (no hardware, no commissioning)
· In construction: idle + load management (cranes) + visibility across brands on one site.

“We make sure that whatever is on your construction site is actually ready for use, regardless of the brand.” El jefe de obra sabe en tiempo real qué está listo y cuánto consume, sin ir a mirar.