| Ideal für | Konkretes, begrenzbares SymptomUrsache kann mehrere Commerce-Systeme betreffen. | Laufende EntwicklungRoadmap, Wachstum, Relaunch, Kampagnen oder kontinuierliche Betreuung. | Plattforminterne ThemenStatus, Richtlinienprozess, Review oder Funktionen des eigenen Systems. | Klar bekannte FachaufgabeDie Ursache und benötigte Disziplin sind bereits bestimmt. | Niedriges RisikoEinfache, bekannte Aufgabe mit verfügbarer interner Kompetenz. |
|---|
| Startpunkt | „Das funktioniert nicht.“Das Symptom reicht für die erste Einordnung. | Business-Ziel, Briefing, Strategie oder Projektdefinition. | Ticket, Konto-ID, Richtlinie oder Plattformstatus. | Konkrete technische Aufgabenbeschreibung. | Eigene Diagnose und Priorisierung. |
|---|
| Kaufmodell | Bestätigter Scope und PreisStandard-Fix oder Angebot nach technischer Prüfung. | Projekt, Retainer, Paket oder Stundenmodell. | Im Plattformverhältnis enthalten beziehungsweise accountgebunden. | Stunden, Tagessatz oder definierte Aufgabe. | Interne Arbeitszeit und Opportunitätskosten. |
|---|
| Systemgrenzen | Explizit systemübergreifendDer Fehlerpfad kann mehrere Anbieter verbinden. | Oft möglich, abhängig von Team, Mandat und Projektumfang. | Primär auf die eigene Plattform begrenzt. | Meist auf Spezialisierung und Briefing begrenzt. | Abhängig von vorhandener interner Erfahrung. |
|---|
| Ergebnis | Vereinbarter technischer ZustandMit Tests, Dokumentation und sichtbaren Grenzen. | Projektmeilenstein oder laufende Zielentwicklung. | Antwort, Anleitung, Status oder Plattformentscheidung. | Erledigte Fachaufgabe gemäß Briefing. | Selbst geprüft und intern verantwortet. |
|---|
| Zugriff | Rollenbasiert und begrenztNur für den bestätigten Fix; Entfernung nach Abschluss. | Häufig breiter und längerfristig, passend zum Mandat. | Je nach Fall ohne externen Adminzugriff möglich. | Hängt vom individuellen Arbeitsstandard ab. | Bleibt vollständig intern. |
|---|