Wir nutzen Google Analytics, um die Nutzung anonymisiert zu analysieren und unser Angebot zu verbessern. Mit „Akzeptieren" willigen Sie ein, dass Google Analytics Cookies setzt (jederzeit widerrufbar). Details in der Datenschutzerklärung.

Plattform-Dokumentation

AG READY Plattform-Dokumentation

Konzeption, Architektur, Funktionen und Prozesse der digitalen AG READY Plattform.

Version:v1.6.0Stand:24. September 2026Herausgeber:Kapitalwerk AGPlattform:AG READY

Diese Dokumentation beschreibt die öffentliche Plattformarchitektur, Funktionen und Prozesse von AG READY.

Vorwort

Vorwort

AG READY entstand ursprünglich aus dem Auftrag, eine digitale Landingpage für eine neue Schweizer AG-Lösung zu entwickeln.

Während der Konzeption wurde jedoch deutlich, dass die eigentliche Herausforderung nicht nur in der Präsentation eines Angebots liegt, sondern in der vollständigen digitalen Abbildung des gesamten Geschäftsprozesses.

Aus einer Landingpage entwickelte sich deshalb schrittweise eine integrierte Plattform für Marketing, Content, Lead Management, Business Development, Prüfung, Offerten, Vertragsprozesse, digitale Signatur, Dokumente, Kommunikation, Administration und Datenintegration.

Diese Dokumentation beschreibt die öffentliche Plattformarchitektur, ihre Funktionen und Prozesse in ihrem heutigen, implementierten Stand. Sie richtet sich an Kunden, Partner, Fachexperten und Interessenten, die verstehen möchten, wie AG READY technisch und fachlich aufgebaut ist.

Editorial

Vom digitalen Auftritt zur integrierten Plattform

Ausgangspunkt war eine vergleichsweise einfache digitale Lösung. Eine Landingpage, die ein neues Schweizer AG-Angebot präsentiert. Schnell wurde jedoch deutlich, dass die Trennung zwischen Auftritt, Vertrieb, Prüfung, Kundenportal und internem Betrieb künstlich ist. Wer einen Lead generiert, sollte ihn im selben System weiterführen, qualifizieren, prüfen, offerte und begleiten können.

AG READY wurde deshalb als zusammenhängendes System konzipiert, nicht als Sammlung einzelner Funktionen.

Mein Ansatz folgte einer klaren Reihenfolge: Geschäftsproblem, Prozess, Daten, Plattform, Automatisierung, Benutzerrollen, Monetarisierung. Erst wenn das Geschäftsproblem und der zugehörige Prozess klar sind, entsteht die Datenstruktur. Aus der Datenstruktur ergibt sich die Plattform. Darauf aufbauend werden Automatisierung, Rollen und Monetarisierung geschichtet.

Entscheidend war nicht, möglichst viele einzelne Funktionen zu bauen, sondern einen durchgängigen Workflow zu schaffen. Jede Information soll möglichst nur einmal entstehen und danach entlang des gesamten Kundenlebenszyklus weiterverwendet werden. Ein Lead, der über die Website eingeht, durchläuft Erstgespräch, Prüfung, Entscheid, Offerte, Vertrag, Aufbau und schliesslich die Aktienübernahme, ohne dass Daten dupliziert oder manuell übertragen werden müssen.

Die Plattform soll skalierbar bleiben, ohne die Bedienung unnötig komplex zu machen. Design und Architektur wurden deshalb gemeinsam gedacht. Technik soll für den Benutzer möglichst unsichtbar bleiben. Was zählt, ist ein nachvollziehbares, zuverlässiges Erlebnis über alle Phasen hinweg.

AG READY wird kontinuierlich weiterentwickelt. Diese Dokumentation beschreibt den heutigen, implementierten Stand der Plattformarchitektur, ihrer Funktionen und Prozesse.

Fabian Reinarz

Entwickler, Designer und Plattformarchitekt

01

Überblick

AG READY besteht aus mehreren miteinander verbundenen Ebenen. Jede Ebene hat eine klare Verantwortung und ist mit den benachbarten Ebenen verzahnt. So entsteht ein durchgängiger Workflow vom ersten Interesse bis zur laufenden Kundenbetreuung.

01

Public Layer

Die öffentliche Website und alle akquisitorischen Einstiegsflächen.

WebsiteSEO HubFachredaktionLinkedInLandingpagesTerminbuchung
02

Lead Layer

Import, Anreicherung, Qualifizierung und Bereitstellung kontaktierbarer Unternehmen für das Business Development.

wirtschaftsdaten.ch (Stammdaten)Import-Eingangmanuelle AuswahlEnrichment Agent V2DataForSEOQualitätsklassen A–DLeadpool
03

Business Development

Qualifizierung, Prüfungsvorbereitung und Begleitung von Leads durch zuständige Owner.

ZuweisungLead OwnerAnrufeE-MailsRückrufeTermineAufgabenPipelineTimelinePrüfung starten
04

Prüfung & Entscheid

Verbindliche Prüfung des Kunden, Rückfragen, interne Beurteilung, getrennter Bescheid und Intervention.

PrüfungsfallFragenkatalogAntwortenRückfragenVersionierungAudit TrailEntscheidBescheidInterventionFolgeentscheid
05

Customer Layer

Vom Entscheid über Offerte und Vertrag bis hin zu Aufbau, Rechnung und Aktienübernahme.

OffertenRückfragenRevisionenVerträgeSignaturAufbauAktienübernahmeDokumenteRechnungenZahlungen
06

Administration

Mitarbeiter, Rollen, Inhalte und Systemverwaltung.

MitarbeiterRollenZuweisungenKunden 360PrüfungBenachrichtigungenContentSEOSystemverwaltung
End-to-End Flows
End-to-End Kundenfluss (verbindlicher Workflow)
ErstgesprächPrüfungEntscheidOfferteVertragUnternehmen aufbauenAktien übernehmen
Detailablauf Prüfung, Entscheid & Bescheid
Prüfung startenFragen versendenKunde antwortetRückfrageKunde antwortetinterne BeurteilungEntscheid (intern)Bescheid vorbereitenBescheid sendenbei negativ: InterventionFolgeentscheidbei positiv: Offerte freigegeben
Detailablauf Offerte & Vertrag
Offerte freigegebenmanueller VersandKunde öffnetRückfrage / RevisionAnnahmeVertrag aus OfferteSignatur (OTP)Aufbau
Lead-Lifecycle (Import → Leadpool)
wirtschaftsdaten.chImport-Eingangmanuelle AuswahlEnrichment Agent V2DataForSEO + öffentliche QuellenMatching & ValidierungQualitätsklasse A–DTelefon vorhanden?FreigabeLeadpool
Übergabe an Business Development (Sales)
LeadpoolKontaktErstgesprächPrüfung startenEignungsfrageninterne Prüfung / RückfragenEntscheidBescheidIntervention (negativ) / Offerte (positiv)VertragUnternehmen aufbauenAktien übernehmen
02

Ausgangslage

Die Schweiz bietet mit der Aktiengesellschaft eine bewährte Rechtsform für haftungsbeschränkte Unternehmungen. Eine Hürde ist dabei regelmässig das gesetzlich erforderliche Aktienkapital von CHF 100'000, das bei der Gründung einbezahlt werden muss.

AG READY begegnet dieser Hürde mit bereitgestelltem Aktienkapital im Rahmen einer vertraglich vereinbarten Struktur. Aus einer einzelnen Leistung wurde so ein zusammenhängendes Angebot: Gründung, Domizil, Verwaltungsrat, Buchhaltung und Administration aus einer Hand.

Die Plattformdokumentation entstand, weil die digitale Abbildung dieses Angebots inzwischen deutlich über eine klassische Landingpage hinausgeht. Sie umfasst den gesamten Weg vom ersten Interesse über die Qualifizierung und Prüfung bis zur Vertragsabwicklung, zum Aufbau der Gesellschaft und zur schliesslichen Aktienübernahme.

04

Öffentliche Website

Die öffentliche Website ist der erste Berührungspunkt für Interessenten. Sie verbindet Informations- und Akquisitionsflächen mit den internen Prozessen.

Bestandteile

  • Startseite mit Leistungsüberblick und Handlungsaufforderung
  • Leistungen mit detaillierter Beschreibung der AG READY Angebote
  • Über uns und Expertenprofile
  • Fachredaktion mit Ratgeberartikeln
  • SEO Landingpages für thematische Suchanfragen
  • FAQ
  • Kontaktformular
  • Terminbuchung für kostenlose Erstgespräche
  • Rechtliche Seiten (Impressum, Datenschutz, AGB)

Ziel und Verknüpfung Die Website führt Besucher gezielt in einen Termin oder eine Kontaktanfrage. Aus diesen Anfragen entstehen Leads, die ohne Medienbruch in das Lead Management übergehen. Das Erstgespräch ist der erste Schritt des verbindlichen Kundenworkflows.

05

AG READY Lösung

AG READY umfasst mehrere aufeinander abgestimmte Leistungen für die Gründung und den Betrieb einer Schweizer Aktiengesellschaft.

Kernleistungen

  • AG-Gründung ohne Einzahlung von CHF 100'000 Eigenkapital
  • AG auf Zeit mit treuhänderischer Aktienhaltung während der Übergangsphase
  • Domizil als Geschäftsdomizil
  • Verwaltungsratsmandat
  • Buchhaltung und Treuhand
  • Administration, Steuerdeklarationen und Behördenverkehr

Ergänzende Leistungen

  • Unternehmensnachfolge
  • Beteiligungsstrukturen
  • Markteintritt Schweiz
  • Ansiedlung Schweiz
  • Relocation

