# Analyse Ist-Zustand: Verkaufsdoku-Prozess GVS

*Befunde aus der Analyse von Google Drive, Copper-CRM und der bestehenden Vorlage.
Grundlage für die Automatisierung. Stand Juni 2026.*

> Zweck dieses Dokuments: vollständiger Überblick über die **heutigen Abläufe, Systeme und
> Datenquellen** beim Grundeigentümer Verband Schweiz (GVS), damit klar ist, worauf die
> Automatisierung aufsetzt und wo die echten Knackpunkte liegen.

---

## 1. Ist-Prozess heute (wie eine Verkaufsdoku entsteht)

Heute läuft die Erstellung einer Verkaufsdokumentation grösstenteils **manuell**:

1. Neues Verkaufsmandat → Objekt wird in **Copper** als «Opportunity» angelegt.
2. Das Front Office bestellt die nötigen Unterlagen **per E-Mail** (Verkäufer, Grundbuchamt,
   Verwaltung, Steueramt) und legt sie von Hand im Google-Drive-Objektordner ab.
3. Fotos werden vom Fotografen geliefert und abgelegt.
4. Die Doku wird in einer **duplizierten PowerPoint-Vorlage** erstellt: Texte, Zahlen und
   Bilder werden manuell eingefügt.
5. Inserate werden separat von Hand getextet, Termine per E-Mail koordiniert.

**Kennzahlen:** ~8 Personen im Front Office, ~25 Dokus/Monat, ~450'000 CHF/Jahr Vollkosten.
Der Engpass ist nicht die Nachfrage (Mandate), sondern der hohe manuelle Aufwand pro Objekt.

---

## 2. Google Drive – Ablagestruktur

Pro Verkaufsobjekt existiert **ein Ordner**. Namensschema (maschinenlesbar):

```
{Status}: {JJ-NNNNN}_{Ort}_{Strasse}
Beispiel:  Verkauft: 26-00042_Stäfa_Dorfstrasse 44D
```

Die Nummer `JJ-NNNNN` = die Immobilien-Nummer in Copper (Bindeglied CRM ↔ Ablage).

**Wiederkehrende Unterordner pro Objekt:**
- `Unterlagen` – Rohdokumente (Grundbuch, Steuer, Verwaltung)
- `GGST` – Stockwerkeigentums-Unterlagen (nur bei STWE)
- `Korrespondenz` – E-Mail-Verkehr
- `Verkauf` – Vermarktungsmaterial
- `Fotos` – benannt nach Fotograf
- `Bearbeitete Grundrisspläne`
- Im Hauptordner: die fertige Doku als `DE_{Nr}_{Ort}_{Strasse}.pdf`, dazu Rechnungen,
  Interessentenliste (Bieterverfahren), Übergabeprotokoll, Akquise-Checkliste

**Wichtig – das Steuerdokument:** In jedem Objektordner liegt ein Sheet **«Checkliste
Unterlagen»**. Es hält fest, welche Rohdokumente vorhanden bzw. bestellt sind. Das ist die
faktische Single Source of Truth für den Beschaffungsstand und ein zentraler Anker für die
Automatisierung.

**Inkonsistenzen (relevant fürs Parsing):** Trennzeichen uneinheitlich (`:` vs. `_`), Status
mal gross-, mal kleingeschrieben, `Korrespondenz` vs. `Korrespondenzen`, Fotoordner nach
Fotografenname statt Funktion, Belege teils als PDF, teils als Handy-Foto.

---

## 3. Copper-CRM

