Who really owns your leads: the two columns the contract forgets

The contract said the developer owned their data. Everyone on the team had checked that line before signing, and it read exactly the way you would want it to. So when they decided to move off their sales platform onto a new CRM a year later, nobody expected trouble. They requested the export, got a file back inside a day, and opened a clean list of names, emails, and phone numbers.

Then someone asked which of these people had actually agreed to be emailed, and where each of them had come from. Neither answer was in the file. The consent state had not travelled with the contacts, and neither had the source trail. The developer owned every row in that spreadsheet and could lawfully act on almost none of them.

That gap is the whole subject of this piece. Having an export is a weaker guarantee than being able to leave clean, and the difference does not appear on any vendor's marketing page. It surfaces on the day you walk out the door. Ownership is settled long before then, in two places most buyers never inspect: the controller line in the contract, and what your data looks like when it comes back out.

The seam nobody inspects

Start from the row itself. A lead in your CRM is a contact record with a lot hanging off it: an email, maybe a phone number, a consent state that says what you are allowed to do with those, and a history that says where the person came from and what they turned into. The ownership language in a contract covers the record. It says almost nothing about the two attributes that decide whether that record is still usable once it moves.

Own the row, lose those, and what you are left holding is a name. That is the seam this post is about, and everything below works through one column or the other.

Before the features, one line in the contract

There is a question worth settling before you watch a single feature demo: in this arrangement, who is the data controller. Under GDPR a controller is whoever "determines the purposes and means of the processing of personal data," and a processor is whoever "processes personal data on behalf of the controller" (EUR-Lex, GDPR Art. 4). If you are a developer collecting leads for your own sales, you decide why the data exists. That makes you the controller almost every time, and it makes your SaaS vendor the processor.

This matters because the controller carries the liability, and you cannot sign that liability over to the processor along with the hosting. The real terms of the relationship live in the data processing agreement that GDPR Art. 28 requires between the two (GDPR Art. 28). That document, and the exit clause inside it, is where the ownership promise either becomes true or stays decorative. Read it before the demo.

Column one: consent that can't travel

Consent is the column that fails quietly, because nothing looks broken until an auditor or an unsubscribe complaint arrives. GDPR does not treat consent as a single yes. It has to be specific to a purpose, and it has to be provable. Recital 32 is explicit that "silence, pre-ticked boxes or inactivity" do not constitute consent (GDPR Recital 32), and the Court of Justice put teeth on that in the Planet49 case, holding that only active behaviour by the user can signify consent (EUR-Lex, Case C-673/17).

So an opt-in is a record of a specific person actively agreeing to a specific use, at a specific time, not just a stored checkbox value. If your export hands you back the contacts but not that per-purpose consent state, you have inherited a list you have no standing record of permission to email. The row survived. The permission did not. How you design the form that captured the consent in the first place is its own craft, and we worked through it in property lead forms that convert. The point here is about the exit: whatever consent you collected has to come back out in a form you can still stand behind.

Column two: attribution that breaks at the vendor seam

The second column breaks in a more structural way, and it is the one most relevant to how these systems actually get assembled. Picture the common setup: one vendor runs the 3D microsite and the lead-capture experience, a different vendor runs the CRM where deals are worked. A buyer fills in a form on the microsite. Weeks later the deal closes in the CRM. Ask which unit that buyer first looked at, and which campaign brought them in, and you find that no single system ever saw both ends. The capture event lived in one platform, the deal outcome in another, and the source → deal → unit trail snapped at the join between them.

Nothing here is anyone's fault. It is a property of the architecture. When capture and outcome sit in two databases owned by two vendors, the connection between them is the thing that never gets owned, and attribution is exactly that connection. You feel it later, when you are trying to justify a marketing budget and cannot prove which spend produced which reservation, or when you switch systems and a lineage that was already thin gets thinner. This is record-level attribution, a lead tied to a deal tied to a unit. It is nothing as elaborate as multi-touch channel modelling, and it does not need to be. We traced the same thread from the buyer's side in interactive floor plans and the sales cycle.

"But we can always export"

Here is where a lot of buyers reassure themselves with the wrong right. GDPR does grant a right to data portability, and it even specifies a "structured, commonly used and machine-readable format" (GDPR Art. 20). But read who it belongs to. Art. 20 is the data subject's right to a copy of their own personal data. It is not the developer's commercial right to bulk-export the entire lead database when a contract ends.

Those are different things that happen to sound identical, and conflating them is how a buyer talks themselves out of checking the clause that actually governs their exit. The GDPR export right is about individuals, so it answers the wrong question. The one to settle before signing is what your own commercial export clause says, and what format it hands you.

One honest caveat on jurisdiction

Everything legal above is EU and UK law. That is not a small caveat, and pretending GDPR is universal would be the generic move. Vinode's own project list makes the point on its own: Kozielska Park and Malinowskiego sit in Poland, squarely under GDPR, while Safa Al Fursan in Riyadh and Más Colonia in Uruguay do not. The ownership logic in this piece, control your record and keep your two columns, holds anywhere. The specific mechanisms, Art. 4, Art. 20, and Art. 28, are European. If you operate outside that territory, keep the logic and swap the statute for your local one.

What one owned panel actually changes

The split-vendor seam in the second column has an architectural answer, and it is not another integration bolted between two systems. Vinode's back panel is CRM and CMS in one, and it can run standalone or alongside an existing system. The lead forms are built in the platform and submissions land straight in the CRM; the contact, its source field, and the deal moving through its pipeline stages all live in that same record, alongside the behavioural trail of which units the contact viewed and for how long. Because the form submission and the eventual deal sit in one place, the trail that snapped at the vendor join has nothing to snap at. We made the broader version of this case in launching a microsite in two weeks, and the behavioural side in your unit selector is already a lead form.

On compliance, the same panel ships purpose-based consent management, GDPR anonymisation and erasure, and asynchronous data export as named features. There is one honest boundary, and it is the discipline this whole post argues for: I can tell you those features exist, not that a given export hands back your per-purpose consent and full attribution history in a machine-readable file. That is the thing to confirm of us, and of anyone else, before you sign.

Five questions to ask before you sign

All of this collapses into a short checklist. Run it against your current vendor at renewal, and against any new one before you commit. None of the five is hard to ask, and the quality of the answers tells you most of what you need.

1. Who is named data controller in the contract, us or the vendor?
2. Does the export include per-purpose consent status?
3. Does the export include source and attribution history?
4. What format is the export, and is it genuinely machine-readable?
5. What do the DPA and the exit clause actually say about leaving?

A vendor that answers all five cleanly is one you could leave, which is exactly what makes it safe to stay. If the answers get vague around questions three and five, that is usually where the lock-in sits.

Ownership only bites at the exit, and by then you cannot fix it. Everything works while you stay, because you are still on the system that recorded the consent and holds the history. You find out what you actually own the day you try to take it somewhere else. So settle it now, with the one question that counts: if you had to leave this vendor next month, what exactly could you take, and could you still use it? That answer is your real data-ownership position, and today is a cheaper time to learn it than a migration is.