Eine Finanzierungsgarantie oder eine Garantie für die spätere Aktienübertragung wird nicht abgegeben. Die spätere Übertragung erfolgt ausschliesslich bei Erfüllung der vertraglich definierten Voraussetzungen. Der letzte Schritt «Aktien übernehmen» wird bewusst erst bei fachlich tatsächlichem Fortschritt freigeschaltet.

06

SEO Hub

Der SEO Hub bündelt die Massnahmen für nachhaltige organische Sichtbarkeit. Er verbindet strukturierte Landingpages mit Fachartikeln, Autoren und Leistungen.

Bestandteile

  • Themenspezifische SEO Landingpages
  • Content Cluster mit verwandten Artikeln
  • Interne Verlinkung zwischen Landingpage, Fachartikel, Autor und Leistung
  • Autorenprofile und strukturierte Personendaten
  • Related Articles zu jedem Beitrag
  • Dynamische Sitemap und Schema.org Auszeichnungen
  • Canonical-Tags und saubere Meta-Daten
  • Mehrsprachige hreflang-Verweise

Verknüpfungsflow SEO Landingpage, Fachartikel, Autor, Leistung und kostenloses Erstgespräch sind konsistent miteinander verbunden. Jede Seite stärkt die thematische Autorität der anderen.

07

Fachredaktion

Die Fachredaktion stellt hochwertige, fachlich geprüfte Inhalte bereit. Jeder Autor ist einem klaren Fachgebiet zugeordnet.

Autoren und Themen

  • Dr. Michele Imobersteg, Recht und Wirtschaftsrecht
  • Daniel Hofmann, Steuern und steuerliche Unternehmensstruktur
  • Elisabeth Büchler, Treuhand und Buchhaltung
  • Fabian Reinarz, Sales und Business Development

Struktur Artikel folgen einer einheitlichen Struktur mit Einleitung, Fachinhalt und Quellen. Jeder Beitrag trägt eine Autorensignatur mit Profil-Verlinkung. Inhalte sind thematisch in Cluster eingebettet und mit den passenden Leistungen und SEO Landingpages verknüpft.

08

LinkedIn Content Engine

Die LinkedIn Content Engine erzeugt regelmässig hochwertige Inhalte für die professionelle Zielgruppe von AG READY.

Funktionsweise

  • Tägliche Erstellung von Beiträgen
  • Themenrotation über relevante Fachgebiete
  • Ausrichtung auf die Zielgruppen Gründer, Fachexperten und Partner
  • Schweizer Schreibregeln und konsistente Ansprache
  • Bildauswahl über eine lizenzierte Bildquelle
  • Medienbibliothek mit Duplikatsschutz
  • Veröffentlichung über einen externen Publishing-Dienst
  • Eindeutige Handlungsaufforderung zu AG READY
  • Nachvollziehbare Content-Historie

Es werden keine internen API-Details, Zugänge oder Secrets veröffentlicht.

09

Lead Management

Das Lead Management erfasst und strukturiert alle Interessenten an zentraler Stelle. Es beginnt mit den Leads, die den Leadpool erreicht haben — also den Enrichment- und Qualifizierungsprozess durchlaufen haben.

Funktionen

  • Meine Leads und alle Leads
  • Lead übernehmen und Lead Owner zuweisen
  • Lead-Zuweisung an zuständige Mitarbeiter
  • Anrufe, E-Mails, Rückrufe, Termine und Aufgaben
  • Notizen zur Gesprächsdokumentation
  • Status und Priorität
  • Pipeline-Übersicht
  • Timeline aller Aktivitäten
  • Teamansicht und Admin Work Mode

Jede Aktion wird in der Timeline revisionssicher protokolliert. So entsteht eine durchgängige Historie je Lead.

10

wirtschaftsdaten.ch Integration

wirtschaftsdaten.ch ist die Quelle für Unternehmens- und Stammdaten ausgewählter Schweizer Handelsregisterereignisse. Importierte Unternehmen sind KEINE definitiven Sales-Leads.

Verarbeitete Ereignisse

  • Konkurs
  • Liquidation
  • Auflösung
  • Löschung

Der Fokus liegt auf der Deutschschweiz.

Rolle im Lead-Lifecycle wirtschaftsdaten.ch liefert ausschliesslich Stammdaten: Firma, UID/CHE, Rechtsform, Adresse, Zweck, Personen, Branche und — soweit vorhanden — erste Kontaktdaten. Diese Rohdaten landen im Import-Eingang, nicht direkt im Leadpool.

Klare Abgrenzung der Systeme

  • wirtschaftsdaten.ch = Quelle für Unternehmens- und Stammdaten
  • DataForSEO = externe Recherche- und Enrichment-Schicht
  • AG READY Lead Enrichment Agent = Orchestrierung, Matching, Validierung, Qualitätsbewertung
  • AG READY Leadpool = operative Sales-Liste
  • Business Development = Bearbeitung qualifizierter Leads

Erfasste Stammdaten Unternehmen, UID/CHE, Rechtsform, Adresse, PLZ, Ort, Kanton, Zweck, Personen (Zeichnungsberechtigte), Branche sowie das auslösende Ereignis mit Datum und Publikationsdatum.

Es werden keine API-Tokens, Secrets, internen Endpoints oder Security-Keys veröffentlicht.

10.1

Import-Eingang

Der Import-Eingang ist die zentrale Eingangsstation für alle aus wirtschaftsdaten.ch importierten Unternehmen. Hier findet die Trennung zwischen Rohdaten und definitiven Sales-Leads statt.

Grundprinzip Importierte Unternehmen sind noch KEINE definitiven Sales-Leads. Sie durchlaufen zuerst Enrichment und Qualifizierung, bevor sie in den Leadpool aufgenommen werden.

Import

  • Daten werden aus wirtschaftsdaten.ch importiert (serverseitige Funktion importWirtschaftsdatenLead).
  • Pro Datensatz werden Source IDs, ein Import Batch und ein vollständiger Source Snapshot (source_payload) erfasst.
  • Dublettenprüfung über transfer_key / source_record_id verhindert Mehrfachimporte.

Verwendete Felder (Lead-Entity)

  • source_system = wirtschaftsdaten.ch
  • source_record_id / company_master_id
  • import_batch_id
  • imported_at
  • source_payload (vollständiger Original-Payload)
  • intake_status = IMPORTED nach dem Import

Status nach Import Neu importierte Datensätze erhalten den Status IMPORTED. Sie bleiben im Import-Eingang und erscheinen nicht im Leadpool.

Filter und Auswahl

  • Filter nach Kanton, Suche, Ereignis und Status.
  • Einzelne Datensätze können gezielt zur Anreicherung ausgewählt werden.
  • Bulk-Auswahl für mehrere Datensätze gleichzeitig.
  • Passwordgeschützter Zugang für berechtigte Mitarbeiter.

Warum nicht automatisch in den Leadpool? Ein automatischer Übertritt würde unqualifizierte Datensätze ohne belastbare Telefonnummer in den Vertrieb bringen. Die manuelle Auswahl und das anschliessende Enrichment stellen sicher, dass nur geprüfte, kontaktierbare Unternehmen den Sales-Prozess erreichen.

10.2

Lead Enrichment Agent V2

Der Lead Enrichment Agent V2 orchestriert die Kontaktanreicherung eines ausgewählten Import-Leads. Er erfindet keine Daten, sondern recherchiert, matcht, validiert und bewertet.

Trigger

  • Manuelle Auswahl im Import-Eingang (Einzel- oder Bulk-Anreicherung).
  • Kein automatischer Aufruf auf jeden Import — bewusste, kostenkontrollierte Ausführung.
  • Erneutes Enrichment bestehender Leadpool-Leads möglich (manuell).

Backend-Funktionen

  • bulkEnrichLeads (Bulk, max. 25 Leads pro Durchlauf)
  • enrichLeadContact (Einnel)
  • Verarbeitung serverseitig via asServiceRole.

Verwendete Entities

  • Lead (angereicherter Datensatz)
  • EnrichmentRun (Audit je Anreicherungslauf)
  • ActivityLog (Timeline)

DataForSEO-Integration DataForSEO ist die primäre Recherchequelle; Gemini Websearch ist Fallback, wenn DataForSEO keine Kontaktdaten liefert. Details im separaten Kapitel DataForSEO.

Enrichment-Priorität (verbindlich)

  1. Telefonnummer
  2. Website
  3. E-Mail-Adresse
  4. Ansprechpartner
  5. Funktion
  6. weitere Sales-relevante Informationen

Ziel: Telefon + Website + E-Mail. Harte Mindestanforderung: eine belastbare Telefonnummer.

Matching-Logik

  • DataForSEO Google Maps liefert Kandidaten.
  • Ein LLM wählt höchstens einen Kandidaten aus, der mit ausreichender Sicherheit zur Schweizer Ziel-Firma passt (Name, UID/CHE, Ort, PLZ, Kanton, Adresse, Rechtsform).
  • Ähnliche Namen in anderen Orten sind KEIN Treffer.
  • Bei Liquidation/Konkurs kann die Adresse weiterhin stimmen; Personenkontakte werden priorisiert.

Feldermittlung

  • Website: aus Maps-Kandidat oder SERP-Fallback; danach Kontakt-/Impressumseite crawlen.
  • Telefon: aus Maps-Kandidat oder Website-Kontaktseite.
  • E-Mail: aus Website-Kontaktseite, Bevorzugung domain-passender Adressen.
  • Ansprechpartner/Funktion: aus wirtschaftsdaten-Personen oder recherchierten Personenkontakten.

Quellen, Confidence, Verification Jeder angereicherte Wert speichert soweit möglich: value, source_url, source_type, found_at, confidence (high/medium/low/none), verification_status, enrichment_run_id.