**Record-Typ:** Verkaufsobjekte = **Opportunities** in der Pipeline **«Immobilienverkauf»**
(~2'300 Objekte). Companies/People = Kontakte (Eigentümer, Käufer, Notar, Fotograf).

**Pipeline-Stages (25, in Reihenfolge):** Startphase · Pausiert (Startphase) · Startphase
abgeschlossen · Fotoaufnahmen erhalten · **Doku in Erstellung · Doku in Kontrolle · Doku beim
Auftraggeber** · Pausiert · Vermarktung gestartet · Im Verkauf (tiefe / mittlere / hohe
Nachfrage) · Standortgespräch vereinbaren · Preisanpassung in Umsetzung · Friedhof ·
Reservation versendet · Reservation erhalten · Anzahlung erhalten · Beim Notar ·
Kaufvertragsentwurf erhalten · Verurkundungstermin abgemacht · Verurkundet · Abschaltung
gemeldet · Abschaltung erledigt · DO NOT USE.

→ Die drei **fett** markierten Stages sind exakt der zu automatisierende Abschnitt. Der
**Trigger** für die Generierung ist der Stage-Wechsel nach «Fotoaufnahmen erhalten».

**Felder, die direkt aus Copper nutzbar sind:**
Immo-Nr. · Adresse/PLZ/Ort (im Namen) · Kanton · Objekttyp · Verkaufspreis · Provisionsmodell ·
Eigentümer (Primary Contact) · Owner/Akquisiteur · **Link zum Google-Drive-Ordner** (Custom
Field) · Prozess-Stage.

**Felder, die in Copper FEHLEN (kein eigenes Feld):**
Zimmerzahl · Wohn-/Grundstücksfläche · Baujahr/Renovation · Kataster-/Grundstück-Nr. ·
Wertquote · Erneuerungsfonds · Steuerwert · Eigenmietwert · Betriebs-/Nebenkosten ·
Parkplätze/Etage · Energie-/GEAK-Klasse · Heizsystem.

**Datenqualität:** Stammdaten meist gepflegt; viele Prozess- und Detailfelder oft leer. Zwei
Immo-Nr.-Formate (neu `JJ-NNNNN`, alt länger), bei Mehrfamilienhäusern teils mehrere Nummern.
**Test-/Archiv-Records ausschliessen** (Stage «DO NOT USE», «TEST PIPELINE», «Tech. Archiv»).

**Wichtigste Erkenntnis:** Copper liefert die **kaufmännischen Stammdaten + den Drive-Link +
den Prozess-Trigger** – aber **nicht** die bautechnischen/bewertungsrelevanten Detaildaten.
Die liegen unstrukturiert in den Dokumenten im Drive-Ordner.

---

## 4. Die Vorlage: `SalesFolder_UMA_v4`

Alle echten Verkaufsdokus laufen über **eine** Vorlage (verglichen über mehrere Objekte). Stark
standardisiert. Aufbau in Reihenfolge:

| Kapitel | Inhalt | Typ |
|---|---|---|
| Titel | Headline + Objekttyp/Adresse + Immo-Nr. | variabel |
| Makrolage | Gemeinde-Stammdaten | variabel |
| Mikrolage | QR-Code Wüest-Tool | fix |
| Objektbeschrieb | Fliesstext + Feature-Bullets | variabel |
| Fakten & Zahlen | Bau, Flächen, Preis, Nebenkosten, Steuern | variabel |
| Besichtigung | QR/Link Terminbuchung | fix |
| Finanzierung | Werbeblock Verband | fix |
| Grundrisse + Situationsplan | je Geschoss | variabel |
| Fotostrecke | pro Bild Raum-Label + Caption | variabel |
| Kontakt / Über uns / Vorbehalte / Links | | fix/variabel |

**Datenmodell: ~30 variable Felder, typabhängig:**
- **Stockwerkeigentum (STWE):** Wertquote, Erneuerungsfonds (Stand/Einlage), Betriebskosten
- **Einfamilienhaus (EFH):** Grundstück-Nr./Kataster-Nr., Schuldbriefe, Bauzone, evtl.
  übernehmbare Hypothek
- **Gemeinsam:** Headline, Objekttyp, Adresse, Gemeinde-Stammdaten, Beschrieb, Baujahr,
  Wohnfläche, Zimmer, Heizung, Parkierung, Kaufpreis, Steuer-/Eigenmietwert, Kontaktperson,
  Fotos, Grundrisse, Links (Matterport, Wüest, propertyowner.ch)
- **Fixe Textblöcke** (für alle gleich): Finanzierung, Über uns, Vorbehalte, Besichtigung

*(«UMA» im Vorlagennamen stammt von einem Testdatensatz «Uma Narayan» – kein inhaltliches Kürzel.)*

---

## 5. Datenquellen-Mapping

| Feld / Gruppe | Quelle | Verfügbarkeit |
|---|---|---|
| Immo-Nr., Adresse, Kanton, Objekttyp, Preis, Eigentümer, Kontaktperson | Copper | strukturiert vorhanden |
| Link zum Drive-Objektordner | Copper (Custom Field) | vorhanden (neue Objekte) |
| Kataster-/Grundstück-Nr., Wertquote, EGRID | Grundbuchauszug (Drive) | vorhanden, unstrukturiert |
| Betriebskosten, Erneuerungsfonds | Verwaltung (Drive) | STWE, unstrukturiert |
| Steuerwert, Eigenmietwert, Baujahr | Steueramt (Drive) | teils zu bestellen |
| Zimmer, Flächen, Heizung, GEAK | Inserat/Grundrisse/GV-Auszug (Drive) | unstrukturiert |
| Marktbewertung | Wüest Partner (extern) | nie im Drive – separat bestellen |
| Fotos, Grundrisse, virtueller Rundgang | Fotograf / Matterport (Drive) | vorhanden |

**Kernaussage:** Kaufmännische Daten sind sauber aus Copper ziehbar. Die bautechnischen und
bewertungsrelevanten Detaildaten liegen **unstrukturiert** in den Drive-Dokumenten – hier liegt
die eigentliche Arbeit (und der grösste KI-Hebel: automatische Extraktion).

---

## 6. Bestehende «Automatisierung» – und warum sie stockt

Es gibt zwei Dinge, die intern verwechselt werden:

- **Produktiv, aber manuell:** Die guten Dokus entstehen über die `UMA_v4`-Vorlage, von Hand in
  PowerPoint gepflegt (zahlreiche «Kopie von Kopie von …»).
- **Die «Automatisierung»:** ein vor wenigen Tagen ausgerolltes Werkbank-Gerüst mit
  `_Input`/`_Output`-Ordnern – **komplett leer und ungenutzt.** Kein Generierungs-Skript, keine
  Verdrahtung, kein verkaufsdoku-spezifischer Workflow.

**Diagnose, warum das Projekt seit ~1 Jahr nicht liefert:**
- Mehrfaches Neu-Aufsetzen des Ordnungssystems statt durchgängiger Bau.
- Es wurde Ordnung geschaffen, aber **nie die Engine gebaut** – der Generierungsschritt fehlt.
- Fortschritt steckt in Vorlagen-Versionen (v3, v4) statt in einem reproduzierbaren Prozess.
- Heterogene, unvollständige Eingangsdaten; Format-Zersplitterung (PDF/PPTX/DOCX/GDoc).
- Solange der manuelle Weg «gut genug» läuft, fehlt der Druck, fertigzubauen.

**Konsequenz:** Vorlage und Daten existieren – die Lücke ist allein der **Generierungsschritt**.
Genau dort setzt Modul 1 an.

---

## 7. Soll-Pipeline (geplanter Ablauf)

1. **Trigger** – Copper-Stage wechselt auf «Fotoaufnahmen erhalten» / «Doku in Erstellung».
2. **Stammdaten ziehen** – aus Copper (Immo-Nr., Adresse, Objekttyp, Preis, Kontakt, Drive-Link).
3. **Dokumente lesen** – Drive-Ordner öffnen; Grundbuch, Steuer, Verwaltung, Inserat per KI
   extrahieren.
4. **Datensatz + Lücken** – Felder befüllen, fehlende/zu bestellende Angaben gegen die
   «Checkliste Unterlagen» markieren.
5. **Doku generieren** – Datensatz ins Template (typabhängig STWE/EFH) → fertige Doku.
6. **Kontrolle** – Front Office prüft, korrigiert (Stage «Doku in Kontrolle»). Bleibt bewusst
   ein menschlicher Schritt.
7. **Ablage & Status** – finale Doku im Objektordner ablegen, Copper-Stage weiterschalten.

---

## 8. Offene technische Punkte / Knackpunkte

- **Datenextraktion** aus unstrukturierten Dokumenten (PDF/Foto) ist der grösste Brocken und
  fehleranfällig – daher Kontroll-Schritt fix eingeplant. Option: die wichtigsten Felder
  zusätzlich als Custom Fields in Copper ergänzen, um weniger extrahieren zu müssen.
- **Copper-API-Zugang** und genaues Feld-Mapping klären.
- **Output-Format:** PDF (wie heute) und/oder Web-Landingpage – aus einer Datenquelle.
- **Ablage-Standardisierung:** Ordnernamen/Trenner vereinheitlichen, «Checkliste Unterlagen»
  konsequent als Steuerquelle.
- **Datenschutz:** Verkaufsdokus enthalten Personendaten (Eigentümer) → revDSG-konform aufsetzen
  (wo werden Daten verarbeitet).
- **MVP-Schnitt:** zuerst nur STWE + EFH, nicht jeden Sonderfall.

---

*Verweise: die ausführliche visuelle Aufbereitung liegt als `struktur-analyse.html`; das
Geschäfts-/Rollen-Briefing als `Projekt-Briefing-Kollege.md`.*