The Point Where Hardware Becomes a Business System

A connected product starts as a device and an app. Then the first business customer buys 400 units and asks whether consumable reorders can post to their purchasing system, whether alerts can open tickets in their service desk, and whether usage can be invoiced monthly. Your product has become a node in someone's enterprise software estate.

The same happens internally. Once you ship at volume, serial numbers, warranty status, and RMA history have to live in the same systems as your invoices and customer records, or support spends its day reconciling spreadsheets.

What Actually Moves Between the Systems

Be specific before anyone writes code. Integration projects fail because "connect the product to the ERP" is not a requirement.

  • Device to business, on an event. Consumable low or depleted, triggering a replenishment order. Fault detected, opening a service ticket. Installation completed, activating a warranty start date. Threshold exceeded, notifying an account manager.
  • Device to business, aggregated. Usage totals per device per billing period for consumption-based invoicing. Runtime hours for maintenance scheduling. Fleet health rollups for quarterly reviews.
  • Business to device. Entitlement and feature flags derived from the customer's subscription state, service contract expiry, and configuration profiles pushed per customer or per site.
  • Shared master data. The customer record, the site or location, the asset with its serial number, and the link between them. This is the hardest part and the part teams skip: without an agreed identity model, the same customer exists three times with three different keys.

Write each flow as a sentence with a trigger, a payload, a destination, and a failure behavior. Ten sentences beat a fifty-page specification, and they immediately expose the flows nobody has thought through.

Architecture: Never Connect the Device to the ERP

The single most consequential decision is to keep a layer between the fleet and the business systems. Devices talk to your IoT backend; your backend talks to the ERP and CRM. Every reason to do it this way is a reason not to shortcut it.

Firmware lifecycles run for years and enterprise software changes constantly. A device that speaks a vendor's API directly is stranded when that API is versioned, and you cannot reflash 20,000 units because a customer migrated systems. Devices are also unreliable narrators: they reconnect, retry, and resend, and an ERP receiving duplicate order events creates duplicate purchase orders, so idempotency and ordering guarantees belong in your backend. Third, an ERP token embedded in firmware is extractable, and one compromised unit exposes a customer's business systems.

Practically, the pattern is a queue and an integration service. Device events land in your platform through MQTT or HTTP, get normalized and validated, then flow into a durable queue that an integration worker drains toward the target system with retries and a dead-letter path. The backend that does this must be able to absorb bursts without dropping messages, which is the design work described in scaling an IoT backend. Expose your own stable, versioned interface to the outside world rather than one shaped by whichever ERP you integrated first, along the lines of opening an API for your hardware product.

What Costs More Than You Expect

Their system, not yours. Every enterprise ERP deployment is customized: different field names, mandatory fields, approval workflows, and sandbox policies. A connector that took three weeks for the first customer takes another three for the second. Budget per-customer work, or productize it by supporting a few standard platforms plus a generic webhook.

Access and scheduling. You will wait for the customer's IT department. Sandbox provisioning, security review, VPN or IP allowlisting, and change windows routinely add four to twelve weeks that have nothing to do with your engineering.

Master data reconciliation. Mapping your device and customer identities onto theirs is most of the real work: serial formats differ, sites are named inconsistently, and someone must decide which system is authoritative.

Ongoing operation. Integrations break silently. You need monitoring on message age and queue depth, alerting on dead-letter growth, and a person who owns it. Realistic annual maintenance for a couple of live integrations is $15,000 to $50,000, on top of the general load described in annual software maintenance cost.

Licensing. Some enterprise platforms charge per API call, per integration user, or per external connection. Find out before you design a chatty integration; a per-event architecture can turn into a five-figure annual bill on the customer's side and kill the deal late.

Designing It Right From the Start

You do not have to build the integration early. You do have to avoid making it impossible.

  • Give every device a permanent, globally unique identity assigned during manufacturing, tied to a cryptographic credential, and recorded at the point of production. Doing this properly through secure device provisioning is what makes an asset record trustworthy years later.
  • Model customers, sites, and assets separately in your backend from day one. Retrofitting a hierarchy onto a flat user-to-device table is a migration nobody enjoys.
  • Emit business-meaningful events, not raw telemetry. An ERP does not want a pressure reading every 10 seconds; it wants "cartridge depleted on asset 4471." Do the interpretation in your platform.
  • Version everything - device payload schemas, internal events, and your outbound API - so a firmware fleet in the field and a customer's connector can move at different speeds.
  • Decide data residency and retention early, because enterprise buyers will ask, and the answers are constrained by the rules in privacy compliance for connected product data.
  • Build the read-only portal first. Most customers' initial request is visibility, not automation, and a B2B customer portal satisfies it in a fraction of the time while teaching you which flows they actually use.

Sequence the Work

A sane order: internal first, then read-only external, then write-back. Connect your own CRM and accounting to the fleet so support can see a device's history next to its invoice. Then give customers a portal and exports. Then, for the customers whose contracts justify it, build the ERP write-back. Doing it in reverse - promising a deep ERP integration during a sales cycle before your own asset model exists - is how a hardware team loses a quarter.

Integration also unlocks commercial models the product could not otherwise support, since usage-based billing and hardware as a service only work when consumption data reaches an invoicing system reliably enough to bill on. That is a good reason to treat the integration layer as product, with an owner and a roadmap, rather than as a series of one-off connectors.

Plan the Platform, Not Just the Device

Projects House builds connected products where the device, the backend, and the business integration are designed as one system, so the first enterprise customer does not force a rewrite. Tell us about your product and the systems it will have to talk to through our contact form.