A developer, a hotel operator and a distributor can each send an enquiry containing the same phrase, and each will expect a different quote. The factory that replies with a product list to all three loses at least two of them.
Three buyers, three definitions
A property developer is buying a deliverable. They need a system that arrives on site, gets commissioned by someone, and hands over with documentation the building operator can use. Their unit of purchase is a building, not a box.
A hotel operator is buying a room controller with a back end. Guest room scenes, energy management, a front desk view, and a maintenance path when a room loses control. Their unit of purchase is a room type multiplied by a room count.
A distributor is buying a component kit. Gateways, sensors, panels, a protocol that their installers already know, and a price list they can resell. Their unit of purchase is a pallet.
The product overlap between these three is substantial. The commercial structure is not. A quotation that ignores the structure misses even when the hardware is right.
Why the mismatch is expensive on both sides
The factory quotes a component price. The developer reads it as a delivered price and later discovers commissioning, cabling, gateway placement and programming are not included. The gap appears at the worst moment, during handover, and it is usually absorbed by whoever has less leverage.
The opposite failure is equally common. A factory prices a full turnkey scope for a distributor who wanted a kit, and the number is three times what the distributor can resell. The enquiry closes with no order and no explanation.
The delivery boundary is the first thing to agree
Before price, agree what crosses the boundary. Four blocks are enough: hardware, software configuration, installation labour, and ongoing support. For each block, state who performs it and who pays for it.
Most disputes in this category are boundary disputes, not quality disputes. A gateway that was specified but never powered is nobody's fault and everybody's problem.
Written as four lines, the boundary takes ten minutes to settle and removes most of the risk from the project. Left implicit, it resurfaces as a change order.
What the developer actually needs to see
A developer's technical team will ask for three things that a component supplier does not normally produce. A device schedule per apartment type, a network topology drawing showing gateway placement and coverage, and a commissioning checklist with acceptance criteria. Without these, the integrator on site invents their own, and the result is inconsistent from floor to floor.
Producing them is not difficult for a factory that has delivered projects. It is close to impossible for a factory that has only shipped boxes, which is why the request is a useful filter.
What the hotel operator actually needs
Two items dominate. First, room-level fallback: when the network is down, the guest must still be able to turn the lights on and off at the wall. This is a hardware requirement, not a software one, and it eliminates a class of designs immediately.
Second, an audit trail. Who changed a scene, when, and which rooms are currently offline. Operators do not ask for this at enquiry and always ask for it after the first month of operation.
What the distributor actually needs
Predictable documentation, a stable part number scheme, and a spares policy. A distributor's margin depends on repeat installs with the same kit, so a supplier who changes the module between batches destroys that margin quietly.
Ask how long a given model will remain orderable and what notice is given before discontinuation. The answer separates a supplier who plans product lifecycles from one who sells what is in stock.
A short framework that fits all three
Collect five facts before quoting: who installs, who commissions, how many rooms or units, which market's regulations apply, and whether the buyer resells. Those five questions route the enquiry to the right commercial structure within one exchange.
The hardware range that sits behind these three structures, including the gateway capacity and the room controller options, is described on the home automation system manufacturing page. Reading it before defining the delivery boundary saves the round trip that usually happens between the first quote and the second. Projects that have already fixed a boundary can send the scope through the contact page for a quotation structured against it.
Top comments (0)