Building the CRM and automation operating system behind an AI property video platform

The challenge

DAIN's technology dramatically cut the time and cost of producing a professional property video. But scaling the product past a handful of early customers required more than the video-generation technology itself — inbound leads, qualification, demos, trials, onboarding, per-property production tracking, delivery, repeat listings, brokerage expansion and reporting all needed a home. Without a central system, that spreads across forms, spreadsheets, email and whatever chat tool happened to be open, and it breaks down exactly at the volume where the product's speed should be an advantage.

aibrevo designed GoHighLevel as that central layer — not a CRM bolted onto the product afterward, but the connective tissue between every customer- and operations-facing step:First Lead → Qualification → Demo → Customer → Property Submission → Video Production → Delivery → Repeat Listing → Expansion.

The structural difficulty is that DAIN's business has two different units of work living side by side. The sales unit is a person or a brokerage: a lead that gets qualified, demoed and won. The operations unit is a property: a listing that gets submitted, processed, reviewed, revised and delivered. Most CRM templates only model the first. A product priced and delivered per listing needs both, and needs them linked, so that "how is this customer doing" and "where is this video" are answerable from the same system without one contaminating the other.

There's also a speed problem specific to this product. When production time drops from days to minutes, the bottleneck moves to everything around production: how fast a new customer is onboarded, how quickly a submission's missing assets are caught, how soon a delivered video prompts the next listing conversation. The build treats those surrounding steps as the constraint to be engineered, since the video itself is no longer the slow part.

The architecture: four connected layers

Eight pipelines, one customer lifecycle

A property isn't a customer, and a customer isn't a lead — treating all three as one flat pipeline is where most GoHighLevel builds for a product like this go wrong. The failure mode is predictable: the moment a customer submits a second property, the single status field on their contact record has to describe two different production states at once, and one of them is necessarily wrong. Reporting on it is worse — "how many videos are in quality review right now" becomes unanswerable, because the only unit the CRM can count is a contact.

DAIN's build separates the concerns instead. Six pipelines cover the core lifecycle, and two supporting pipelines (referral growth and revision handling) keep side-flows from polluting the main ones. Each pipeline has explicit entry and exit criteria, so a record only moves forward when the data the next stage depends on actually exists:

Automation that removes the manual handoff

Every stage transition above is backed by an automation, not a person remembering to move a card. The design rule is that an automation should either move a record forward, or surface exactly why it can't — never fail silently. Each workflow therefore has a defined trigger, a defined set of preconditions, and a defined fallback (an owner notification or a queued manual task) when those preconditions aren't met. A few of the load-bearing ones:

The data model underneath it

Eight separate object types, cleanly related, instead of treating every interaction as one flat contact record:

The relationships matter as much as the objects. A Contact belongs to a Company or Brokerage; a Company can have many Contacts and many Opportunities; an Opportunity that reaches Customer Won gives rise to an ongoing account, which in turn owns many Property records; and every Property owns exactly one active Video project at a time, with revision history kept underneath it. Because the property carries its own status, a customer's overall standing (active, high-volume, at-risk) is derived from what their properties are doing rather than manually maintained on the contact — which removes an entire class of "the record says one thing and reality says another" errors.

Where GoHighLevel's native objects didn't map cleanly onto a property-level concept, the build used custom objects and associations rather than stuffing property details into custom fields on the contact. Custom fields on a contact scale badly for one-to-many data: the second property either overwrites the first or forces a numbered-field workaround (Property 1 Address, Property 2 Address) that no automation or report can reason about cleanly. A proper related object avoids that at the cost of a little more upfront design.

Integrations: keeping CRM status and production status in sync

The CRM is only useful to operations if what it says about a property matches what is actually happening in the video-production pipeline. The integration layer exists to make drift between the two structurally hard, not just unlikely:

Every integration writes back to a single source of truth on the property record, with a timestamped activity entry, so when something does go wrong an operator can trace it — which webhook fired, what payload it carried, and what response came back — instead of reconstructing it from memory.

Tagging and lead scoring built for this business