Fehlerbehandlung und Retry

  • DataForSEO-Fehler werden geloggt; der Lauf fällt auf Gemini Websearch zurück.
  • Enrichment-Historie: jeder Lauf erzeugt einen EnrichmentRun-Datensatz mit Dauer, Requests, Kandidaten, Treffer, Score und Quelle.
  • Versionierung über enrichment_attempts und fallback_enriched_at; 7-Tage-Caching verhindert unnötige Wiederholungen.

Keine erfundenen Kontaktdaten Der Agent darf keine Telefonnummern oder E-Mail-Adressen konstruieren oder erraten. Insbesondere werden keine vermuteten E-Mail-Muster als echte Kontaktdaten gespeichert. Nur verifizierte, quellengesicherte Werte werden übernommen.

10.3

DataForSEO

DataForSEO ist die externe Recherche- und Enrichment-Schicht, eingesetzt nach der manuellen Auswahl im Import-Eingang.

Warum DataForSEO wirtschaftsdaten.ch liefert Stammdaten, aber häufig keine belastbaren Kontaktdaten. DataForSEO stellt strukturierte Google Maps- und SERP-Daten bereit, mit denen Telefon, Website und E-Mail verifiziert recherchiert werden können.

Einsatzstelle im Lifecycle Import-Eingang → manuelle Auswahl → DataForSEO (primär) → Matching & Validierung → Qualifizierung.

Tatsächlich implementierte APIs

  • Google Maps Business Search (mapsSearch): Sucht Schweizer Unternehmen per Keyword + Ort.
  • Google SERP Organic Search (serpSearch): Fallback zur Website-Ermittlung.
  • Website Contact Extraction (fetchContactData): Crawlt Kontakt-/Impressumseiten der ermittelten Website.

Es werden keine theoretischen Endpoints dokumentiert, die nicht implementiert sind.

Suchanfragen Keyword-Aufbau: «Firmenname Ort Schweiz». Maps liefert bis zu 8 Kandidaten mit Titel, Telefon, Website, Adresse und Kategorie.

Firmen-Matching und Vermeidung falscher Zuordnungen

  • LLM-Matching gegen Stammdaten (Name, UID/CHE, Ort, PLZ, Kanton, Adresse, Rechtsform).
  • Ähnliche Namen in anderen Orten werden nicht zugeordnet.
  • matched=false bei unzureichender Sicherheit; niemals Erfinden.

Quellenspeicherung Gefundene Werte werden mit source_url, source_type, confidence und verification_status im contact_enrichment_result gespeichert.

API-Credentials und Kostenschutz

  • Credentials serverseitig als Secrets gespeichert (DATAFORSEO_LOGIN / DATAFORSEO_PASSWORD), nie im Frontend.
  • Bulk-Anreicherung auf maximal 25 Leads pro Durchlauf begrenzt.
  • Caching (7 Tage) verhindert unnötige Wiederholungsrequests.
  • EnrichmentRun protokolliert die Anzahl DataForSEO-Requests je Lauf.
10.4

Qualitätsklassen

Jeder Lead erhält nach dem Enrichment eine Qualitätsklasse, die die Kontaktierbarkeit bewertet.

Klassen

  • A: Telefon + Website + E-Mail
  • B: Telefon + Website
  • C: Telefon + E-Mail
  • D: Telefon
  • Nicht qualifiziert: keine belastbare Telefonnummer

Telefon als Mindestanforderung Ohne belastbare Telefonnummer ist ein Lead nicht qualifiziert. Die Telefonnummer ist die harte Mindestvoraussetzung für die Aufnahme in den Leadpool.

Technische Berechnung Die Funktion scoreLead (contactQuality) prüft das Vorhandensein von phone/company_phone, website/domain und email/company_email sowie aktive Personen. Das Ergebnis wird in contact_quality_score (A–E) und contact_quality_reason gespeichert.

  • Score A: Telefon + Website + E-Mail
  • Score B: Telefon + Website
  • Score C: Telefon + E-Mail
  • Score D: nur Telefon
  • Score E: kein Telefon → nicht qualifiziert (REJECTED_NO_PHONE)

ag_ready_transfer_eligible ist true nur, wenn die Firma gesellschaftsrechtlich transferable ist UND die Kontaktqualität A–D beträgt (Telefon vorhanden).

Datenherkunft Originaldaten und Enrichment-Daten bleiben nachvollziehbar getrennt: original_phone / enriched_phone, original_email / enriched_email, original_website / enriched_website.

10.5

CSV-Export

