01
Route einordnen
Eine explizite Pfadpolitik entscheidet, ob eine Seite überhaupt einen positiven Kontext erhält.
Eigenes System und Process Proof · kein Kundenresultat
Der mu-digital Sales Assistant: kontrollierte Antworten, klare Owner und sichere Grenzen
Ein technischer Einblick in Policy, Antwortstruktur, Fallback und menschliche Übergabe – ohne interne Prompts, private Daten oder Erfolgsbehauptung offenzulegen.
NutzerfrageIntent und Route
→Policyerlaubt oder begrenzt
→Antwortstrukturiert
→Handoffmenschlich
Direkte Antwort
Das System beweist Kontrolle – nicht Autonomie.
Der Sales Assistant ist ein eigenes produktives System. Er ordnet nur freigegebene Seiten positiv ein, begrenzt Antwort und CTA, verarbeitet Eingaben serverseitig und nutzt bei Fehlern einen deterministischen Fallback. Daraus folgt weder ein Kunden-AI-Case noch ein CRM-, Beratungs- oder Ergebnisclaim.
Vier Kontrollschichten
Von der Frage bis zur menschlichen Übergabe bleibt jede Entscheidung sichtbar.
02
Antwort strukturieren
Ausgaben und Handlungsoptionen werden auf ein kontrolliertes Format und erlaubte CTAs begrenzt.
03
Grenzen durchsetzen
Serverprüfung, Eingabelimits und ein deterministischer Fallback verhindern offene Versprechen.
04
Menschlich übergeben
Unsicherheit und projektspezifische Entscheidungen enden in einem begrenzten Handoff statt Autonomie.
Daten- und Inhaltsquellen
Öffentliche Seiteninhalte werden durch eine feste Policy begrenzt.
Das System arbeitet mit freigegebenen Websitekontexten, einer serverseitigen Routenklassifikation und eng definierten Antwortfeldern. Es lädt nicht pauschal jede Repositorydatei, keinen vollständigen Gesprächsverlauf und keine privaten Kundendaten in eine Antwort.
- Allowed
- explizit freigegebene öffentliche Routen.
- Service
- separat gepflegte Leistungskontexte mit passender Eröffnungsfrage.
- Excluded
- exakte Seiten ohne positiven projektspezifischen Kontext.
- Unknown
- Default-deny mit allgemeinem, deterministischem Fallback.
User Question × Owner Policy × Controlled Response × Human Handoff
Default-deny ist ein Produktmerkmal.
Eine Seite wird nicht allein deshalb beraten, weil sie öffentlich erreichbar ist. Exakte Ausschlüsse, Präfixregeln und serverseitige Prüfung halten den Kontext eng.
163explizit erlaubte Routen
70Servicekontexte
51exakte Ausschlüsse nach dieser Veröffentlichung
1deterministischer sicherer Fallback
Datensparsame Messung
Analyse braucht nicht automatisch ein Gesprächsarchiv.
Tracking ist einwilligungsabhängig. Dokumentiert werden kompakte Ereignisse und eine begrenzte Zusammenfassung, nicht automatisch vollständige Transkripte oder sensible Inhalte.
- Keine API-Schlüssel oder Zugangsdaten in Nutzereingaben
- Keine privaten Prompt- oder Schutzdetails auf dieser Seite
- Keine ungefilterte Providerfehlermeldung im Frontend
- Keine positive Freigabe unbekannter Routen
Strukturierte Antwort
Erlaubte Handlungen sind enger als freie Textgenerierung.
Was ist sicher beantwortbar?
Kontext und Grenzen werden zuerst benannt.
Welche Aktion ist erlaubt?
Nur definierte CTA-Ziele werden ausgegeben.
Wann endet Automation?
Offene Projektfragen gehen in den menschlichen Handoff.
Scope, Claims und Angebote
Der Assistant darf keine fehlende Entscheidungsgrundlage erfinden.
Preis und Angebot
Er übernimmt nur ausdrücklich freigegebene öffentliche Preis- oder Angebotsinformationen. Für diese Proof-Seite gilt NO_PUBLIC_PRICE; sie enthält keinen Zahlenpreis.
Technische Themen
Er kann einen begrenzten nächsten Schritt erklären, aber keine ungeprüfte Kompatibilität, Sicherheit oder vollständige Integration zusagen.
Recht und sensible Themen
Er verweist auf Grenzen und menschliche Prüfung, statt Rechts-, Finanz-, Förder- oder Datenschutzberatung zu simulieren.
Leadübergabe
Kontaktangaben werden erst in einem separaten, einwilligungsgebundenen Formular erfasst. Der Assistant schließt keinen Vertrag und qualifiziert keine Person autonom.
Fallback × Abschaltbarkeit × Monitoring
Betriebssicherheit bedeutet auch: kontrolliert aufhören können.
Fehlt die AI-Freigabe, der Schlüssel oder eine valide strukturierte Antwort, bleibt eine nutzbare deterministische Hilfe erhalten. Feature Flags können den freien Antwortpfad deaktivieren, ohne den persönlichen Kontaktweg zu entfernen.
- TestValidierung, CTA-Mapping und Widerspruchsnormalisierung
- RegressionRoutepolicy, Consent, Fallback und API-Schutz
- Monitoringdatensparsame Ereignisse statt öffentlich behaupteter Geschäftsresultate
- Handoffklarer Wechsel zu Muharrem Uzun bei projektspezifischen Entscheidungen
Öffentliche Proof-Grenzen
Was diese Architektur nicht belegt.
- Kein Kunden-AI-Projekt oder Kundenresultat
- Keine autonome Rechts-, Finanz- oder Förderberatung
- Kein CRM-Betrieb oder universelle Systemintegration
- Keine garantierte Lead-, Conversion- oder Qualifizierungswirkung
- Keine Veröffentlichung vertraulicher Prompts, Schlüssel oder Angriffspfade
FAQ
Fragen zur Architektur und ihren Grenzen.
Ist der Sales Assistant ein Kundenprojekt?
Nein. Er ist ein eigenes System von mu digital und kein Beleg für eine Kundenimplementierung oder einen Kundenerfolg.
Was belegt die Seite?
Sie belegt einen kontrollierten Entwicklungs- und Betriebsprozess: Routenpolitik, strukturierte Antworten, Eingabelimits, Fallback, datensparsame Messung und menschliche Übergabe.
Welche Seiten darf der Assistant positiv einordnen?
Nur explizit freigegebene Routen und Servicekontexte. Unbekannte, ausgeschlossene oder sensible Pfade bleiben standardmäßig ohne positiven Kontext.
Speichert das System vollständige Gespräche für Analytics?
Nein. Die dokumentierte Messung ist einwilligungsabhängig und auf kompakte, personenarme Ereignisse ausgelegt, nicht auf vollständige Transkripte.
Gibt der Assistant Rechts-, Finanz- oder Förderberatung?
Nein. Er ersetzt keine fachliche Beratung und trifft keine rechtlichen, finanziellen oder förderbezogenen Entscheidungen.
Erstellt der Assistant automatisch Angebote?
Nein. Zulässige CTAs und der menschliche Handoff sind kontrolliert. Ein autonomer Angebots- oder Vertragsabschluss wird nicht behauptet.
Ist der Assistant mit einem CRM verbunden?
Aus diesem Proof folgt kein CRM-Betrieb, keine CRM-Integration und kein automatisches Lead-Routing in fremde Systeme.
Werden interne Prompts oder API-Schlüssel offengelegt?
Nein. Öffentliche Transparenz beschreibt Kontrollprinzipien, nicht vertrauliche Prompts, Zugangsdaten oder ausnutzbare Schutzdetails.
Was passiert bei einem Provider- oder Strukturfehler?
Das System fällt auf eine begrenzte, deterministische Antwort zurück und gibt keine internen Providerfehler an Nutzer weiter.
Kann mu digital einen ähnlichen Assistenten umsetzen?
Ein enger Use Case kann nach Daten-, Rollen-, Anbieter-, Kosten-, Datenschutz- und Betriebsgate geprüft werden. Daraus folgt keine pauschale Integrationszusage.
Welche Ergebnisse werden nicht behauptet?
Keine höhere Conversion, mehr Leads, bessere Qualifizierung oder andere Geschäftskennzahl wird diesem System ohne separate Primärevidenz zugeschrieben.
Wer verantwortet das System?
Verantwortlich für Konzeption und technischen Betrieb ist mu digital, Muharrem Uzun.
Verantwortlich: mu digital · Muharrem Uzun
Ein sinnvoller Assistant beginnt mit einem engen Use Case.
Beschreiben Sie Ziel, Datenquellen und gewünschten Handoff – ohne sensible Daten oder Zugangsdaten in der Erstanfrage.
Begrenzten Assistenten-Use-Case besprechen