How TripleDart Taught Domotz's CRM to Speak Product
86
Product and billing properties are live across contacts and companies
About Domotz
Domotz is a network monitoring platform for IT teams, managed service providers, and AV integrators. It gives them one dashboard for the health of every network, device, and connected system they oversee.
Domotz grows through free trials. A technician signs up, deploys a monitoring collector on a live network, and either activates or churns out quietly.
Domotz came to TripleDart with a strong product and a CRM that had never been taught to see it.
The Challenge: A CRM That Couldn't See the Product
In a product-led business, the moments that decide revenue happen inside the product. At Domotz, almost none of that reached the teams responsible for growth.
Picture a grocery store where the staff steers someone looking for hiking boots to the kids' toy aisle. That's what an unintegrated CRM does: the prospect wants something specific inside the product, and marketing, working blind, keeps pushing offers that have nothing to do with it.
By the time we stepped in, Domotz ran on two systems that never talked to each other. One held the truth about what customers did. The other was where every revenue decision got made.
What the Product Knew That HubSpot Didn't
HubSpot held names, emails, and lead source, nothing more. The product knew sign-ups, trial starts, collector deployments, and usage trends, and none of it reached the CRM.
Marketing Optimizing Against the Wrong Signal
Campaigns were tuned to form fills and email opens, the only signals HubSpot could see. The one signal that mattered, real product activation, sat untouched.
Sales Treating Every Trial the Same
A serious buyer running Domotz on a live network looked identical, on paper, to someone who signed up and vanished. Reps spent their time guessing which trials were worth a call.
Customer Success Finding Out Too Late
With no usage or subscription signal in view, CS often learned an account was at risk only after it churned, the one moment nothing can be done.
Domotz already had the data. The problem was where it lived: the most valuable signal in the business sat in the one system where the fewest revenue decisions get made.
What We Did: Teaching HubSpot to Speak Product
Services: RevOps and CRM data architecture.
A CRM and a product speak different languages. HubSpot thinks in contacts, companies, and deals; the product thinks in accounts, collectors, and trials. We built a data model that translates between the two, in four moves.
Move 1: Establishing Identity
Two identity keys anchor every other property in the model:
- domotz_account_id maps to the Company record, the commercial account
- domotz_user_id maps to the Contact record, the individual person
Get these wrong and the CRM fills with duplicates. Get them right and product and CRM stay in lockstep automatically.
Move 2: Mirroring the Product's Structure
We mirrored the product's own hierarchy, an account contains users, into one clean rule:
- Contact properties cover what a person does: source, UTM, trial status, collector activations
- Company properties cover what the account is: subscription status, billing type, MRR/ARR, device health
A rep sees a person's trial story. A CS manager sees the account's revenue and health. Same data, placed where each team needs it.
Move 3: Typing Every Property on Purpose
Each property's type was chosen on purpose, not defaulted to plain text:
- Number fields on devices and collectors enable thresholds, so 25+ managed devices flags a serious account
- Datetime fields on trial and payment dates trigger time-based automation, like a rep alert three days before a trial ends
- Enum fields on status and ICP segment power clean segmentation and saved views
- Boolean fields on feature adoption (configuration management, documentation, script creation, ticketing) turn depth of use into a one-click filter
CS can find customers who've never touched a core feature in seconds. Sales can spot expansion candidates just as fast.
Move 4: Deriving the Lifecycle from Events
The lifecycle stage is computed from product truth, not tagged by a human:
- Lead: the moment someone signs up
- Trial: the moment a trial starts
- Trial Activated: the moment the first collector deploys
- Product Qualified: the moment usage clears the bar
- Customer: the moment Stripe confirms payment
The lifecycle stops being an opinion someone updates by hand. It becomes something the system measures on its own.
Unifying Three Streams into One Record
- Domotz product feeds identity, usage, activation, and feature adoption
- Stripe feeds subscription status, billing type, and MRR/ARR
- Marketing UTM data feeds original source and channel attribution
By the end, 86 Domotz properties were live across contacts and companies, each tracked as created-in-production versus already-existing, so the rollout stayed clean and auditable.
Results
Open a Domotz company record today, and live fields show exactly what the account is doing.
This is one real record, 17 of the 86 properties populated:
Conclusion
TripleDart's work with Domotz didn't stop at connecting two systems. It gave marketing, sales, and customer success one live picture of what a trial account is doing, computed from product truth instead of guesswork.
The lifecycle updates itself as usage climbs, with no one touching a dropdown. That's the kind of system a product-led business can scale without adding headcount just to keep the data honest.