Der CSV-Export stellt Import- und Enrichment-Daten für die externe Weiterverarbeitung bereit. Er läuft serverseitig, sodass auch grosse Datenmengen (5'000+) vollumfänglich exportiert werden.

Export-Varianten

  • alle Importdaten
  • aktuell gefilterte Daten
  • ausgewählte Daten
  • angereicherte Daten
  • qualifizierte Daten (A–D)
  • mit Telefonnummer
  • ohne Telefonnummer
  • nach Qualitätsklasse

Enthaltene Felder Stammdaten (Firma, UID, Rechtsform, Adresse, PLZ, Ort, Kanton, Branche), Import-Metadaten (source_company_id, import_batch_id, imported_at, source), getrennt original_ / enriched_ für Telefon, E-Mail und Website — jeweils mit Status und Quelle —, Ansprechpartner, Funktion, LinkedIn, Enrichment_Status, Qualitätsklasse, Confidence, verification_status, Leadpool_Status, Owner und letzte Aktivität.

Codierung UTF-8 mit BOM, Semikolon-Trenner, CRLF — öffnet sauber in Schweizer Excel mit korrekten Umlauten (ä, ö, ü).

Serverseitige Ausführung Die Backend-Funktion exportLeadsCsv holt alle Datensätze serverseitig (Pagination), unabhängig von der im Browser gerenderten Menge.

Berechtigungen Nur Admin, Super Admin und Business Development dürfen exportieren.

Audit Logging Jeder Export wird im ActivityLog protokolliert: exported_by, Zeit, record_count, angewendeter Filter und export_type. CSV-Inhalte werden nicht gespeichert.

10.6

Lead-Lifecycle & Architektur

Der verbindliche Lead-Lifecycle trennt Rohdaten, Anreicherung, Qualifizierung und Sales klar voneinander.

Architekturdiagramm wirtschaftsdaten.ch → Import-Eingang → manuelle Auswahl → Enrichment Agent → DataForSEO + öffentliche Quellen → Matching + Validierung → Datenqualität A/B/C/D → Telefon vorhanden? → NEIN: Review/Reject / JA: Freigabe → Leadpool → Business Development.

Statusmodell des Lead-Lifecycle (intake_status, tatsächlich implementiert)

  • IMPORTED — Rohdaten aus wirtschaftsdaten.ch
  • SELECTED_FOR_ENRICHMENT — zur Anreicherung ausgewählt
  • ENRICHING — Anreicherung läuft
  • ENRICHED — angereichert, zur Prüfung
  • NEEDS_REVIEW — manuelle Prüfung erforderlich
  • QUALIFIED — qualifiziert
  • REJECTED_NO_PHONE — keine Telefonnummer, nicht qualifiziert
  • ENRICHMENT_FAILED — Anreicherung fehlgeschlagen
  • LEADPOOL — freigegeben für Business Development

Manuell erfasste Leads erhalten direkt LEADPOOL.

Übergabe an Business Development Erst nach erfolgreicher Qualifizierung und Übernahme in den Leadpool beginnt der eigentliche AG-READY-Sales-Prozess: Leadpool → Kontakt → Erstgespräch → Prüfung starten → Eignungsfragen → interne Prüfung / Rückfragen → Entscheid → Bescheid → bei negativ: Intervention / bei positiv: Offerte → Vertrag → Unternehmen aufbauen → Aktien übernehmen.

Lead Enrichment gehört VOR diesen Sales-Prozess.

11

Business Development

Das Business Development begleitet Leads von der ersten Kontaktaufnahme bis zur Qualifizierung und Vorbereitung der Prüfung. Voraussetzung ist, dass ein Lead den Leadpool erreicht hat — also den Enrichment- und Qualifizierungsprozess durchlaufen hat.

Funktionen

  • Meine Leads und alle Leads
  • Lead übernehmen
  • Lead Owner und Lead-Zuweisung
  • Anruf, E-Mail, Rückruf
  • Termin und Aufgabe
  • Notiz
  • Status und Priorität
  • Pipeline
  • Timeline
  • Teamansicht
  • Admin Work Mode

Prüfungsvorbereitung Business Development darf eine Prüfung für einen zuständigen Kunden starten, den Fragenkatalog versenden, eingegangene Antworten einsehen, Rückfragen stellen und eine interne Beurteilung ergänzen. Der Entscheid selbst bleibt Admin / Super Admin vorbehalten.

Zuständige Owner arbeiten ihre Leads strukturiert ab. Jede Interaktion wird dokumentiert und fliessen in die Timeline ein. Damit bleibt der Verlauf auch nach Owner-Wechseln nachvollziehbar.

12

Mitarbeiter und Rollen

AG READY unterscheidet konzeptionell mehrere Rollen mit unterschiedlichen Verantwortlichkeiten.

Rollen

  • Super Admin
  • Admin
  • Business Development
  • Sales

Freigabeprozess Neue Mitarbeiter durchlaufen eine Registrierung mit anschliessender Freigabe. Eine Registrierung erzeugt zunächst einen Pending-Status. Erst nach Freigabe durch einen Admin erhält die Person Zugriff im vereinbarten Rahmen.

Berechtigungen im Kundenworkflow

Business Development:

  • Prüfung starten
  • Fragen versenden
  • Antworten einsehen
  • Rückfragen stellen
  • interne Beurteilung ergänzen

Admin / Super Admin zusätzlich:

  • Entscheid setzen
  • Offerte finalisieren
  • Offerte versenden
  • Vertrag versenden
  • Status korrigieren
  • komplette Historie einsehen
  • Testprozess mit Testkunden ausführen

Interne Security-Interna werden nicht veröffentlicht.

13

Customer Lifecycle

Der verbindliche Kundenworkflow von AG READY beschreibt den Weg vom Erstkontakt bis zur Aktienübernahme in sieben Hauptschritten.

Verbindlicher Workflow

  1. Erstgespräch
  2. Prüfung
  3. Entscheid
  4. Offerte
  5. Vertrag
  6. Unternehmen aufbauen
  7. Aktien übernehmen

Prinzipien

  • Jeder Schritt baut auf dem vorhergehenden auf.
  • Der sichtbare Hauptstatus im Kunden-Dashboard leitet sich ausschliesslich aus dem tatsächlichen Backend-Status ab, nie aus Annahmen.
  • Übergänge sind entweder automatisch (Eingang einer Kundenantwort, Signatur abgeschlossen) oder bewusst manuell (Entscheid, Offertenversand, Freischaltung «Aktien übernehmen»).
  • Der letzte Schritt «Aktien übernehmen» wird nicht automatisch früh aktiviert. Nur fachlich tatsächlicher Fortschritt darf ihn freischalten.

Ein Lead bleibt im System erhalten. Aus dem Lead wird ein Customer, dem Prüfung, Offerten, Verträge und Zahlungen zugeordnet sind. Lead, Customer, Prüfung, Offerten, Verträge und Zahlungen sind konsistent miteinander verknüpft. So bleibt die Herkunft jedes Kunden nachvollziehbar.

14

Prüfung

Die Prüfung ist der verbindliche Schritt nach dem Erstgespräch. Sie stellt sicher, dass bestehende Verpflichtungen und die zukünftige Entwicklung des Kunden sachgerecht beurteilt werden können.

Wer eine Prüfung starten darf

  • Business Development (für die zuständigen Kunden)
  • Admin
  • Super Admin

Übermittlung an den Kunden Nach dem Start wird ein Prüfungsfall angelegt. Der verbindliche Fragenkatalog wird als Snapshot erfasst. Der Kunde erhält eine Benachrichtigung per Resend sowie eine Portal-Notification mit einem direkten Einstieg in die Prüfung.

Antworten im Dashboard Der Kunde beantwortet die Fragen direkt im Kunden-Dashboard. Antworten werden serverseitig gespeichert. Bei Ja/Nein-Fragen kann eine bedingte Ergänzung (Betrag, Begründung, Dokument-Upload) erforderlich sein. Erst wenn alle Pflichtfragen und erforderlichen Ergänzungen beantwortet sind, kann der Kunde die Prüfung einreichen.

Rückfragen Business Development oder Admin können Rückfragen zu einzelnen Fragen oder zur gesamten Prüfung stellen. Der Kunde wird per Resend und Portal-Notification informiert und antwortet im Dashboard. Nach Beantwortung einer Rückfrage geht der Fall automatisch in die weitere Prüfung; der Verlauf bleibt vollständig erhalten.

Frageversionierung Fragen sind versioniert. Bei Anpassung eines Fragetextes wird die Version erhöht. Historische Antworten bleiben über die gespeicherte Frageversion nachvollziehbar. Antworten selbst werden bei Änderung nicht überschrieben, sondern als neue Antwort-Version abgelegt; ältere Versionen bleiben revisionssicher erhalten.

Audit Trail Jede relevante Aktion wird protokolliert: Start, Versand, Antworten, Einreichen, Rückfragen, Antworten auf Rückfragen, interne Beurteilung und Entscheid.

Resend Alle produktiven System- und Kommunikationsmails im Prüfungskontext (Prüfung bereit, Rückfrage, Erinnerung, Antwort eingegangen, Entscheid) laufen über die bestehende Resend-Infrastruktur. Es wird keine parallele E-Mail-Architektur verwendet.

Admin Notifications Bei den Ereignissen Prüfung gestartet, Prüfung eingereicht, Kundenantwort, Rückfrage, Antwort auf Rückfrage und «Entscheid erforderlich» werden alle berechtigten Admins informiert.

Trennung der internen Beurteilung Die interne Beurteilung durch Business Development oder Admin ist eine separate Information und wird dem Kunden nicht angezeigt. Sie fliesst in den Entscheid ein, bleibt aber vom Kundenbereich getrennt.

15

Prüfungsfragen

Der aktuell verwendete, verbindliche Fragenkatalog umfasst sechs Fragen in zwei Kategorien.

Rückwirkend / bestehende Verpflichtungen

  1. Sind Sie privat oder über Freunde Bürgschaften eingegangen?
  2. Besteht ein Covid-19-Kredit, für den Sie persönlich haften?

Zukunftsbezogen 3. Wie sieht die Marktentwicklung in Ihrem Marktsegment aus? 4. Wie kann sich Ihr Auftragsbestand für die nächsten 12 Monate entwickeln? 5. Bestehen Kundenaufträge, welche von Anfang an in die neue AG eingebracht werden? 6. Verfügen Sie über Liquidität für die nächsten 3 Monate für das operative Geschäft?

Versionierung und Historie Fragen sind versioniert. Bei Anpassung eines Fragetextes wird die Version erhöht; historische Antworten bleiben über die gespeicherte Frageversion nachvollziehbar. Antworten werden bei Änderung nicht überschrieben, sondern als neue Antwort-Version abgelegt. Damit bleibt die Historie vollständig nachvollziehbar.

16

Entscheid

Nach abgeschlossener Prüfung folgt der Schritt «Entscheid». Er ist ein eigener, sichtbarer Schritt im Kundenworkflow.

Mögliche Ausgänge

  • positiv
  • negativ
  • weitere Prüfung / Rückfrage

Freigabe der Offerte Nur bei einem positiven Entscheid wird die Offerte freigegeben. Die Offerte wird jedoch nicht automatisch versendet.

Bewusster manueller Versand Der Versand der Offerte erfolgt bewusst manuell durch einen berechtigten Admin. Damit bleibt die Kontrolle über den vertraglichen Einstieg beim Unternehmen, nicht bei einer Automatik.

Trennung Die interne Beurteilung und die Entscheidnotiz sind intern und werden dem Kunden nicht angezeigt. Der Kunde erhält das Ergebnis des Entscheids (positiv / negativ / weitere Prüfung) per Resend und Portal-Notification.

17

Offerten

Offerten werden strukturiert erstellt, versioniert und mit dem Kunden abgestimmt. Sie setzen einen positiven Entscheid voraus.

Hauptleistung

  • AG-Gründung: CHF 2'500 einmalig

Monatlicher Leistungsblock

  • VR-Mandat
  • Buchhaltung
  • Domizil

Diese drei Leistungen werden als zusammenhängender monatlicher Block dargestellt. Damit ist die wiederkehrende Betreuung der Gesellschaft als Einheit abgebildet.

Bestandteile

  • Offerte erstellen mit Positionen
  • Einmalige Hauptleistung (AG-Gründung)
  • Monatlicher Leistungsblock (VR-Mandat, Buchhaltung, Domizil)
  • Versionierung V1, V2, V3
  • manueller Versand durch berechtigten Admin
  • Resend für den Versand
  • Anzeige im Client-Dashboard
  • viewed Tracking (Offerte geöffnet)
  • Rückfrage und Änderungswunsch
  • Revision
  • Annahme und Ablehnung
  • Audit Trail

Versionierung und Snapshot Eine ersetzte Offerte bleibt revisionssicher erhalten. Bei Annahme wird ein verbindlicher Offer Snapshot erfasst, der die vertragliche Grundlage zum Zeitpunkt der Annahme einfriert. Aus diesem Snapshot entsteht später der Vertrag.

Der Versand erfolgt bewusst manuell. Eine automatisch versendete Offerte gibt es nicht.

18

Verträge

Ein Vertrag entsteht erst nach angenommener Offerte. Er übernimmt exakt die bestätigte Quote-Version.

Entstehung

  • Vertrag aus angenommener Offerte
  • Übernahme der bestätigten Quote-Version
  • Vertrag übernimmt die eingefrorene vertragliche Grundlage

Status

  • Draft
  • Review
  • Approved
  • Sent for Signature
  • Viewed
  • Signed

Nachvollziehbarkeit Jeder Vertrag verfügt über eine Dokumentversion, einen Audit Trail und einen Dokumentenhash. Archivierung stellt sicher, dass frühere Versionen verfügbar bleiben.

Es wird keine alte, parallele Vertragslogik dokumentiert. Es gibt nur den beschriebenen Weg aus der angenommenen Offerte.

Konkrete interne Signatur-Security-Details werden nicht veröffentlicht.

19

Digitale Signatur

Die elektronische Signatur wird als geschlossener, nachvollziehbarer Prozess abgebildet. Sie setzt einen versendeten Vertrag voraus.

Signaturprinzip

  • Vorname
  • Nachname
  • E-Mail
  • OTP via Resend (Einmalcode an die hinterlegte E-Mail)
  • Consent (explizite Zustimmung zu einem festgelegten Consent-Text)
  • sichtbare elektronische Signatur (bestätigter Vor- und Nachname als Darstellung)
  • SHA-256 (Dokumentenhash der finalen, eingefrorenen Vertragsversion)
  • Zertifikat (erzeugtes Signaturzertifikat mit Zertifikats-Hash)
  • QR-Verifikation (öffentliche Verifikations-ID und QR-Code)
  • finales PDF (signiertes Dokument)

Ablauf

  • Vertragsprüfung
  • Festlegung der Unterzeichner
  • OTP-Versand via Resend
  • OTP-Verifikation
  • Consent-Erfassung
  • Signatur
  • Zeitstempel
  • Audit Trail
  • Dokumentenhash
  • Zertifikat
  • Verifikationsseite mit QR-Code
  • finales signiertes PDF

Es wird keine Aussage über die rechtliche Signaturstufe gemacht. Die massgebliche rechtliche Einordnung ergibt sich aus dem jeweiligen Vertrag und den anwendbaren Bestimmungen.

20

Unternehmen aufbauen

Nach dem signierten Vertrag folgt der Schritt «Unternehmen aufbauen». Dieser Schritt kann länger dauern und umfasst die operative Errichtung der Gesellschaft.

Mögliche interne Sub-Schritte

  • Gründungsunterlagen
  • Domizil
  • Verwaltungsrat
  • Buchhaltung
  • Handelsregister
  • administrative Einrichtung
  • operative Vorbereitung

Diese Sub-Schritte müssen nicht alle als Hauptschritte im Client-Fortschritt erscheinen. Im Kunden-Dashboard bleibt «Unternehmen aufbauen» ein zusammenhängender Hauptschritt; die internen Teilfortschritte werden separat geführt.

Statuswechsel Statuswechsel im Aufbauprozess lösen entsprechende Notifications an die berechtigten Admins aus.

21

Aktien übernehmen

«Aktien übernehmen» bleibt der letzte Hauptschritt im Kundenworkflow.

Prinzip

  • Er darf nicht automatisch früh aktiviert werden.
  • Nur fachlich tatsächlicher Fortschritt darf diesen Schritt freischalten.
  • Die Freischaltung erfolgt bewusst manuell durch einen berechtigten Admin.

Eine Finanzierungsgarantie oder eine Garantie für die spätere Aktienübertragung wird nicht abgegeben. Die Übertragung erfolgt ausschliesslich bei Erfüllung der vertraglich definierten Voraussetzungen.

22

Kundenportal

Das Kundenportal ist die zentrale Anlaufstelle für bestehende Kunden. Es zeigt den tatsächlichen Stand entlang des verbindlichen Kundenworkflows.

Sichtbare Hauptelemente

  • aktueller Hauptstatus
  • aktueller Schritt
  • offene Aktion
  • nächste Aktion
  • Prüfung
  • Offerte
  • Vertrag
  • Signatur
  • Unternehmen aufbauen
  • Aktien übernehmen

Bereiche

  • Übersicht über Projekt und Status
  • Prüfung
  • Leistungen
  • Dokumente
  • Verträge
  • Offerten mit Detailansicht
  • Rechnungen
  • Termine
  • Nachrichten
  • Support
  • Unternehmensdaten
  • Einstellungen

Prüfung im Kunden-Dashboard Bei der Prüfung sieht der Kunde:

  • offene Fragen
  • beantwortete Fragen
  • Rückfragen
  • Antworten
  • Fortschritt
  • Zeitpunkt der Übermittlung

Kunden können Offerten einsehen, darauf reagieren, Dokumente abrufen und Termine verwalten. Alle Aktionen sind mit den internen Prozessen verbunden.

23

Admin-Dashboard

Das Admin-Dashboard bündelt die interne Steuerung des gesamten Kundenworkflows.

Hauptreiter

  • Übersicht
  • Prüfung
  • Offerten
  • Verträge
  • Signaturen
  • Unternehmen aufbauen
  • Dokumente
  • Kommunikation
  • E-Mails
  • Support
  • Historie

Prüfung Der Reiter «Prüfung» ist neu und zentral. Er zeigt alle Prüfungsfälle mit Status, Antworten, Rückfragen und Entscheid. Admins können eine Prüfung starten, Rückfragen stellen, die interne Beurteilung ergänzen und den Entscheid setzen.

Customer 360 View Die Customer-360-Ansicht wurde aktualisiert. Sie fasst für einen Kunden den gesamten Verlauf zusammen: Lead, Prüfung, Entscheid, Offerten, Verträge, Signaturen, Aufbau, Kommunikation, Dokumente und Historie.

24

Notifications

AG READY verwendet persistente interne Notifications, um relevante Ereignisse zuverlässig zu kommunizieren. Bei den folgenden Ereignissen werden alle berechtigten Admins informiert:

Ereignisse

  • Prüfung gestartet
  • Prüfung eingereicht
  • Kundenantwort
  • Rückfrage
  • Antwort auf Rückfrage
  • Entscheid erforderlich
  • positiver Entscheid
  • negativer Entscheid
  • Offerte versendet
  • Offerte geöffnet
  • Offerte angenommen
  • Vertrag erstellt
  • Vertrag versendet
  • Vertrag signiert
  • Statuswechsel im Aufbauprozess

Notifications bleiben so lange verfügbar, bis sie bearbeitet oder gelesen sind. Damit gehen keine wichtigen Ereignisse verloren, auch wenn ein Mitarbeiter nicht unmittelbar online ist.

25

Statusmodell

Die Plattform unterscheidet zwischen einem sichtbaren Hauptstatus und internen Workflow-States. Das dokumentierte Statusmodell entspricht der tatsächlichen Implementierung.

Sichtbarer Hauptstatus

  • Erstgespräch
  • Prüfung
  • Entscheid
  • Offerte
  • Vertrag
  • Unternehmen aufbauen
  • Aktien übernehmen

Lead-Lifecycle (intake_status, tatsächlich implementiert)

  • IMPORTED — Rohdaten aus wirtschaftsdaten.ch
  • SELECTED_FOR_ENRICHMENT — zur Anreicherung ausgewählt
  • ENRICHING — Anreicherung läuft
  • ENRICHED — angereichert, zur Prüfung
  • NEEDS_REVIEW — manuelle Prüfung erforderlich
  • QUALIFIED — qualifiziert
  • REJECTED_NO_PHONE — keine Telefonnummer, nicht qualifiziert
  • ENRICHMENT_FAILED — Anreicherung fehlgeschlagen
  • LEADPOOL — freigegeben für Business Development

Interner Workflow-State (Beispiele)

  • Prüfungsfall: draft, sent_to_customer, in_progress, submitted, in_review, followup_open, decision_required, approved, rejected, closed
  • Offerte: draft, sent, viewed, accepted, rejected, superseded
  • Vertrag: draft, review, approved, sent_for_signature, viewed, signed
  • Signatur: draft, ready_for_signature, sent_for_signature, viewed, partially_signed, signed, declined, expired, cancelled

Übergänge

  • zulässige Übergänge sind definiert
  • wer Übergänge auslösen darf ist rollenbasiert (Business Development vs. Admin / Super Admin)
  • automatische Übergänge: Eingang einer Kundenantwort, Signatur abgeschlossen, Annahme einer Offerte
  • bewusst manuelle Übergänge: Entscheid, Offertenversand, Vertrag versenden, Freischaltung «Aktien übernehmen»

Es werden keine veralteten Statuswerte weitergeführt. Das Statusmodell ist synchron zur Implementierung.

26

Audit Trail

Jede relevante Aktion speichert einen Audit-Eintrag. Damit bleibt der gesamte Kundenworkflow revisionssicher nachvollziehbar.

Felder je Audit-Eintrag

  • timestamp
  • actor_type
  • actor_user_id
  • actor_name
  • action
  • object_type
  • object_id
  • old_status
  • new_status
  • reference_id

Audit-Einträge werden nicht nachträglich überschrieben. Sie bilden die Grundlage für die Customer-360-Historie und für die interne Nachvollziehbarkeit.

27

Testmodus

Admins müssen den gesamten Prozess mit einem klar markierten Testkunden testen können.

Testflow Erstgespräch → Prüfung → Kunde antwortet → Rückfrage → Kunde antwortet → Entscheid → Offerte → Vertrag → Signatur → Unternehmen aufbauen → Aktien übernehmen

Prinzipien

  • Der Testkunde ist klar markiert.
  • Dabei dürfen keine echten, fremden Kunden verändert oder benachrichtigt werden.
  • Der vollständige Workflow kann ohne Risiko für produktive Kundendaten durchlaufen werden.

Damit lässt sich der implementierte Prozess End-to-End prüfen, bevor er produktiv verwendet wird.

28

Multi-Tenancy und Security

Die Plattform trennt die Datenbereiche der Kunden konsequent.

Massnahmen

  • Row-Level Security (RLS) für alle kundenbezogenen Entitäten
  • Tenant Isolation über die User-/Customer-Zuordnung
  • sichere User-/Customer-Zuordnung
  • keine client_id aus unsicheren Frontend-Parametern
  • serverseitige Ausführung kritischer Aktionen
  • Idempotenz bei wiederholten Aufrufen
  • keine Duplikate bei Offerte, Vertrag, Prüfung oder Signatur

Implementierungsdetails, die die Security schwächen könnten, werden bewusst nicht veröffentlicht.

29

Resend

Alle produktiven System- und Kommunikationsmails laufen über die bestehende Resend-Infrastruktur.

Ereignisse

  • Prüfung bereit
  • Rückfrage
  • Erinnerung
  • Antwort eingegangen
  • Entscheid
  • Offerte
  • Vertrag
  • Signatur (OTP)
  • Onboarding bzw. weitere Folgeprozesse

Es wird keine parallele Base44-E-Mail-Architektur verwendet. Resend ist der massgebliche Provider für den gesamten ausgehenden System- und Kommunikationsversand.

Es werden keine internen API-Details, Tokens oder Secrets veröffentlicht.

30

Historische Daten

Bestehende historische Daten werden nicht nachträglich überschrieben.

Geschützte Bestände

  • bestehende Offerten
  • signierte Verträge
  • Zertifikate
  • Rechnungen
  • alte Kundenvorgänge

Prinzip Die neue Workflow-Logik gilt für neue und aktive Prozesse. Historische Bestände bleiben revisionssicher erhalten. Damit bleibt die Nachvollziehbarkeit auch für in der Vergangenheit abgeschlossene Vorgänge gewährleistet.

31

Rechnungen und Zahlungen

Die Abrechnung unterscheidet zwischen einmaligen und wiederkehrenden Leistungen.

Einmalige Leistungen Einmalige Leistungen wie die AG-Gründung (CHF 2'500) werden über klassische Rechnungen abgerechnet.

Wiederkehrende Leistungen Wiederkehrende Leistungen aus dem monatlichen Block (VR-Mandat, Buchhaltung, Domizil) werden über wiederkehrende Zahlungen abgewickelt.

Flow SIGNED, Rechnung, Zahlung, Subscription, Active.

32

Medienbibliothek

Die Medienbibliothek verwaltet Bild- und Medienassets zentral.

Funktionen

  • Zentrale Ablage für Bilder
  • Bezug über eine lizenzierte Bildquelle
  • Duplikatsschutz über stabile IDs
  • Nutzungsnachverfolgung
  • Zuordnung zu Beiträgen
  • Freigabe- und Prüfstatus

Damit bleiben Bildauswahl konsistent und nachvollziehbar.

33

Datenmodell

Das Datenmodell ist abstrahiert dargestellt. Es zeigt die zentralen Entitäten und ihre Beziehungen.

Entitäten

  • Lead
  • EnrichmentRun (Anreicherungs-Audit)
  • Customer
  • ReviewCase (Prüfungsfall)
  • ReviewQuestion (Fragenkatalog)
  • ReviewAnswer (Antworten)
  • ReviewFollowup (Rückfragen)
  • Quote (Offerte)
  • Contract (Vertrag)
  • ContractVersion (Vertragsversion)
  • SignatureRequest (Signaturanfrage)
  • Signer (Unterzeichner)
  • Invoice
  • Subscription
  • User
  • Activity (Audit Trail)
  • Notification
  • Article
  • Author

Beziehungen Ein Lead kann zu einem Customer werden. Einem Customer sind Prüfung, Offerten, Verträge, Rechnungen und Zahlungen zugeordnet. Die Prüfung besteht aus einem Fall, versionierten Fragen, Antworten und Rückfragen. Ein Vertrag entsteht aus einer angenommenen Offerte und führt zu einer Signaturanfrage mit Unterzeichnern. Aktivitäten und Notifications begleiten den gesamten Lebenszyklus. Artikel und Autoren bilden die redaktionelle Ebene.

Es werden keine internen Datenbank-IDs, Secrets oder technischen Schwachstellen veröffentlicht.

34

Automatisierungen

AG READY nutzt automatisierte Prozesse, um wiederkehrende Aufgaben zuverlässig auszuführen.

Beispiele

  • Content- und SEO-Automatisierung
  • Lead-Import und Qualitätsprüfung
  • Benachrichtigungen bei relevanten Ereignissen
  • Erinnerungen an Rückrufe und Termine
  • Automatische Aufgaben bei Offertenreaktionen
  • Automatische Statusübergänge bei Kundenantworten und Signaturabschluss

Automatisierungen sind so gestaltet, dass sie den Menschen entlasten, ohne die Kontrolle abzugeben. Sensible Schritte — Entscheid, Offertenversand, Freischaltung «Aktien übernehmen» — bleiben bewusst manuell und durch Freigaben abgesichert.

35

Integrationen

AG READY integriert ausgewählte externe Dienste auf einer klaren Abstraktionsschicht.

Bereiche

  • Bildquelle für Medien
  • Datenquelle für Unternehmensereignisse
  • Zahlungsverkehr für wiederkehrende Leistungen
  • Publishing-Dienst für Social Media
  • KI-gestützte Texterstellung
  • Resend als E-Mail- und OTP-Provider

Es werden keine internen API-Details, Tokens oder Secrets veröffentlicht. Integrationen sind so gekapselt, dass einzelne Dienste austauschbar bleiben.

36

Sicherheit

Die Sicherheit der Plattform beruht auf mehreren Prinzipien.

Massnahmen

  • Authentifizierung für alle internen Bereiche
  • Rollenbasierter Zugriff
  • Geschützte Adminbereiche
  • Geschütztes Business Development
  • Serverseitige API-Authentifizierung
  • Audit Trail für relevante Aktionen
  • Row-Level Security und Tenant Isolation
  • Trennung öffentlicher und interner Bereiche
  • Idempotenz bei kritischen Aktionen

Implementierungsdetails, die die Security schwächen könnten, werden bewusst nicht veröffentlicht.

37

SEO und Indexierung

Die SEO- und Indexierungsstrategie verfolgt das Ziel nachhaltiger organischer Sichtbarkeit.

Bestandteile

  • Dynamische Sitemap
  • robots.txt
  • Schema.org mit Article, Person, Organization, Service und Breadcrumbs
  • Canonical-Tags
  • hreflang für mehrsprachige Versionen
  • Content Cluster
  • Saubere Meta-Daten

Öffentliche Inhalte sind crawler-gerecht aufbereitet. Geschützte Bereiche sind von der Indexierung ausgeschlossen.

38

E-E-A-T

E-E-A-T steht für Experience, Expertise, Authoritativeness und Trustworthiness. AG READY verfolgt diese Prinzipien bewusst.

Umsetzung

  • Klare Autorenschaft mit echten Fachexperten
  • Fachartikel mit Quellen und nachvollziehbaren Informationen
  • Eindeutige Unternehmensidentität
  • Strukturierte Person- und Organization-Daten
  • Transparente Rechtstexte
  • Autorenprofile mit Verknüpfung zu Beiträgen
  • Konsistente Verknüpfung von Inhalt, Autor und Leistung

Ziel ist Vertrauen durch Transparenz und fachliche Tiefe, nicht durch übertriebene Selbstdarstellung.

39

LLM und AI Discoverability

AG READY bereitet Inhalte so auf, dass sie auch für KI-gestützte Systeme auffindbar und interpretierbar sind.

Bestandteile

  • Entity Graph mit Organisation, Marken und Leistungen
  • Strukturierte Daten nach Schema.org
  • llms.txt mit kompakter Plattformbeschreibung
  • Crawler-gerechte Inhalte
  • Klare Autoren- und Organisationszuordnung
  • Verknüpfte Services und Content Cluster

Es wird nicht behauptet, dass bestimmte LLMs die Inhalte indexieren. Die Massnahmen verbessern jedoch die strukturelle Auffindbarkeit.

40

Plattformbetrieb

Der Betrieb der Plattform ist auf Stabilität und kontinuierliche Weiterentwicklung ausgelegt.

Aspekte

  • Bereitstellung über eine verwaltete Plattform
  • Versionierte Weiterentwicklung
  • Trennung von öffentlichem und internem Bereich
  • Nachvollziehbare Änderungen
  • Laufende Pflege von Inhalten und Strukturen
  • Synchronisation von Dokumentation und Implementierung

Betriebliche Interna, die Rückschlüsse auf Schwachstellen zulassen könnten, werden nicht veröffentlicht.

40.1

Performance & Ladeverhalten

Die öffentliche Landing-Page ist auf schnelles und stabiles Laden auch auf langsamen Mobilverbindungen ausgerichtet. Die Massnahmen konzentrieren sich auf den kritischen Render-Pfad, die Grösse des initialen JavaScript-Bundles, die Schriftauslieferung, das Analytics-Loading und die Bildauslieferung — nicht auf Lighthouse-Optimierung um jeden Preis.

Ausgangslage und Ergebnis

  • Mobile Performance: ca. 45 → 87 / 100
  • Desktop Performance: 91 / 100
  • Haupt-JavaScript-Bundle: ca. 552 KiB → ca. 203 KiB
  • Initial-Payload: ca. 6,65 MB → deutlich reduziert (5-MB-Bild entfällt, GTM nur noch nach Einwilligung)

Implementierte Massnahmen

  • Route-Code-Splitting: nur die Landing-Page ist eager; Admin-, Sales-, Portal- und Partner-Routen laden erst bei Aufruf (React.lazy + Suspense).
  • Render-Blocker entfernt: keine globale Loading-Sperre mehr auf der Landing-Page.
  • Google Fonts: preconnect, nicht-blockierendes preload/swap, reduzierte Gewichte (Inter 400/500/600/700, Sora 600/700/800), display=swap.
  • Bilder: responsives WebP über die Plattform-Medienpipeline statt unoptimierter Grossdateien; Artikel- und Wissenskarten verwenden fill.
  • Below-the-fold Daten laden erst im Idle-Zustand (requestIdleCallback); doppelte Author-Requests über einen geteilten Cache dedupliziert; Author-Beiträge parallel geladen.
  • Chat-Widget lädt erst im Idle-Zustand oder bei erster Interaktion (LazyChatWidget).
  • Google Tag Manager (gtag.js) wird erst nach erteilter Analytics-Einwilligung geladen; Erstbesucher ohne Einwilligung laden es nicht. Events gehen nicht verloren (dataLayer-Stub).

Bewusst nicht geändert

Content, Layout, Branding, SEO-Inhalte und Funktionalität bleiben unverändert. Keine weiteren Architekturrewrites zur reinen Lighthouse-Optimierung. Ein Self-Hosting der WOFF2-Schriftdateien wurde geprüft, aber nicht umgesetzt, da die Plattform keinen sauberen binären Upload-Pfad dafür bereitstellt.

Verbleibende Bottlenecks

GTM zählt nach Laden weiterhin als „unused JavaScript“ (gtag-bedingt); das eine CSS-Bundle enthält auch Klassen nicht-öffentlicher Bereiche; die mehrsprachigen Content-Dateien bleiben im Bundle. Diese Schritte sind technisch möglich, stehen aber in einem ungünstigen Verhältnis zwischen Aufwand, Risiko (FOUC/Flash) und erwartbarem Gewinn.

41

Roadmap

Die Roadmap zeigt, welche Bereiche von AG READY bereits live sind und welche Themen weiterentwickelt werden. Nur Funktionen, die tatsächlich live sind, sind als aktuell markiert.

Aktuell
  • Marketing & SEO Hub
  • Fachredaktion
  • Lead Import & Enrichment Pipeline
  • Import-Eingang
  • DataForSEO-Anreicherung
  • Qualitätsklassen
  • CSV-Export
  • Lead Management
  • Business Development
  • Prüfung & Entscheid
  • Offerten & Versionierung
  • Kundenportal
  • Verträge & elektronische Signatur
  • Aufbauprozess
  • Notifications
  • Resend-Kommunikation
In Entwicklung
  • Billing & Stripe Subscriptions
  • Weitere Aufbau-Teilschritte
  • Erweiterte Customer-360-Auswertungen
Später
  • Weitere Datenquellen
  • Weitere Integrationen
  • Erweiterte Analytics
  • Weitere Länder und Märkte
42

Changelog

Jeder Eintrag ist einzeln verlinkbar – klicke auf das Link-Symbol neben der Version.

v1.7.0 · Enrichment Engine V224.09.2026Enrichment, V2-Engine, Retrieval-First

Überarbeitete Enrichment-Engine (V2) mit Retrieval-first-Ansatz: Kontaktdaten werden vorrangig aus realen Quellen recherchiert und erst durch ein LLM bewertet und zugeordnet statt generiert. Verarbeitungsstufen: Fast Path (welche Felder fehlen), Domain Discovery, Website Retrieval, Person Resolution, Web Search Fallback, LLM-Resolution/Validierung. Jedes Feld speichert Verification-Status (VERIFIED/FOUND_ON_SOURCE/INFERRED/UNKNOWN) und Confidence (0–1). Strukturierte Failure Reasons (NO_PHONE_FOUND, WEBSITE_OFFLINE u.a.) machen fehlende Ergebnisse auditierbar. Bereits vorhandene hochwertige (VERIFIED/FOUND_ON_SOURCE) Daten werden nicht verschlechtert ("no-deterioration"). Nutzen: höhere Datenqualität, nachvollziehbare Herkunft jedes Felds und geringere Halluzinationsgefahr bei Kontaktdaten.

v1.7.2 · Parallelisierung & Performance24.09.2026Enrichment, Performance, Parallelisierung

Kontrollierte Parallelisierung der Enrichment-Verarbeitung: begrenzte Lead-Concurrency, paralleles Website-Retrieval mehrerer Unterseiten gleichzeitig sowie Retry-/Timeout-Handling bei externen Requests. Dadurch werden grössere Lead-Bestände schneller und stabiler verarbeitet, während API- und LLM-Last kontrolliert bleibt (Concurrency-Limit, Caching, bewusste Stufenfolge). Nutzen: kürzere Laufzeiten bei grösseren Durchläufen, geringere externe Kosten und stabileres Verhalten auch bei einzelnen fehlgeschlagenen Requests.

v1.7.3 · Altbestand-Backfill24.09.2026Enrichment, Backfill, Altbestand

Neuer Admin-Prozess "Altbestand anreichern": bestehende, noch nicht oder nur teilweise angereicherte Leads können automatisch nachbearbeitet werden, ohne erneut importiert zu werden. Der Backfill nutzt die vorhandene Enrichment Engine V2 und verarbeitet die Leads autonom über die zentrale Queue und die Worker. Bereits vorhandene gute Daten bleiben erhalten. Wichtig: Der bestehende Lead Pool wird dadurch nicht verändert — Lead-Pool-Leads sind vom Backfill ausdrücklich ausgeschlossen. Nutzen: qualitative Nachbearbeitung des historischen Bestands ohne Neuimport und ohne Berührung des produktiven Lead Pools.

v1.7.4 · Enrichment Queue & Worker24.09.2026Enrichment, Queue, Worker, Automation

Persistente Enrichment-Queue mit zentralen Feldern (queue_status, queue_priority, queued_at, enrichment_started_at, queue_lock_expires_at, enrichment_attempt_count, next_retry_at). Priorisierung (1 = neue wirtschaftsdaten.ch-Leads bis 4 = historischer Backfill), kontrollierte Batch-Verarbeitung, Versuchszähler mit konfigurierbarem Maximalwert, Retry-Handling mit Sperrverfall (abgestürzte Worker geben Leads nach Lock-Ablauf frei), automatische Worker-Verarbeitung (Schedule alle 5 Min.) sowie manuelles Starten eines Worker-Laufs durch Admins. Nutzen: zuverlässige, autonome und nachvollziehbare Abarbeitung auch grösserer Mengen mit klarem Status je Lead.

v1.7.5 · Automation / Enrichment Admin-Dashboard24.09.2026Admin, Monitoring, Enrichment

Neues/erweitertes Admin-Monitoring für die Enrichment-Automation: Queue-Grösse, aktuell verarbeitete Leads, Tagesstatistiken (verarbeitet, erfolgreich, Lead-Pool-Conversion, Needs Review, Partial, Failed) sowie Performance-Kennzahlen (Median/P90-Laufzeit, aktive Worker, Concurrency). Dazu operative Werkzeuge (Worker starten, Reconciliation, Dedup, Quality-Gate, Backfill). Nutzen: transparente Steuerung und Kontrolle der autonomen Anreicherung durch die Administration.

v1.7.6 · Live-Monitoring des Backfills24.09.2026Admin, Monitoring, Backfill, Live

Live-Monitoring des laufenden Altbestand-Backfills: Fortschrittsanzeige (verarbeitet/gesamt in %), aktive Worker, Live-Queue mit Status, Versuchen, Deep-Search-Status, Laufzeit und Failure Reason pro Lead, automatische Dashboard-Aktualisierung. Es ist rein Monitoring — Lead-Pool- und Enrichment-Regeln werden dadurch nicht verändert. Nutzen: belastbare Nachvollziehbarkeit des Fortschritts und frühzeitiges Erkennen von Blockaden.

v1.7.7 · Bestands-Cleanup & Dublettenprüfung24.09.2026Admin, Dedup, Cleanup

Werkzeuge für das Bestands-Cleanup: Bestandsanalyse, Duplicate-Dry-Run und kontrolliertes Zusammenführen bestätigter Dubletten. Historien und vorhandene hochwertige Daten bleiben beim Merge erhalten; unterschiedliche Event-Datensätze derselben Firma (gleiche UID, anderes Ereignis) werden nicht automatisch als Dublette behandelt, sondern als eigenständige Datensätze erhalten; nur unsichere Treffer gehen in den Admin-Review. Nutzen: nachvollziehbare, sichere Dublettenbereinigung ohne Datenverlust.

v1.7.8 · Quality-Gate-Werkzeuge24.09.2026Admin, Quality Gate

Striktes, serverseitiges Quality-Gate für die Lead-Pool-Freigabe (vollständige Verifikation von Firma, Telefon, Website, E-Mail, Kontaktperson) mit zugehörigen Werkzeugen: Quality-Gate-Dry-Run und Revalidierungsmöglichkeit für Administratoren, sodass die Qualitätsprüfung vorhandener Datensätze kontrolliert und ohne produktive Änderung vorab geprüft werden kann. Die bestehenden Lead-Pool-Regeln werden dadurch nicht verändert. Nutzen: kontrollierte, nachvollziehbare Qualitätssicherung vor produktiven Änderungen.

v1.7.9 · wirtschaftsdaten.ch Reconciliation24.09.2026Integration, Reconciliation, wirtschaftsdaten.ch

Zusätzlicher Pull-/Reconciliation-Prozess zwischen wirtschaftsdaten.ch und AG READY als Sicherheitsmechanismus zum bestehenden Push: fehlende Events können automatisch erkannt und importiert werden, mit Pagination über alle Seiten, Watermark-/Sync-Mechanismus und Idempotenz über transfer_key gegen Doppelimporte. Push und Pull ergänzen sich. Status: implementiert; der produktive Sync-Endpoint wird aktuell bei Ratenbegrenzung noch stabilisiert (in Umsetzung). Nutzen: höhere Robustheit der Datenübernahme und Schutz gegen verpasste Events.

v1.7.10 · wirtschaftsdaten.ch API-Integration24.09.2026Integration, API, wirtschaftsdaten.ch

Integration des ag-ready/events-Endpoints von wirtschaftsdaten.ch mit API-Key-basierter Authentifizierung (serverseitig als Secret gespeichert). Verarbeitung von BANKRUPTCY-, LIQUIDATION- und DELETION-Events mit Übernahme der relevanten Unternehmens- und Ereignisinformationen; ein transfer_key stellt die eindeutige Zuordnung und Idempotenz sicher. Keine API-Secrets oder Schlüssel werden veröffentlicht. Nutzen: strukturierte, idempotente Übernahme relevanter Handelsregister-Ereignisse in den AG-READY-Bestand.

v1.7.11 · Reconciliation Monitoring & Fehlerbehandlung24.09.2026Admin, Monitoring, Reconciliation

Reconciliation-Monitoring und Fehlerbehandlung im Admin-Dashboard: HTTP-Status, Sync-Status, erhaltene/bereits bekannte/neue Events, importierte Leads, API-Requests/Seiten, Laufzeit und Importfehler. Der Sync-Watermark (last_successful_sync) wird nur bei einem vollständig fehlerfreien Lauf fortgeschrieben; bei Fehlern bleibt er stehen, sodass fehlende Events beim nächsten Lauf erneut gezogen werden. Nutzen: belastbare Nachvollziehbarkeit jedes Sync-Laufs und Schutz gegen stillen Datenverlust.

v1.7.12 · Lead-Pool-Schutz beim Backfill24.09.2026Enrichment, Backfill, Lead-Pool-Schutz

Der Altbestand-Backfill schliesst bestehende Lead-Pool-Leads (intake_status = leadpool) ausdrücklich aus — sie werden durch den Backfill nicht erneut angereichert. Bestehende Claims und Ownership bleiben unverändert, ebenso die BD-Berechtigungen und die Lead-Pool-Logik. Nutzen: klare Trennung zwischen Nachbearbeitung des Altbestands und dem produktiven Lead Pool; keine unerwünschten Veränderungen freigegebener Leads.

v1.7.13 · Enrichment-Datenmodell & Nachvollziehbarkeit24.09.2026Datenmodell, Enrichment, Audit

Erweitertes Enrichment-Datenmodell für bessere Nachvollziehbarkeit: Verification-Status und Confidence je Feld (Telefon, Website, E-Mail, Kontaktperson), Quelleninformation (source_url) je angereichertem Feld, Verifikationszeitpunkt, normalisierte Schweizer Telefonnummer, strukturierte Kontaktperson (Vorname, Nachname, Funktion) und strukturierte Failure Reasons. Nutzen: jede Anreicherung ist später feldbezogen nachvollziehbar, was Vertrauen, Audit-Fähigkeit und Datenqualität erhöht.

v1.7.14 · Lead-Weitergabe (Transfer)24.09.2026Sales, Business Development, Lead-Transfer

Neue serverseitige Lead-Weitergabe (transferLead) für Business Development: ein BD-Mitarbeiter kann eigene Leads an einen Kollegen (Business Development/Admin) übergeben — mit Kollegen-Auswahl, optionaler Notiz, atomarer Neuzuweisung, Zuordnung der Timeline an den neuen Owner und Eintrag in der Lead-Historie. Admins können jeden Lead weitergeben, BD nur eigene; Lead-Pool-, Claim-, RLS- und Quality-Gate-Logik bleiben unangetastet. Nutzen: saubere, nachvollziehbare Lead-Übergabe innerhalb des Teams ohne Umweg über den Lead Pool.

v1.6.024.09.2026RBAC, Row-Level Security, Leadpool, Lead-Übernahme, Audit Trail, Rollen-Redirect, Datenabtrennung

Strikte Rollentrennung zwischen Administration (Super Admin / Admin) und Business Development auf Daten- und Backend-Ebene. Row-Level Security für Leads verschärft: Business Development sieht ausschliesslich die eigenen, übernommenen Leads — keine unassigned oder fremden Datensätze mehr. Der Leadpool liefert vor der Übernahme nur noch fünf Felder (Firma, Branche, Kanton, Lead Score, Datenstand), serverseitig projiziert; vertrauliche Kontaktdaten werden erst nach der Übernahme sichtbar. Atomare, race-condition-sichere Lead-Übernahme mit konfigurierbarem Active-Lead-Limit pro Mitarbeiter. Serverseitige Eigentumsprüfung bei jedem Lead-Aufruf inklusive Audit-Eintrag (Lead geöffnet, Kontaktdaten eingesehen). Zentrales, unveränderliches Audit- und Lead-Historie-Logging aller Aktionen (Übernahme, Statuswechsel, Kontaktversuche, Notizen, Termine, Prüfung gestartet) — für Business Development nicht einsehbar, ausschliesslich der Administration vorbehalten. Statuswechsel laufen über eine serverseitige Funktion mit Pflichtfeld-Validierung (Rückruf, Wiedervorlage, Termin, Kein Interesse, Nicht geeignet, fehlerhafte Kontaktdaten) und Audit-Erfassung alt→neu. Automatischer Login-Redirect: Super Admin / Admin → Admin-Bereich, Business Development → Sales-Bereich. Admin-Routen rollenbasiert abgesichert; Business-Development-Navigation auf die zulässigen Bereiche eingeschränkt. Unberechtigte Zugriffsversuche werden als Security-Ereignis protokolliert.

v1.5.218.09.2026Performance, Ladeverhalten, Fonts, GTM, Bundle, Bildoptimierung

Performance- und Ladeverhalten-Optimierung der öffentlichen Landing-Page. Render-Blocker entfernt: die globale Loading-Sperre (Auth/Public-Settings), die die gesamte App inkl. Landing-Page im Spinner hielt, wurde abgebaut. Route-Code-Splitting via React.lazy + Suspense — nur die Landing-Page ist eager, alle Admin-, Sales-, Portal- und Partner-Routen laden erst bei Aufruf (entfernt three.js, recharts, react-leaflet, react-quill, jspdf, framer-motion aus dem initialen Bundle; Haupt-JS-Bundle von ca. 552 KiB auf ca. 203 KiB reduziert). Google Fonts von render-blockierendem CSS-@import auf preconnect + nicht-blockierendes preload/swap umgestellt, Font-Gewichte von 11 auf 6 reduziert (Inter 400/500/600/700, Sora 600/700/800), display=swap. 4,96 MB unoptimiertes Office-Bild ersetzt durch responsives WebP via Medienpipeline (serviert in gerenderter Grösse); Artikel- und Wissenskarten-Bilder auf fill gestellt. Below-the-fold Daten (Team, Author, FAQ, Artikel) laden erst im requestIdleCallback; doppelte Author-Requests über geteilten Cache dedupliziert; KnowledgeSection lädt drei Author-Beiträge parallel statt sequenziell. Chat-Widget (inkl. chatConfig) per LazyChatWidget erst im Idle/Interaktion geladen. Google Tag Manager (gtag.js, ca. 167 KiB) wird erst nach erteilter Analytics-Einwilligung geladen — Erstbesucher ohne Einwilligung laden es nicht; dataLayer-Stub stellt sicher, dass keine Events verloren gehen. Ergebnis (verifiziert): Mobile Performance ca. 45 → 87, Desktop 91.

v1.5.110.09.2026Leadpool, CSV-Import

Leadpool-Karten zeigen neu «Im System seit» mit Datum und Uhrzeit (imported_at bei wirtschaftsdaten.ch-Importen, sonst created_date). CSV-Import erzwingt die Leadpool-Mindestanforderung: nur Leads mit Telefonnummer gelangen in den Leadpool; Leads ohne Telefon werden automatisch nach «Zur Prüfung» (needs_review) einsortiert, auch wenn die CSV den Status leadpool angibt.

v1.501.09.2026Lead Import, Import-Eingang, Enrichment Agent V2, DataForSEO, Qualitätsklassen, CSV-Export, Leadpool

Neuer verbindlicher Lead-Lifecycle: wirtschaftsdaten.ch → Import-Eingang → manuelle Auswahl → Enrichment Agent V2 (DataForSEO primär, Gemini Websearch Fallback) → Matching & Validierung → Qualitätsklasse A–D → Leadpool → Business Development. Importierte Unternehmen sind KEINE definitiven Sales-Leads. Harte Mindestanforderung Telefonnummer; ohne Telefon = REJECTED_NO_PHONE. Trennung von Original- und Enrichment-Daten (original_/enriched_). Keine erfundenen Kontaktdaten. Serverseitiger CSV-Export mit UTF-8-BOM, Varianten (alle/gefiltert/ausgewählt/angereichert/qualifiziert/mit Telefon/ohne Telefon), Audit Logging. Neues Statusmodell intake_status (IMPORTED … LEADPOOL). EnrichmentRun-Audit je Lauf.

v1.401.09.2026Prüfung, Entscheid, Bescheid, Intervention, Offertenfreigabe, Fortschrittsanzeige

Trennung von internem Entscheid und Kunden-Bescheid: der Entscheid wird intern gesetzt (notice_pending) und erst manuell als Bescheid über Resend versendet. Bei negativem Bescheid kann der Kunde im Portal intervenieren (Stellungnahme + Dokumente); Admin prüft die Intervention und erlässt einen versionierten Folgeentscheid (negativ bestätigt oder auf positiv geändert). Offerten werden erst nach gesendetem positivem Bescheid freigegeben (canCreateQuote-Gate im QuoteBuilder). Fortschrittsanzeige (computeLifecycle) als einzige fachliche Single Source of Truth aus echten Backend-States — kein paralleler Status. Neue Backend-Funktionen sendReviewNotice, submitReviewIntervention, processReviewIntervention; decideReview versendet keine Kundenmail mehr.

v1.301.09.2026Prüfung, Entscheid, Offertenlogik, Signatur, Aufbau, Aktienübernahme

Verbindlicher 7-Schritt-Kundenworkflow (Erstgespräch → Prüfung → Entscheid → Offerte → Vertrag → Unternehmen aufbauen → Aktien übernehmen). Prüfung mit versioniertem Fragenkatalog, Rückfragen, Audit Trail. Neue Offertenlogik (AG-Gründung CHF 2’500 + monatlicher Block VR-Mandat/Buchhaltung/Domizil). Vertrag aus angenommener Offerten-Version. Elektronische Signatur mit OTP via Resend, Consent, SHA-256, Zertifikat und QR-Verifikation. Statusmodell, Rollen und Notifications synchron zur Implementierung dokumentiert.

v1.201.08.2026Kundenportal, Verträge, Notifications

Einführung des Kundenportals, vertragliche Prozesse und persistente interne Benachrichtigungen.

v1.101.06.2026Lead Management, Business Development, Offerten

Lead Workspace, Lead-Zuweisung, versionierte Offerten mit Rückfrage- und Revisionslogik.

v1.001.03.2026Website, SEO Hub, Redaktion

Öffentliche Website, SEO Landingpages, Fachredaktion und erstes Content-Setup.

AG READY kennenlernen

Vereinbaren Sie ein kostenloses Erstgespräch und erleben Sie, wie eine Schweizer Aktiengesellschaft ohne Eigenkapital strukturiert wird.

Wenn Sie eine Website, eine Web-App, eine Softwarearchitektur inklusive API oder eine vollautomatische Social-Media-Engine wünschen, können Sie gerne direkt über LinkedIn mit mir in Kontakt treten.