1263 lines
32 KiB
Markdown
1263 lines
32 KiB
Markdown
# PRD: SmartMeter-Lite App
|
||
## Product Requirements Document - MVP Version
|
||
|
||
**Version:** 1.0
|
||
**Datum:** Februar 2026
|
||
**Status:** Final für Development
|
||
**Owner:** [PM Name]
|
||
**Stakeholder:** Stadtwerke, Endkunden, Support-Teams
|
||
|
||
---
|
||
|
||
## 1. EXECUTIVE SUMMARY
|
||
|
||
### Vision
|
||
Digitalisierung der Zählerablesung für deutsche Stadtwerke durch eine einfache, mobile App. Ziel: Manuelle Ablesungsprozesse automatisieren, Fehlerquote von 30-40% auf <5% reduzieren, und Support-Anfragen zu Abrechnungsfehlern um 70% senken.
|
||
|
||
### Problem Statement
|
||
Stadtwerke basieren aktuell auf **manueller, fehlerhafter Zählerablesung**:
|
||
- 📊 **30-40% Fehlerquote** bei manuellen Eingaben
|
||
- 📞 **50+ Anrufe/Woche** zu Abrechnungskorrektionen
|
||
- 💰 **5-10 Millionen EUR/Jahr** Verarbeitungskosten
|
||
- 😞 **Customer Dissatisfaction:** 45% Unzufriedenheit mit Abrechnungsprozess
|
||
|
||
### Solution
|
||
**SmartMeter-Lite:** Eine mobile App, die es Kunden erlaubt, ihren Stromzähler zu fotografieren. OCR-Technologie liest automatisch die Zahl aus, validiert sie, und sendet sie direkt an die Stadtwerk-Abrechnungssysteme.
|
||
|
||
### Expected Outcomes (Year 1)
|
||
- ✅ **<5% Fehlerquote** (vs. 30-40% aktuell)
|
||
- ✅ **70% weniger Support-Anfragen** zu Abrechnungen
|
||
- ✅ **40% Cost Savings** im Ablese-Prozess
|
||
- ✅ **80% Kundenakzeptanz** nach 6 Monaten
|
||
- ✅ **+50 NPS** Verbesserung
|
||
|
||
### Market Opportunity
|
||
- **TAM:** 900+ Stadtwerke in Deutschland
|
||
- **SAM:** Top 100 Stadtwerke (60% Markt)
|
||
- **SOM Year 1:** 10-15 Stadtwerke = **€800k - 1.2M ARR**
|
||
- **SOM Year 2:** 30-40 Stadtwerke = **€2.4M - 4.8M ARR**
|
||
|
||
### Business Model
|
||
**B2B SaaS:**
|
||
- **Small Stadtwerke:** €1.000 - €3.000/Monat
|
||
- **Medium Stadtwerke:** €3.000 - €8.000/Monat
|
||
- **Large Stadtwerke:** €8.000 - €20.000/Monat
|
||
- **Per-Scan Pricing (optional):** €0.05 - €0.15 pro Ablesung
|
||
|
||
---
|
||
|
||
## 2. USER PERSONAS
|
||
|
||
### Persona 1: Anna Müller (B2C - Endkundin)
|
||
**Alter:** 42
|
||
**Job:** IT-Projektmanagerin
|
||
**Tech-Affinity:** Hoch
|
||
|
||
**Probleme:**
|
||
- Vergisst regelmäßig Zählerablesung (Deadline jeweils 15. des Monats)
|
||
- Hatte schon 2x Abrechnungskorrektionen (Stress, Telefonieren)
|
||
- Wünscht sich digitale Lösung
|
||
|
||
**Needs:**
|
||
- ✅ Einfach Foto machen, fertig
|
||
- ✅ Bestätigung, dass Ablesung ankam
|
||
- ✅ Keine technischen Fehler
|
||
- ✅ Ablauf in <2 Minuten
|
||
|
||
**Motivation für Nutzung:**
|
||
- Zeitersparnis (10 Min Telefonat vermeiden)
|
||
- Sicherheit (Beweis, dass korrekt abgelesen)
|
||
- Convenience (von zuhause, am Wochenende)
|
||
|
||
---
|
||
|
||
### Persona 2: Klaus Schmidt (B2B - Stadtwerk IT-Manager)
|
||
**Alter:** 55
|
||
**Job:** IT-Leiter bei großer Stadtwerk (100k+ Kunden)
|
||
**Tech-Affinity:** Mittel
|
||
|
||
**Probleme:**
|
||
- Support-Team bekommt täglich 50-100 Anfragen zu Abrechnungen
|
||
- Manuelle Ablesungen führen zu Datenfehlern in SAP-System
|
||
- Keine Digitalisierung im Ablese-Prozess
|
||
|
||
**Needs:**
|
||
- ✅ Integration mit SAP/Oracle Abrechnungssystem
|
||
- ✅ Admin-Dashboard zur Überwachung
|
||
- ✅ Fehlerbehandlung (was wenn OCR falsch liest?)
|
||
- ✅ Datenqualitäts-Reports
|
||
- ✅ DSGVO Compliance
|
||
|
||
**Motivation für Nutzung:**
|
||
- ROI in <18 Monaten
|
||
- Weniger Support-Tickets
|
||
- Bessere Datenqualität
|
||
- Wettbewerbsfähigkeit
|
||
|
||
---
|
||
|
||
### Persona 3: Hans Schneider (B2B - Kundenservice Manager)
|
||
**Alter:** 38
|
||
**Job:** Head of Customer Service bei Medium Stadtwerk (50k Kunden)
|
||
**Tech-Affinity:** Mittel-niedrig
|
||
|
||
**Probleme:**
|
||
- Team muss täglich 100+ falsche Ablesungen korrigieren
|
||
- Customer Satisfaction score: 3.2/5 (zu niedrig)
|
||
- Keine Automatisierung möglich mit aktuellen Prozessen
|
||
|
||
**Needs:**
|
||
- ✅ Einfach zu bedienende Software (nur Clicks, kein Coding)
|
||
- ✅ Klare Reports (wie viele Ablesungen/Woche?)
|
||
- ✅ Training für Support-Team
|
||
- ✅ Schneller Kundenservice (FAQ, Video-Tutorials)
|
||
|
||
**Motivation für Nutzung:**
|
||
- Team-Entlastung
|
||
- Bessere Customer Satisfaction
|
||
- Kostenersparnis (weniger Korrektionen)
|
||
- Moderne Arbeitsprozesse
|
||
|
||
---
|
||
|
||
## 3. USE CASES
|
||
|
||
### Use Case 1: Normale Ablesung (Happy Path)
|
||
|
||
**Akteur:** Anna Müller (Endkundin)
|
||
**Trigger:** Abrechnungs-Deadline erreicht (15. des Monats)
|
||
|
||
**Ablauf:**
|
||
```
|
||
1. Anna öffnet SmartMeter App auf ihrem Smartphone
|
||
2. Sie wählt "Neue Ablesung"
|
||
3. App öffnet Kamera, zeigt "Frame Guide" (Zähler-Umriss)
|
||
4. Anna fotografiert ihren Stromzähler (sechs Ziffern sichtbar)
|
||
5. App zeigt OCR-Ergebnis: "128456" mit 96% Confidence
|
||
6. Anna bestätigt oder korrigiert die Zahl
|
||
7. App speichert die Ablesung, zeigt "✅ Erfolgreich gesendet"
|
||
8. Ablesung wird in Echzeit an Stadtwerk-Backend übertragen
|
||
9. Stadtwerk bestätigt Receipt per SMS/E-Mail
|
||
```
|
||
|
||
**Erwartetes Ergebnis:**
|
||
- ✅ Ablesung korrekt im Stadtwerk-System
|
||
- ✅ Anna erhält Bestätigung
|
||
- ✅ Keine manuelle Bearbeitung nötig
|
||
- ✅ Keine Support-Anfrage
|
||
|
||
---
|
||
|
||
### Use Case 2: OCR-Fehler (Alternate Path)
|
||
|
||
**Akteur:** Klaus Mueller (Endkunde mit älterem Zähler)
|
||
**Trigger:** Zähler ist dunkel, schlecht lesbar
|
||
|
||
**Ablauf:**
|
||
```
|
||
1. Klaus fotografiert seinen alten, schmuddeligen Zähler
|
||
2. OCR liest: "12345X" (X statt 6, 60% Confidence - LOW)
|
||
3. App zeigt Warning: "Unsicher. Bitte überprüfen oder neu fotografieren"
|
||
4. Klaus sieht das rote Warning-Symbol
|
||
5. Er fotografiert nochmal, besser fokussiert
|
||
6. Dieses Mal: "123456" mit 98% Confidence
|
||
7. Klaus bestätigt
|
||
8. App speichert, zeigt: "✅ Erfolgreich gesendet"
|
||
```
|
||
|
||
**Erwartetes Ergebnis:**
|
||
- ✅ Fehler werden NICHT ans Backend gesendet
|
||
- ✅ User wird informiert und kann korrigieren
|
||
- ✅ Keine falschen Daten im System
|
||
|
||
---
|
||
|
||
### Use Case 3: Admin Dashboard (B2B)
|
||
|
||
**Akteur:** Klaus Schmidt (Stadtwerk IT-Manager)
|
||
**Trigger:** Morgens zur Arbeit, checkt Status
|
||
|
||
**Ablauf:**
|
||
```
|
||
1. Klaus loggt sich ins Admin Dashboard ein
|
||
2. Er sieht Übersicht:
|
||
- 847 Ablesungen diese Woche
|
||
- 834 erfolgreich (98.5%)
|
||
- 13 fehlgeschlagen (1.5%) - mit Reasons
|
||
- Average Confidence Score: 96.2%
|
||
3. Er klickt auf "Failed Ablesungen"
|
||
4. Er sieht: 8 × "Low Quality Photo", 5 × "Invalid Format"
|
||
5. Er exported den Report als CSV für SAP
|
||
6. Er sieht Alert: "3 Customers haben >3 Fehlerversuche"
|
||
7. Er klickt auf die Kunden → sieht ihre Fehlerbilder
|
||
8. Er sendet Kunden eine Email: "Bitte wie folgt fotografieren..."
|
||
```
|
||
|
||
**Erwartetes Ergebnis:**
|
||
- ✅ Klaus sieht Qualitätsmetriken in Echtzeit
|
||
- ✅ Fehler werden identifiziert, bevor sie zu Problems werden
|
||
- ✅ Pro-aktive Kundenunterstützung möglich
|
||
|
||
---
|
||
|
||
### Use Case 4: Integration mit SAP (B2B Backend)
|
||
|
||
**Akteur:** SAP-System der Stadtwerk
|
||
**Trigger:** Ablesung wird in SmartMeter-App bestätigt
|
||
|
||
**Ablauf:**
|
||
```
|
||
1. User submitted Ablesung in App
|
||
2. SmartMeter Backend validates:
|
||
- Format korrekt? ✅
|
||
- Plausibility Check? (Z.B. nicht 50% mehr als letzte Ablesung)
|
||
- Duplicate Check? (Wurde heute schon abgelesen?)
|
||
3. SmartMeter sendet REST API Call zu Stadtwerk SAP:
|
||
POST /api/readings
|
||
{
|
||
"customer_id": "SW12345",
|
||
"reading": 128456,
|
||
"timestamp": "2026-02-17T14:32:00Z",
|
||
"confidence": 0.96,
|
||
"photo_hash": "abc123def456"
|
||
}
|
||
4. SAP antwortet: {"status": "success", "reading_id": "RD987654"}
|
||
5. SmartMeter speichert Reading ID lokal
|
||
6. App zeigt Kunde: "✅ Ablesung erfolgreich übertragen"
|
||
7. SAP triggert automatische Rechnungsberechnung
|
||
8. Keine manuelle Bearbeitung nötig
|
||
```
|
||
|
||
**Erwartetes Ergebnis:**
|
||
- ✅ Daten sind in Echtzeit im SAP-System
|
||
- ✅ Rechnungsprozess startet sofort
|
||
- ✅ Keine Verzögerungen durch manuelle Prozesse
|
||
|
||
---
|
||
|
||
## 4. FEATURES - MVP (PHASE 1)
|
||
|
||
### 4.1 Mobile App Features (iOS + Android)
|
||
|
||
#### Feature 1.1: Authentication & Onboarding
|
||
**Priority:** CRITICAL
|
||
**Effort:** M (Medium)
|
||
|
||
```
|
||
- Sign Up: Email/Passwort oder SMS OTP
|
||
- Login: Standard Email/Passwort
|
||
- "Kundendaten Import": Stadtwerk importiert Kundenlisten
|
||
→ App kann automatisch Kunden-ID vorausfüllen
|
||
- 2FA (optional): SMS-Bestätigung
|
||
- Biometric: Fingerprint / Face ID support
|
||
- Session Management: Auto-logout nach 15 Min Inaktivität
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ Sign-Up in <2 Minuten
|
||
- ✅ 95%+ erfolgreiche Logins
|
||
- ✅ <30 Sekunden Login-Zeit
|
||
|
||
---
|
||
|
||
#### Feature 1.2: Camera & Photo Capture
|
||
**Priority:** CRITICAL
|
||
**Effort:** M-L
|
||
|
||
```
|
||
- Live Camera Preview mit Frame Guide
|
||
→ Zeigt Umriss des Zählers als Overlay
|
||
→ Hilft User, korrekt zu fotografieren
|
||
→ "Zähler muss in diesem Rahmen sein"
|
||
|
||
- Auto-Capture Option:
|
||
→ App fotografiert automatisch, wenn Zähler erkannt
|
||
→ Oder manueller Knopf "Foto machen"
|
||
|
||
- Flash Control:
|
||
→ Auto-Flash für dunkle Umgebungen
|
||
→ Manual Flash Adjustment möglich
|
||
|
||
- Photo Quality Check:
|
||
→ Vor Upload: Ist Foto scharf genug?
|
||
→ Ist Zähler vollständig sichtbar?
|
||
→ Wenn nicht: "Bitte besseres Foto machen"
|
||
|
||
- Multiple Captures:
|
||
→ User kann 3-5 Fotos machen, beste wählen
|
||
→ App zeigt auto-selected bestes Foto
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ >95% Fotos sind verwertbar
|
||
- ✅ <5% müssen erneut fotografiert werden
|
||
- ✅ Average Photo Quality Score: >90/100
|
||
|
||
---
|
||
|
||
#### Feature 1.3: OCR & Digit Recognition
|
||
**Priority:** CRITICAL
|
||
**Effort:** L (Large)
|
||
|
||
```
|
||
TECHNOLOGY OPTION A: Google Vision API (Recommended)
|
||
- Best Accuracy (97%+)
|
||
- Schnell (500ms)
|
||
- Kostet ca. €0.01 pro Request
|
||
- Einfache Integration via REST API
|
||
|
||
TECHNOLOGY OPTION B: Tesseract (Open Source)
|
||
- Kostenlos
|
||
- 85-90% Accuracy
|
||
- Langsamer (2-3s)
|
||
- Braucht Local Processing
|
||
|
||
TECHNOLOGY OPTION C: TensorFlow Lite Model (Custom)
|
||
- Medium Accuracy (88-92%)
|
||
- Schnell (300ms)
|
||
- Offline möglich
|
||
- Braucht Training Data (100+ Meter Fotos)
|
||
|
||
RECOMMENDATION: Option A (Google Vision) für MVP
|
||
Later: Option C für Kosteneinsparungen
|
||
|
||
FEATURES:
|
||
- Automatic OCR nach Foto-Upload
|
||
- Confidence Score anzeigen (Z.B. "96% sicher")
|
||
- Zeige alternatives interpretations wenn <90% Confidence
|
||
Z.B.: "Könnte auch sein: 128455 (87%)"
|
||
- Digit-by-Digit Verification möglich
|
||
- Auto-correct häufige Fehler:
|
||
→ "O" als "0" erkennen
|
||
→ "l" als "1" erkennen
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ >95% OCR Accuracy
|
||
- ✅ <1s OCR Response Time
|
||
- ✅ <0.5% False Positives
|
||
|
||
---
|
||
|
||
#### Feature 1.4: Manual Verification & Correction
|
||
**Priority:** CRITICAL
|
||
**Effort:** S (Small)
|
||
|
||
```
|
||
- Nach OCR: Zeige große, klare Digits zum Verifizieren
|
||
- User kann nach oben/unten swipen um Digit zu ändern
|
||
Z.B.: "1" → swipen-oben → "2" → swipen-unten → "1"
|
||
ODER: Tippen auf jede Ziffer → Numpad poppen up
|
||
|
||
- Confirmation Screen:
|
||
"Bitte bestätigen Sie die Ablesung:"
|
||
[Großes Display: 123456]
|
||
[Button: ✅ Bestätigt] [Button: ❌ Neu fotografieren]
|
||
|
||
- Fehlertoleranz:
|
||
Wenn User versucht "999999" einzugeben:
|
||
→ "Warnung: Dieses ist um 800% höher als letzte Ablesung"
|
||
→ "Bitte überprüfen oder Foto neu machen"
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ >99% der Ablesungen sind korrekt nach Verification
|
||
- ✅ <5% Ablesungen müssen korrigiert werden
|
||
|
||
---
|
||
|
||
#### Feature 1.5: Submission & Confirmation
|
||
**Priority:** CRITICAL
|
||
**Effort:** M
|
||
|
||
```
|
||
- Upload Status:
|
||
Zeige Progress Bar während Upload
|
||
"Sende Ablesung... 45%"
|
||
|
||
- Offline Support:
|
||
Wenn kein Internet: Queue die Ablesung lokal
|
||
"Wird bei nächster Verbindung hochgeladen"
|
||
|
||
- Success Confirmation:
|
||
"✅ Ablesung erfolgreich eingereicht!"
|
||
"Bestätigungs-ID: RD987654"
|
||
"Nächste Ablesung fällig: 15. März 2026"
|
||
|
||
- Notification:
|
||
Push Notification: "Ablesung akzeptiert"
|
||
Email: Ablesung + Bestätigungs-ID
|
||
SMS (optional): "Ablesung erhalten"
|
||
|
||
- History:
|
||
Alle bisherigen Ablesungen anzeigen:
|
||
"15. Feb 2026: 128456 ✅"
|
||
"15. Jan 2026: 127812 ✅"
|
||
Mit Links zu PDFs/Fotos
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ >99% Uptime während Submission
|
||
- ✅ <2s Submission Response Time
|
||
- ✅ >95% Confirmations kommen an
|
||
|
||
---
|
||
|
||
#### Feature 1.6: User Dashboard
|
||
**Priority:** HIGH
|
||
**Effort:** M
|
||
|
||
```
|
||
- Home Screen:
|
||
"Aktuelle Ablesung: 128456 (15. Feb 2026)"
|
||
"Nächste Ablesung fällig: 15. März 2026" (5 Tage)
|
||
[Big Button: "Jetzt Ablesen"]
|
||
|
||
- History Tab:
|
||
Liste aller Ablesungen:
|
||
"15. Feb 2026 - 128456 ✅"
|
||
"15. Jan 2026 - 127812 ✅"
|
||
Mit: Foto, Zeitstempel, Status
|
||
|
||
- Alerts Tab:
|
||
"Warnung: Ablesung 3 Tage überfällig!"
|
||
"Info: Neue Version verfügbar"
|
||
|
||
- Settings Tab:
|
||
- Notifications (push, email, SMS)
|
||
- Sprache (Deutsch, Englisch)
|
||
- Account Management (Profil, Passwort)
|
||
- About & Help
|
||
- Logout
|
||
|
||
- Help & FAQ:
|
||
"Wie fotografiere ich richtig?"
|
||
→ Video Tutorial (30s)
|
||
"Mein Foto wird nicht erkannt"
|
||
→ Troubleshooting Guide
|
||
"Wann ist die nächste Ablesung fällig?"
|
||
→ FAQ
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ >80% Users nutzen App min. 1x/Monat
|
||
- ✅ <3 Taps um Ablesung zu machen
|
||
- ✅ NPS >50
|
||
|
||
---
|
||
|
||
### 4.2 Admin Dashboard Features (Web - Für Stadtwerke)
|
||
|
||
#### Feature 2.1: Authentication & Authorization
|
||
**Priority:** CRITICAL
|
||
**Effort:** S
|
||
|
||
```
|
||
- Login: Email/Passwort (Standard)
|
||
- 2FA: Mandatory für Admin Accounts
|
||
- Role-Based Access Control:
|
||
- Super Admin: Full Access
|
||
- Manager: Reports, Alerts, antwort auf Fehler
|
||
- Analyst: Read-Only
|
||
- Support: Kundensuche, Fehlerbehandlung
|
||
|
||
- Session Management:
|
||
Auto-logout nach 30 Min Inaktivität (Enterprise Standard)
|
||
```
|
||
|
||
---
|
||
|
||
#### Feature 2.2: Real-Time Dashboard
|
||
**Priority:** CRITICAL
|
||
**Effort:** L
|
||
|
||
```
|
||
MAIN DASHBOARD WIDGETS:
|
||
|
||
1. Today's Metrics:
|
||
- "847 Ablesungen heute"
|
||
- "823 erfolgreich (97.2%)"
|
||
- "24 fehlgeschlagen (2.8%)"
|
||
- "96.1% Average Confidence"
|
||
|
||
2. Trend Chart (7-Day):
|
||
- Liniendiagramm: Ablesungen pro Tag
|
||
- Durchschnittliche Erfolgsrate
|
||
- Average Confidence über Zeit
|
||
|
||
3. Top Issues (This Week):
|
||
- "13 × Zähler nicht lesbar (Low light)"
|
||
- "8 × Ungültige Format"
|
||
- "7 × User Error (falsche Zahl eingegeben)"
|
||
|
||
4. Recent Submissions:
|
||
Live Feed:
|
||
"14:32 - Kunde XYZ - 128456 ✅"
|
||
"14:28 - Kunde ABC - 127812 ✅"
|
||
"14:25 - Kunde DEF - Error (Low confidence 41%) ❌"
|
||
|
||
5. Alerts & Notifications:
|
||
- "3 Customers haben >3 Fehlerversuche"
|
||
- "System Response Time >2s" (Performance Alert)
|
||
- "Neue App Version verfügbar"
|
||
|
||
REFRESH RATE: Real-time (WebSocket connection)
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ Dashboard loads in <2s
|
||
- ✅ Real-time updates <500ms delay
|
||
- ✅ 99.9% uptime
|
||
|
||
---
|
||
|
||
#### Feature 2.3: Detailed Analytics & Reports
|
||
**Priority:** HIGH
|
||
**Effort:** M
|
||
|
||
```
|
||
REPORT TYPES:
|
||
|
||
1. Daily Summary Report:
|
||
- Datum
|
||
- Total Submissions
|
||
- Erfolgsrate (%)
|
||
- Avg Confidence Score
|
||
- Errors by Category
|
||
- Cost Calculation (EUR saved vs. manual)
|
||
|
||
2. Customer-Level Report:
|
||
- Filter by: Alter, Region, Stadtwerke
|
||
- Details:
|
||
* Anzahl Ablesungen
|
||
* Success Rate
|
||
* Average Confidence
|
||
* Last Reading (Date + Value)
|
||
- Download: CSV, PDF
|
||
|
||
3. Error Analysis Report:
|
||
- Fehlertypen:
|
||
* Low Quality Photo (%)
|
||
* Invalid Format (%)
|
||
* OCR Failure (%)
|
||
* User Error (%)
|
||
- Time Series: Fehler über Zeit
|
||
|
||
4. Performance Report:
|
||
- Response Time (average, min, max)
|
||
- Uptime (%)
|
||
- API Availability
|
||
- Subscription Usage
|
||
|
||
5. Compliance Report (DSGVO):
|
||
- Data Processing Log
|
||
- Audit Trail
|
||
- User Activity Log
|
||
|
||
EXPORT OPTIONS: CSV, PDF, Excel, Email
|
||
SCHEDULING: Daily, Weekly, Monthly Reports
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ Reports generieren in <10s
|
||
- ✅ >90% Accuracy of reported numbers
|
||
|
||
---
|
||
|
||
#### Feature 2.4: Customer Management
|
||
**Priority:** HIGH
|
||
**Effort:** M
|
||
|
||
```
|
||
- Customer Search:
|
||
Suche by: Name, Customer ID, Email, Telefon
|
||
|
||
- Customer Details:
|
||
- Name, Adresse, Kontakt
|
||
- Current Reading + History
|
||
- Success Rate
|
||
- Errors (Foto + Reason)
|
||
- Contact History
|
||
|
||
- Bulk Import:
|
||
Upload CSV:
|
||
customer_id, name, email, phone, address
|
||
→ System importiert und sendet Invitation
|
||
|
||
- Customer Deactivation:
|
||
Kunde kann sich abmelden
|
||
Admin kann deactivieren (Z.B. umgezogen)
|
||
|
||
- Resend Invitation:
|
||
Falls Kunde App nicht installiert hat
|
||
→ Admin kann Invitation Email/SMS erneut senden
|
||
```
|
||
|
||
---
|
||
|
||
#### Feature 2.5: Error Management & Troubleshooting
|
||
**Priority:** CRITICAL
|
||
**Effort:** M
|
||
|
||
```
|
||
- Failed Submissions Detailed View:
|
||
Click on Error → Zeige:
|
||
- Foto (Thumbnail + Full View)
|
||
- OCR Result + Confidence Score
|
||
- User's Correction (falls vorhanden)
|
||
- Error Category: [Low Quality] [Invalid] [OCR Error]
|
||
- Customer Contact Info
|
||
|
||
- Automated Responses:
|
||
Admin kann automatische Messages schreiben:
|
||
"Lieber Kunde, Ihr Zähler war nicht lesbar"
|
||
"Bitte fotografieren Sie wie folgt:"
|
||
[Link zu Video Tutorial]
|
||
|
||
- Manual Intervention:
|
||
Admin kann:
|
||
- Reading manuell akzeptieren (mit Notiz)
|
||
- Reading ablehnen + Kunde kontaktieren
|
||
- Foto im System ersetzten
|
||
|
||
- Error Categories:
|
||
Auto-Tagging nach AI (später):
|
||
- "Low Light" (60% Confidence)
|
||
- "Angle Wrong" (Invalid Format)
|
||
- "Meter Dirty" (Low Quality)
|
||
- "User Typo" (Plausibility Check Failed)
|
||
```
|
||
|
||
**Success Criteria:**
|
||
- ✅ Errors werden in <1h erkannt und handelt
|
||
- ✅ Support kann Fehler in <2 Min beheben
|
||
|
||
---
|
||
|
||
#### Feature 2.6: User Management & Permissions
|
||
**Priority:** HIGH
|
||
**Effort:** S
|
||
|
||
```
|
||
- Add/Remove/Edit Users:
|
||
- Email
|
||
- Role: [Super Admin] [Manager] [Analyst] [Support]
|
||
- Permissions by Role
|
||
- Activation/Deactivation
|
||
|
||
- Audit Log:
|
||
Wer hat was wann gemacht:
|
||
"Admin XYZ hat User ABC gelöscht (17.02.2026 14:23)"
|
||
"Manager DEF hat Reading manuell akzeptiert (RD987654)"
|
||
|
||
- Activity Report:
|
||
- Logins (Zeit, IP)
|
||
- Actions (What, When, Who)
|
||
- Data Export
|
||
```
|
||
|
||
---
|
||
|
||
#### Feature 2.7: Integration & API
|
||
**Priority:** CRITICAL
|
||
**Effort:** L
|
||
|
||
```
|
||
API INTEGRATION with Stadtwerk's SAP/ERP:
|
||
|
||
1. REST API Endpoints:
|
||
POST /api/v1/readings - Submit reading
|
||
GET /api/v1/readings/{id} - Get reading details
|
||
GET /api/v1/customers/{id} - Get customer info
|
||
GET /api/v1/reports/daily - Daily report data
|
||
|
||
2. Authentication:
|
||
OAuth 2.0 Token-based
|
||
API Keys for System-to-System
|
||
|
||
3. Data Format:
|
||
{
|
||
"customer_id": "SW12345",
|
||
"reading": 128456,
|
||
"timestamp": "2026-02-17T14:32:00Z",
|
||
"confidence": 0.96,
|
||
"photo_hash": "abc123def456"
|
||
}
|
||
|
||
4. Callback Webhooks:
|
||
Stadtwerk kann subscribe zu:
|
||
- new_reading_submitted
|
||
- reading_failed
|
||
- customer_error
|
||
|
||
Wir senden: POST to /webhook/readings
|
||
|
||
5. Rate Limiting:
|
||
- 10,000 requests/hour (default)
|
||
- Higher tiers: 50,000 /hour
|
||
|
||
6. Documentation:
|
||
Full Swagger/OpenAPI docs
|
||
Code Examples (Python, Node.js, Java)
|
||
```
|
||
|
||
---
|
||
|
||
## 5. TECH STACK - MVP
|
||
|
||
### 5.1 Mobile App (iOS + Android)
|
||
|
||
```
|
||
Framework: React Native / Flutter
|
||
Language: TypeScript / Dart
|
||
State Management: Redux Toolkit / Provider
|
||
API Client: Axios / http
|
||
Camera: react-native-camera / Camera2
|
||
OCR Integration: Google Vision API SDK
|
||
Storage: AsyncStorage / Realm DB (local caching)
|
||
UI Library: React Native Paper / Material 3
|
||
Push Notifications: Firebase Cloud Messaging
|
||
Testing: Jest + Detox (E2E)
|
||
CI/CD: GitHub Actions / EAS Build
|
||
```
|
||
|
||
### 5.2 Backend (API Server)
|
||
|
||
```
|
||
Language: Node.js + TypeScript (Recommended)
|
||
Framework: Express.js / Fastify
|
||
Database: PostgreSQL 13+
|
||
Cache: Redis (Session Cache, Rate Limiting)
|
||
Storage: AWS S3 / Azure Blob (for photos)
|
||
Authentication: JWT + OAuth2
|
||
API Gateway: Kong / AWS API Gateway
|
||
Message Queue: RabbitMQ (for async processing)
|
||
Logging: Winston / Pino
|
||
Monitoring: Prometheus + Grafana
|
||
Testing: Jest + Supertest
|
||
```
|
||
|
||
### 5.3 OCR Service
|
||
|
||
```
|
||
Primary: Google Vision API (REST-based)
|
||
Fallback: Tesseract.js (Web-based)
|
||
Alternative: TensorFlow Lite (Custom Model)
|
||
|
||
OCR Confidence Threshold:
|
||
- >90%: Accept automatically
|
||
- 70-90%: Show to user for confirmation
|
||
- <70%: Reject + ask for new photo
|
||
```
|
||
|
||
### 5.4 Admin Dashboard
|
||
|
||
```
|
||
Frontend: React 18+
|
||
Language: TypeScript
|
||
UI Library: Material-UI / TailwindCSS
|
||
Charts: Recharts / Chart.js
|
||
State Management: Redux Toolkit / TanStack Query
|
||
Testing: Jest + React Testing Library
|
||
Build: Vite / Create React App
|
||
Deployment: Vercel / Netlify
|
||
```
|
||
|
||
### 5.5 Infrastructure
|
||
|
||
```
|
||
Cloud Provider: AWS (or Azure/GCP)
|
||
Containerization: Docker
|
||
Orchestration: Kubernetes (EKS) / or Lambda
|
||
Database Hosting: RDS PostgreSQL
|
||
File Storage: S3
|
||
CDN: CloudFront
|
||
Monitoring: CloudWatch / DataDog
|
||
Security: WAF, SSL/TLS, VPC
|
||
```
|
||
|
||
---
|
||
|
||
## 6. DATA MODELS
|
||
|
||
### 6.1 Customer
|
||
|
||
```json
|
||
{
|
||
"id": "uuid",
|
||
"customerNumber": "SW123456",
|
||
"email": "anna@example.com",
|
||
"phone": "+49123456789",
|
||
"firstName": "Anna",
|
||
"lastName": "Müller",
|
||
"address": "Beispielstr. 42, 69120 Heidelberg",
|
||
"postalCode": "69120",
|
||
"city": "Heidelberg",
|
||
"stadtwerkeId": "uuid",
|
||
"createdAt": "2026-01-15T10:30:00Z",
|
||
"updatedAt": "2026-02-17T14:22:00Z",
|
||
"status": "active" | "inactive" | "deleted"
|
||
}
|
||
```
|
||
|
||
### 6.2 Meter
|
||
|
||
```json
|
||
{
|
||
"id": "uuid",
|
||
"customerId": "uuid",
|
||
"meterNumber": "MTR987654",
|
||
"meterType": "electricity" | "gas" | "water",
|
||
"manufacturer": "Siemens",
|
||
"installDate": "2020-06-01",
|
||
"location": "Wohnzimmer",
|
||
"readingInterval": "monthly" | "quarterly",
|
||
"nextReadingDue": "2026-03-15",
|
||
"currentReading": 128456,
|
||
"lastReading": 127812,
|
||
"lastReadingDate": "2026-02-15T14:32:00Z",
|
||
"createdAt": "2020-06-01T00:00:00Z"
|
||
}
|
||
```
|
||
|
||
### 6.3 Reading (Ablesung)
|
||
|
||
```json
|
||
{
|
||
"id": "uuid",
|
||
"readingNumber": "RD987654",
|
||
"customerId": "uuid",
|
||
"meterId": "uuid",
|
||
"submittedValue": 128456,
|
||
"ocrResult": "128456",
|
||
"ocrConfidence": 0.96,
|
||
"manualCorrection": null,
|
||
"photoUrl": "s3://bucket/photos/RD987654.jpg",
|
||
"photoHash": "abc123def456",
|
||
"status": "success" | "pending_review" | "rejected" | "manual_approved",
|
||
"validationStatus": "valid" | "invalid" | "plausibility_warning",
|
||
"validationErrors": [],
|
||
"previousReading": 127812,
|
||
"previousReadingDate": "2026-02-15T00:00:00Z",
|
||
"submittedAt": "2026-02-17T14:32:00Z",
|
||
"processedAt": "2026-02-17T14:32:05Z",
|
||
"sentToSAPAt": null,
|
||
"sapReadingId": null,
|
||
"staffNotes": null
|
||
}
|
||
```
|
||
|
||
### 6.4 Error Log
|
||
|
||
```json
|
||
{
|
||
"id": "uuid",
|
||
"readingId": "uuid",
|
||
"customerId": "uuid",
|
||
"errorType": "low_confidence" | "invalid_format" | "plausibility_check" | "system_error",
|
||
"errorMessage": "OCR Confidence 41% below threshold 70%",
|
||
"severity": "info" | "warning" | "error",
|
||
"resolution": "ask_for_new_photo" | "manual_review" | "accepted_with_warning",
|
||
"resolvedAt": "2026-02-17T14:35:00Z",
|
||
"createdAt": "2026-02-17T14:32:10Z"
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 7. API SPECIFICATIONS
|
||
|
||
### 7.1 Mobile App → Backend
|
||
|
||
#### Endpoint: POST /api/v1/readings/submit
|
||
|
||
**Request:**
|
||
```json
|
||
{
|
||
"customerId": "uuid",
|
||
"meterId": "uuid",
|
||
"photoUrl": "data:image/jpeg;base64,...",
|
||
"submittedValue": 128456,
|
||
"latitude": 49.1234,
|
||
"longitude": 8.5678,
|
||
"appVersion": "1.0.5",
|
||
"timestamp": "2026-02-17T14:32:00Z"
|
||
}
|
||
```
|
||
|
||
**Response (Success):**
|
||
```json
|
||
{
|
||
"status": "success",
|
||
"readingId": "RD987654",
|
||
"message": "Ablesung erfolgreich eingereicht",
|
||
"nextReadingDue": "2026-03-15",
|
||
"confirmation": {
|
||
"email": true,
|
||
"sms": true
|
||
}
|
||
}
|
||
```
|
||
|
||
**Response (Error):**
|
||
```json
|
||
{
|
||
"status": "error",
|
||
"readingId": "RD987654",
|
||
"message": "OCR Confidence zu niedrig (41%)",
|
||
"suggestion": "Bitte neu fotografieren",
|
||
"suggestions": [
|
||
{
|
||
"value": 123456,
|
||
"confidence": 0.67
|
||
},
|
||
{
|
||
"value": 128456,
|
||
"confidence": 0.41
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
#### Endpoint: GET /api/v1/readings/history
|
||
|
||
**Request:**
|
||
```json
|
||
{
|
||
"customerId": "uuid",
|
||
"limit": 10,
|
||
"offset": 0
|
||
}
|
||
```
|
||
|
||
**Response:**
|
||
```json
|
||
{
|
||
"readings": [
|
||
{
|
||
"id": "RD987654",
|
||
"value": 128456,
|
||
"date": "2026-02-15",
|
||
"status": "success",
|
||
"photoUrl": "https://..."
|
||
}
|
||
],
|
||
"total": 24,
|
||
"hasMore": true
|
||
}
|
||
```
|
||
|
||
### 7.2 Backend → Stadtwerk SAP
|
||
|
||
#### Endpoint: POST /api/v1/readings/sync-to-sap
|
||
|
||
**Internal Queue Job:**
|
||
```json
|
||
{
|
||
"readingId": "uuid",
|
||
"customerId": "SW123456",
|
||
"meterNumber": "MTR987654",
|
||
"readingValue": 128456,
|
||
"readingDate": "2026-02-15",
|
||
"ocrConfidence": 0.96,
|
||
"source": "smartmeter_app"
|
||
}
|
||
```
|
||
|
||
**SAP Response:**
|
||
```json
|
||
{
|
||
"status": "success",
|
||
"sapReadingId": "SAP-RD-2026-0987654",
|
||
"invoiceGenerated": true,
|
||
"invoiceNumber": "INV-2026-123456"
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 8. SECURITY & COMPLIANCE
|
||
|
||
### 8.1 DSGVO (GDPR) Compliance
|
||
|
||
```
|
||
✅ Privacy by Design:
|
||
- Minimize data collection
|
||
- Only collect: Name, Email, Phone, Address
|
||
- NO unnecessary tracking
|
||
|
||
✅ Data Retention:
|
||
- Photos: Delete after 90 days
|
||
- Readings: Keep 7 years (legal requirement)
|
||
- Logs: Delete after 30 days
|
||
|
||
✅ User Rights:
|
||
- Right to Export: Full data download as PDF/CSV
|
||
- Right to Delete: GDPR-compliant deletion workflow
|
||
- Right to Rectification: Edit own data
|
||
|
||
✅ Consent Management:
|
||
- Explicit opt-in for marketing emails
|
||
- Easy opt-out button
|
||
- Consent logging in DB
|
||
|
||
✅ Third-Party Processors:
|
||
- Google Vision API: DPA signed
|
||
- AWS: DPA signed
|
||
- List all Subprocessors on website
|
||
```
|
||
|
||
### 8.2 Data Security
|
||
|
||
```
|
||
✅ Encryption:
|
||
- TLS 1.3 for all data in transit
|
||
- AES-256 for data at rest (S3)
|
||
- Database encryption enabled
|
||
|
||
✅ Authentication:
|
||
- Passwords: bcrypt (12 rounds)
|
||
- Sessions: JWT with 24h expiry
|
||
- Admin: Require 2FA (TOTP)
|
||
- Biometric: Support Touch/Face ID
|
||
|
||
✅ API Security:
|
||
- Rate Limiting: 1000 req/min per IP
|
||
- CORS: Whitelist origin domains
|
||
- Input Validation: Sanitize all inputs
|
||
- SQL Injection Prevention: Use Parameterized Queries
|
||
|
||
✅ Photo Security:
|
||
- Photos stored in S3 with ACL
|
||
- Signed URLs expire after 24h
|
||
- Photos never logged to any logs
|
||
- Hash comparison for integrity
|
||
```
|
||
|
||
### 8.3 Penetration Testing & Audits
|
||
|
||
```
|
||
- Security Audit: Monthly (Internal)
|
||
- Penetration Testing: Quarterly (External)
|
||
- Bug Bounty Program: Available
|
||
- Vulnerability Disclosure: responsible-disclosure@smartmeter.app
|
||
```
|
||
|
||
---
|
||
|
||
## 9. SUCCESS METRICS & KPIs
|
||
|
||
### 9.1 Product Metrics
|
||
|
||
| Metrik | Target (6M) | Target (12M) | Measurement |
|
||
|--------|------------|-------------|-------------|
|
||
| **App Install Rate** | 30% of users | 60% of users | App Store Analytics |
|
||
| **Monthly Active Users (MAU)** | 40% of customers | 70% of customers | App Backend Logs |
|
||
| **Successful Readings/Month** | 95%+ success rate | 97%+ success rate | Dashboard KPI |
|
||
| **Average Time to Submit** | <3 min | <2 min | User Session Logs |
|
||
| **OCR Accuracy** | 95%+ | 97%+ | Test Dataset |
|
||
| **App Crash Rate** | <0.1% | <0.05% | Crash Analytics |
|
||
| **NPS Score** | >40 | >50 | Monthly Survey |
|
||
|
||
### 9.2 Business Metrics
|
||
|
||
| Metrik | Target (12M) | Measurement |
|
||
|--------|------------|-------------|
|
||
| **Customers Acquired** | 10-15 Stadtwerke | Sales Pipeline |
|
||
| **Annual Recurring Revenue (ARR)** | €800k - €1.2M | Finance |
|
||
| **Customer Retention Rate** | >90% | Churn Analysis |
|
||
| **Customer Satisfaction (CSAT)** | >80% | Survey |
|
||
| **Cost per User** | <€2 | Cost Analytics |
|
||
|
||
### 9.3 Operational Metrics
|
||
|
||
| Metrik | Target | Measurement |
|
||
|--------|--------|-------------|
|
||
| **System Uptime** | 99.9% | Monitoring (Datadog) |
|
||
| **Average Response Time** | <500ms | APM Tools |
|
||
| **OCR Processing Time** | <1s | Backend Logs |
|
||
| **API Error Rate** | <0.1% | API Monitoring |
|
||
| **Database Query Time** | <100ms | Query Logs |
|
||
|
||
---
|
||
|
||
## 10. TIMELINE & MILESTONES
|
||
|
||
### Phase 1: Foundation (Week 1-2)
|
||
- [ ] Team Setup & Onboarding
|
||
- [ ] Development Environment Setup
|
||
- [ ] Database & API Schema Design
|
||
- [ ] UI/UX Design Finalization (Figma)
|
||
|
||
### Phase 2: MVP Development (Week 3-8)
|
||
|
||
**Sprint 1-2 (Week 3-4): Backend Foundation**
|
||
- [ ] Project Setup (Node.js, Express, PostgreSQL)
|
||
- [ ] Authentication API (Sign Up, Login, 2FA)
|
||
- [ ] Database Migrations
|
||
- [ ] CI/CD Pipeline Setup
|
||
|
||
**Sprint 2-3 (Week 5-6): Mobile App**
|
||
- [ ] React Native Project Setup
|
||
- [ ] Camera Integration
|
||
- [ ] Photo Upload Flow
|
||
- [ ] Basic UI Implementation
|
||
|
||
**Sprint 3-4 (Week 7-8): OCR Integration**
|
||
- [ ] Google Vision API Integration
|
||
- [ ] OCR Pipeline (Photo → Digits)
|
||
- [ ] Confidence Scoring
|
||
- [ ] Error Handling
|
||
|
||
**Sprint 4 (Week 8): Submission & Dashboard**
|
||
- [ ] Submission Workflow
|
||
- [ ] Confirmation Emails/SMS
|
||
- [ ] Basic Admin Dashboard
|
||
- [ ] Reading History
|
||
|
||
### Phase 3: Testing & Optimization (Week 9-10)
|
||
- [ ] Unit Tests (Backend + Frontend)
|
||
- [ ] Integration Tests
|
||
- [ ] E2E Tests
|
||
- [ ] Performance Optimization
|
||
|
||
### Phase 4: Pre-Launch (Week 11-12)
|
||
- [ ] Beta Testing (5-10 Kunden)
|
||
- [ ] Feedback Collection
|
||
- [ ] Bug Fixes
|
||
- [ ] Production Deployment
|
||
|
||
### Phase 5: Launch & Support (Week 13+)
|
||
- [ ] Official Launch
|
||
- [ ] Support & Monitoring
|
||
- [ ] Customer Onboarding
|
||
- [ ] Iteration & Improvements
|
||
|
||
---
|
||
|
||
## 11. RISKS & MITIGATION
|
||
|
||
| Risiko | Wahrscheinlichkeit | Impact | Mitigation |
|
||
|--------|------------------|--------|-----------|
|
||
| **OCR Accuracy niedrig** | Medium | Hoch | Testing mit 100+ Meter-Fotos, Google Vision ist 97%+ |
|
||
| **SAP Integration komplex** | Medium | Hoch | Early Integration Testing, Dedicated Integration Engineer |
|
||
| **Mobile Adoption schwach** | Low | Mittel | Good UX Design, Video Tutorials, SMS Reminders |
|
||
| **Performance Issues** | Low | Mittel | Load Testing, Caching Strategy, Database Indexing |
|
||
| **Security Vulnerabilities** | Low | Hoch | Penetration Testing, Code Reviews, Security Audits |
|
||
| **Compliance Issues (DSGVO)** | Low | Hoch | Legal Review Early, Privacy-by-Design, Audit Trail |
|
||
|
||
---
|
||
|
||
## 12. ROLLOUT STRATEGY
|
||
|
||
### Phase A: Beta Phase (Week 13-16)
|
||
- **Customers:** 3-5 Small Stadtwerke
|
||
- **Users:** 500-1000 Endkunden
|
||
- **Goal:** Validate product-market-fit, gather feedback
|
||
- **Success Criteria:**
|
||
- NPS >40
|
||
- OCR Success Rate >95%
|
||
- <1 Critical Bug
|
||
|
||
### Phase B: Soft Launch (Week 17-20)
|
||
- **Customers:** 10-15 Small-to-Medium Stadtwerke
|
||
- **Users:** 5.000-10.000 Endkunden
|
||
- **Goal:** Prove business model, improve onboarding
|
||
- **Success Criteria:**
|
||
- NPS >45
|
||
- Monthly Churn <5%
|
||
- Customer Satisfaction >75%
|
||
|
||
### Phase C: General Availability (Month 6+)
|
||
- **Customers:** 20-30 Stadtwerke (Mix small/large)
|
||
- **Users:** 50.000+ Endkunden
|
||
- **Goal:** Scale to profitability
|
||
- **Success Criteria:**
|
||
- NPS >50
|
||
- Monthly Churn <3%
|
||
- ARR >€1M
|
||
|
||
---
|
||
|
||
## 13. RESOURCE REQUIREMENTS (MVP)
|
||
|
||
### Team Size: 7-9 Personen (6 Monate)
|
||
|
||
| Role | Seniority | FTE | Responsibilities |
|
||
|------|-----------|-----|------------------|
|
||
| Product Manager | Mid | 1.0 | PRD, Roadmap, Prioritization |
|
||
| Tech Lead / CTO | Senior | 1.0 | Architecture, Tech Decisions, Code Quality |
|
||
| Backend Lead | Senior | 1.0 | API Design, Database, Integration |
|
||
| Backend Developer | Mid | 1.0 | Backend Feature Development |
|
||
| React Native Developer | Mid | 1.0 | Mobile App Development |
|
||
| Frontend Developer | Junior | 1.0 | Dashboard Frontend |
|
||
| DevOps / Infrastructure | Mid | 0.5 | CI/CD, Deployment, Monitoring |
|
||
| QA / Tester | Mid | 0.5 | Testing, Bug Reports |
|
||
| **Total** | | **7.5** | |
|
||
|
||
### Budget (6 Monate MVP)
|
||
|
||
| Category | Cost |
|
||
|----------|------|
|
||
| **Salaries (7.5 FTE × €8k/month avg)** | €360.000 |
|
||
| **Infrastructure (AWS, Google API)** | €15.000 |
|
||
| **Tools (IDE, Figma, Jira, Slack)** | €8.000 |
|
||
| **Contingency (10%)** | €38.300 |
|
||
| **Total** | **€421.300** |
|
||
|
||
*Rounded to **€420-450k*** für MVP-Entwicklung
|
||
|
||
---
|
||
|
||
## 14. SUCCESS DEFINITION
|
||
|
||
### Minimum Viable Product (MVP) Success
|
||
- ✅ App funktioniert auf iOS + Android
|
||
- ✅ OCR Accuracy >95%
|
||
- ✅ 3+ Stadtwerke haben erfolgreich abgelesen (100+ Readings)
|
||
- ✅ System uptime: 99.5%
|
||
- ✅ NPS >40 in Beta
|
||
- ✅ Zero critical bugs
|
||
- ✅ DSGVO-compliant
|
||
|
||
### Go-to-Market Success
|
||
- ✅ 10 Customers in Year 1
|
||
- ✅ 500+ Readings/Day durchschnittlich
|
||
- ✅ €800k - €1.2M ARR
|
||
- ✅ <5% Churn rate
|
||
- ✅ >40 NPS Score
|
||
|
||
---
|
||
|
||
## 15. APPENDIX: GLOSSARY
|
||
|
||
| Term | Definition |
|
||
|------|-----------|
|
||
| **OCR** | Optical Character Recognition - automatische Ziffernerkennung aus Fotos |
|
||
| **ARR** | Annual Recurring Revenue - jährliche wiederkehrende Einnahmen |
|
||
| **ACV** | Average Contract Value - durchschnittlicher Vertragswert |
|
||
| **MVP** | Minimum Viable Product - kleinste funktionsfähige Version |
|
||
| **NPS** | Net Promoter Score - Maß für Kundenloyal (0-100) |
|
||
| **DSGVO** | Datenschutz-Grundverordnung (GDPR) |
|
||
| **SAP** | ERP-System für Finanzbuchführung & Abrechnungen |
|
||
| **SaaS** | Software as a Service - Cloud-basiertes Softwaremodell |
|
||
| **Confidence Score** | Genauigkeit der OCR-Erkennung (0-100%) |
|
||
|
||
---
|
||
|
||
## 16. APPROVAL & SIGN-OFF
|
||
|
||
| Role | Name | Signature | Date |
|
||
|------|------|-----------|------|
|
||
| Product Manager | [Name] | __________ | ________ |
|
||
| Engineering Lead | [Name] | __________ | ________ |
|
||
| Business Lead | [Name] | __________ | ________ |
|
||
| Stakeholder | [Name] | __________ | ________ |
|
||
|
||
---
|
||
|
||
**Document Version:** 1.0
|
||
**Last Updated:** Februar 2026
|
||
**Next Review:** April 2026
|
||
**Status:** READY FOR DEVELOPMENT
|