# Ownership and property leads

{/* AUTO-SYNCED SOURCE: this page lives in apps/app/src/modules/db-leads/docs/ and is mirrored into the docs app by `bun sync:module-docs`. Edit it in the module, not in apps/docs. */}

<Lead>
Before an acquisition call you do not want to know where somebody lives, you want to know **what they own**. The **Ownership** section of the contact panel answers exactly that: which properties belong to this person, how big they are, where they are, and how we know.
</Lead>

## Why your own listings are not shown here

DB-Leads works the period **before** the mandate. The property in question therefore exists in no record of your office: a listing is created when the mandate is signed, not while you are chasing it.

That is exactly where the previous version of this section failed. It tried to attach an existing listing to every contact, and whenever the owner relation in onOffice was not maintained, it fell back to matching the **address**. That produced two kinds of nonsense:

<DefinitionList>
  <DefItem term="Somebody else's property on the wrong contact">A buyer who happens to live on a street where you are marketing showed up as a possible owner of that listing. It belongs to somebody else. Building a call on that means offering to sell a stranger's flat.</DefItem>
  <DefItem term="The right property was missing">The property the call is actually about exists in no record. It sits in an email from 2023.</DefItem>
</DefinitionList>

That email is what the qualification reads anyway. Since August 2026 it also reports what that text says about properties.

## What a property lead is

It is **not a link to a listing record**, it is the facts themselves. It can carry:

<DefinitionList>
  <DefItem term="Address">Street, house number, postal code, city. As much of it as is evidenced.</DefItem>
  <DefItem term="Property type">Free text, worded the way it was said: “semi-detached house”, “3-room flat”, “plot of land”.</DefItem>
  <DefItem term="Sizes">Rooms, living area, plot area, year built.</DefItem>
  <DefItem term="Relationship">How the person relates to the property (see below).</DefItem>
  <DefItem term="Evidence">The sentence it all comes from, with its date. No evidence, no entry.</DefItem>
</DefinitionList>

The image on the card is a **placeholder**, and that is not a gap: there is no photo of this property because it exists in no record.

## The six relationships

<DefinitionList>
  <DefItem term="Owner">Belongs to this person alone.</DefItem>
  <DefItem term="Co-owner">Shared ownership: couple, community of heirs, fractional ownership.</DefItem>
  <DefItem term="Heir">Inherited, or an inheritance has been announced.</DefItem>
  <DefItem term="Let out">Belongs to the person and is rented out (investment).</DefItem>
  <DefItem term="Previously sold">Already sold, often through your office. Satisfaction back then is a reason to call today.</DefItem>
  <DefItem term="Relationship unclear">The property is evidenced, the relationship does not follow from the evidence.</DefItem>
</DefinitionList>

<Callout tone="note" title="“Unclear” is a result, not a failure">
A guessed relationship would be a statement about a real person's property. If the analysis cannot tell, it says so instead of picking.
</Callout>

## Where entries come from

<Steps>
  <Step title="From the analysis">
    On every qualification the AI reads the correspondence and records what it finds about properties. Those cards carry the **From the analysis** chip: unverified, derived from text, evidence below.
  </Step>
  <Step title="Added by you">
    What you learn on the phone you record via **Add property**. That is the moment the information is most valuable and most fleeting. Without this path it ends up in a note and is unfindable at the next call a year later.
  </Step>
  <Step title="Confirmed by you">
    If an AI entry is right, press the check. It loses the chip and stays permanently.
  </Step>
</Steps>

## What a new scan overwrites, and what it does not

This is the rule worth knowing:

<DefinitionList>
  <DefItem term="Entries from the analysis">Are replaced on **every** new qualification. A briefing is the snapshot of one run, and the next run reads the same history again.</DefItem>
  <DefItem term="Entries you added or confirmed">Stay. Always. Through every further scan.</DefItem>
</DefinitionList>

That is why any edit to an AI entry changes its origin: whoever touches it has checked it. Without that switch your correction would vanish without trace on the next weekly run, and you would see the old house number again and take it for your own input.

<Tip title="The same address is never duplicated">
If the analysis finds a property you already confirmed, no second card appears. “Musterstr. 3” and “Musterstrasse 3” count as the same address.
</Tip>

## When two people edit the same property at once

The form writes all details at once, and it is filled with the state you saw when you opened it. If somebody else edited the property in the meantime, saving would also overwrite the fields you never touched.

That is why the tool asks instead of saving in silence. You can still apply your version, or close the window and look at the other state.

## The empty state

If nothing is there you see **“No properties found.”** plus the way to add one. The section deliberately does not disappear: the property nobody knows about yet is the reason for the call, and right after the call is the only moment anybody records it. A section you have never seen is a section you will not look for.

## “On file”: the exception

If onOffice explicitly lists the contact as owner or buyer of a property, that property appears under its own heading **On file**, with cover image and a link into the listing page. That is a fact from the CRM and the one case where a record really exists.

It sits **below** the leads, because it is almost never what matters for the next call: a property that is on file is usually long sold or currently being marketed, so it is no acquisition opportunity.

## Why there is no "create listing"

The obvious move would be to turn a lead into a real listing under **Properties**. That would be a mistake. Your property inventory is the list of what you hold a mandate for, and it feeds the exposé generator, the website, statistics, and the onOffice sync. A placeholder built on a guess would be counted there as a mandate and, in the worst case, published.

So a lead stays a lead until there is a mandate. Then you create the listing in onOffice, as you do today, and it arrives through the [sync](/tools/db-leads/onoffice-import).

## Who can do what

<PermissionTable roles="tenant_owner,tenant_admin,employee" caption="Property leads">
  <Permission action="db-leads.read" label="See the section" description="Read a contact's property leads." allow="yes,yes,yes" />
  <Permission action="db-leads.update" label="Maintain entries" description="Add, edit, confirm and remove." allow="yes,yes,yes" />
</PermissionTable>

## Data protection

Property leads are personal data: they describe a specific person's property. They live in your workspace under the same tenant isolation as all other contact data, and they are **deleted with the contact**. Delete a contact and no addresses are left behind.

## Further reading

<CardGrid>
  <Card title="Database scan" href="/tools/db-leads/datenbank-scan">Where the entries come from.</Card>
  <Card title="Customer view" href="/tools/db-leads/kundenansicht">The panel the section lives in.</Card>
  <Card title="Durcharbeiten" href="/tools/db-leads/durchgang">The mode where you fill it minute by minute.</Card>
</CardGrid>