Checkout
Warenkorb, Daten, Lieferung und Zahlung ohne echte Bestellung.
täglich oder alle 6 Stunden
Weniger Überraschungen. Schnellere Reaktion. Schriftlicher Bericht.
Ihr Shop soll verkaufen, auch wenn niemand das WordPress-Dashboard beobachtet.
Der Store Reliability Plan ersetzt zufällige Updates und verspätete Fehlermeldungen durch einen kontrollierten Betriebsrhythmus.
Shop-Daten per E-Mail sendenSchriftliche Empfehlung in einem Arbeitstag.
Reliability Commerce
1.490 EUR / Monat
Aktiver Shop mit Kampagnen
P1: 4 Arbeitsstunden
bis 6 Std. kleine Änderungen
Vier Kontrollen für den Umsatz
Uptime allein reicht nicht, wenn Warenkorb oder Zahlung fehlschlägt.
Updates
Snapshot, Staging und kritische Tests vor Produktion.
monatlich oder zweiwöchentlich
Backup und Restore
Integrität und regelmäßiger Wiederherstellungstest.
monatlich oder quartalsweise
Core Web Vitals
Konstante URLs zeigen Regressionen nach Änderungen.
monatlich oder wöchentlich
Drei Betreuungsstufen
Jeder Plan enthält Bericht und klares Budget für kleine Änderungen.
Reliability Essential
690 EUR / Monat
Stabiler Shop mit wenigen Änderungen
- Uptime alle 5 Minuten
- monatlicher Checkout-Test
- monatliche Staging-Updates
- Backup- und CWV-Prüfung
P1: 1 Arbeitstag
bis 2 Std. kleine Änderungen
Reliability Commerce
1.490 EUR / Monat
Aktiver Shop mit Kampagnen
- Uptime und täglicher Checkout
- Updates alle zwei Wochen
- monatlicher Restore-Test
- wöchentliche CWV-Prüfung
P1: 4 Arbeitsstunden
bis 6 Std. kleine Änderungen
Reliability Critical
2.890 EUR / Monat
Hohe Ausfallkosten und häufige Releases
- Checkout alle 6 Stunden
- wöchentliches Updatefenster
- quartalsweiser Restore-Test
- Regression nach Release
P1: 2 Arbeitsstunden
bis 12 Std. kleine Änderungen
P1 bedeutet Ausfall von Produktion, Checkout oder Zahlung. Reaktionszeiten gelten an CET-Arbeitstagen und garantieren keine Behebungszeit.
Monatsbericht ohne Fülltext
Der Bericht zeigt Betrieb, Änderungen und wachsende Risiken.
- 01Verfügbarkeit und Vorfälle
- 02Checkout-Tests
- 03Updates und Rollbacks
- 04Backup und Restore
- 05Core Web Vitals
- 06Risiken und Empfehlungen
Verantwortungsgrenzen
Baseline zuerst
Bestehende Fehler und technische Schulden sind nicht automatisch enthalten.
Kontrollierte Fenster
Updates haben Snapshot, Staging und Rollback.
Änderungsbudget
Größere Features und Integrationen werden separat geschätzt.
Drittsysteme
Hosting, Zahlungsanbieter und externe APIs können nicht garantiert werden.
Warum scheitert die Erstzahlung im WooCommerce-Shop?
Ein anonymisierter Fall aus Österreich. Ein Verlag verkauft Abonnements über WooCommerce, die erste Zahlung startet das Abo. Der Support meldete 19 Bestellungen mit Status Zahlung ausstehend. Ausgewertet habe ich 90 Tage: rund 35 echte Fälle nach Abzug der Testkonten.
| Zahlungsart | Abgebrochene Erstzahlungen | Typischer Grund |
|---|---|---|
| Karte (Stripe) | rund 10 % | Abgelehnte Karten und ein eigener Cluster fehlgeschlagener SCA/3DS-Authentifizierung |
| Klarna | rund 16 % | Kundin oder Kunde verlässt den Klarna-Dialog vorzeitig (Customer aborted purchase) |
| PayPal | rund 4 % | Kein Ablehngrund gespeichert |
| Kauf auf Rechnung | rund 6 % | Keine Freigabe für den Rechnungskauf |
Näherungswerte, 90 Tage, ein Shop.
So wurde gemessen
Reine Leseabfragen auf Elternbestellungen in vier Status: ausstehend, fehlgeschlagen, storniert und Papierkorb. Dazu die Bestellnotizen, denn der feste Textbaustein des Supports zum versendeten Zahlungslink ist maschinell erkennbar.
Warum eine Momentaufnahme zu wenig zeigt
Zahlung ausstehend hält nur ein paar Tage. Danach wird die Bestellung fehlgeschlagen, storniert und landet im Papierkorb, der sich nach rund 30 Tagen selbst leert. Von 19 gemeldeten Beispielen gab es 8 nicht mehr. Eine Person versuchte am selben Tag die Karte, scheiterte an 3DS und brach Klarna zweimal ab.
Was sich geändert hat
Ein monatlicher Export ersetzt das händische Durchsehen. 3DS als technisches Problem ist jetzt getrennt vom Kaufverhalten bei Klarna und von fehlenden Daten bei PayPal. Für Stripe liegen Fragen zu den Ablehncodes im 3DS-Cluster bereit, für Klarna Fragen zu den Abbruchpunkten.
Gescheiterte Erstzahlungen lassen sich nicht rückwirkend messen, weil der Shop seine Spuren selbst löscht. Es hilft nur laufende Erfassung.
Der Sprint-Bericht wird zur Ausgangslage der Betreuung
Der Sprint-Bericht wird zur Baseline und erspart eine wiederholte Startprüfung.
Häufig gestellte Fragen
Sind Reparaturen unbegrenzt?
Nein, jede Stufe hat ein klares Stundenbudget.
Erzeugt das Monitoring echte Bestellungen?
Standardmäßig stoppt es vor der Zahlung.
Sind Updates automatisch?
Kritische Updates laufen zuerst über Snapshot und Staging.
Gibt es 24/7-Support?
Nein, die Reaktion gilt in CET-Geschäftszeiten.
Start ohne Rescue Sprint?
Ja, nach einem bezahlten Baseline-Audit.
Senden Sie Shop, Release-Frequenz und Ausfallkosten.
Sie erhalten Stufenempfehlung und Startumfang.
Shop-Daten per E-Mail senden