A generic lead score (opened an email, clicked a link) tells you very little about whether a real-estate agent is likely to become a repeat video customer. The scoring model here is built on the attributes that actually predict fit for a product sold per listing: the agent's market, whether they work solo, on a team or in a brokerage, their approximate listing volume, and how they currently produce listing media. An agent handling a steady flow of listings and paying a videographer for each one has a concrete, quantifiable reason to switch; an agent with one listing a year does not, and shouldn't consume the same sales attention.

Tags are organized in four families rather than accumulating freely: source (where the contact came from), customer type (solo agent, team, brokerage), lifecycle stage, and priority. Each tag family is owned by specific automations, which is what stops tag sprawl — a tag exists because a workflow reads it or a report filters on it, not because someone thought it might be useful later. Tags that drive nothing get removed during periodic cleanups, which keeps the tag list small enough for the team to actually trust.

Reporting leadership can act on

Reporting is designed backwards from the decisions leadership actually makes, not forwards from the fields that happen to exist. Four views cover it. A sales view shows pipeline coverage, stage conversion and where deals are stalling. A customer view shows account health, submission cadence and expansion candidates. A property-operations view shows how many properties sit at each production stage right now and which are approaching their turnaround window. A growth view shows lead sources, referral contribution and reactivation from the lost-deal nurture tracks.

Because the data model separates properties from customers, the operations view can count videos directly — something that isn't possible when a contact record is the only unit. That is the difference between a dashboard that describes CRM activity and one that describes the business.

What this architecture actually solved

The product-impact figures above come from DAIN itself and describe the video technology, not the CRM. What the CRM and automation layer addresses is the set of operational problems that determine whether those product capabilities turn into a business that scales. Each one maps to a specific piece of the build.

Enquiry capture. DAIN reports 3.2× more enquiries on listings with video. Extra enquiries only matter if they are captured and answered. Lead capture, scoring and first-response automation make sure demand generated by the product lands in a queue with an owner and a next action, instead of adding to an inbox no one has time to triage.

Throughput. DAIN reports an agent can cover 14 listings a week, and 41,000 tours were generated in year one. At that kind of volume, manual coordination stops scaling long before the technology does. Per-property tracking, SLA watches and asset checks at submission are what let production volume grow without operations headcount growing in lockstep with it.

Unit economics. With compute cost per video under $12, every avoidable rework cycle and every stalled job cuts directly into margin. Catching missing assets at submission, and tracking revisions with reason codes, addresses the two main sources of wasted production effort: starting a job that can't finish, and repeating one that should have been right the first time.

Speed to launch. The platform itself was built in 7 weeks, so the operating system around it had to be designed to be adopted quickly and extended later, not perfected up front. That's why the pipelines are modular and the data model keeps concerns separate: adding a new customer segment or a new production stage is a configuration change, not a rebuild.

What we'd do differently, and what to watch for

No build of this size gets every decision right on the first pass, and the useful part of a case study is what the team would adjust. A few honest lessons from the design.

• Model the property object first. The single biggest structural decision was separating properties from customers. Teams that add it later, after a year of data lives on the contact record, face a painful migration. Starting there costs a little extra design time and saves a rebuild.
• Keep the first version of scoring simple. A scoring model built on a handful of fit attributes is easier to validate against actual conversions than one with dozens of weighted signals. Add signals only once there's enough closed-won data to justify them.
• Treat loss reasons as required data from day one. Reactivation logic is only as good as the reasons captured at loss. Adding required loss reasons after hundreds of unlabeled lost deals already exist means that history can't be routed into the right nurture tracks.
• Watch automation overlap. With this many workflows reading the same tags and stages, two automations can trigger on the same event and send conflicting messages. Every workflow needs a documented owner and a defined suppression rule, and the workflow list needs periodic review as the system grows.
• Plan for the brokerage motion early. Enterprise deals introduce procurement, security review and multi-stakeholder approval that individual-agent sales never touch. Keeping that pipeline separate from the start avoids having to retrofit stages into a pipeline designed for a five-minute purchase decision.
• Document the integration contract. The webhook payloads and status values between the CRM and the production pipeline are effectively an API. Writing them down, and versioning changes, prevents a silent mismatch when either side evolves.