Start / Seminare / Shopify in der Praxis
Modul
Commerce-Plattform Shopify
Modul 1 von 23 aus dem Seminar Shopify in der Praxis
5 Kapitel in diesem Modul-Video · Laufzeit
Für Teams
Die Videos zeigen, wie es geht. Die Schulung sorgt dafür, dass Ihr Team es danach tut.
Ein Video kann niemanden fragen, warum es ausgerechnet in Ihrem Repository nicht funktioniert. Es kann kein Team auf eine gemeinsame Konvention bringen. Und es setzt sich niemand freiwillig drei Tage hin. In der Schulung sind am Ende alle auf demselben Stand, gearbeitet wurde am eigenen Code, und die offenen Fragen sind entschieden — in ein paar Tagen statt irgendwann nebenbei.
Vorgespräch am Telefon · Programm nach Maß · ab 1 Tag (8 Unterrichtseinheiten) · Teilnahmezertifikat
Transkript
Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.
Commerce-Plattform Shopify
0:00 Wenn ein Unternehmen heute einen Onlineshop plant, fällt der Name Shopify meist innerhalb der ersten fünf Minuten. Und genau da beginnt das Problem: Die Entscheidung ist gefallen, bevor jemand die Frage gestellt hat, was der Shop eigentlich leisten soll. In diesem Modul drehen wir die Reihenfolge um. Wir sehen uns an, was die Plattform ist, wo ihre Grenzen liegen, was sie tatsächlich kostet und wer im Projekt wofür einsteht.
0:24 Am Ende steht kein Lob und keine Warnung, sondern eine Entscheidung, die Sie begründen können — auch gegenüber jemandem, der sie in zwei Jahren hinterfragt.
Commerce-Plattform Shopify
0:33 Wir starten bewusst nicht im Shopify-Admin. Die ersten Entscheidungen eines Shop-Projekts fallen vor dem ersten Klick, und sie sind die teuersten: Welche Anforderungen muss die Plattform tragen? Was kostet sie wirklich, wenn man Apps, Entwicklung und Betrieb mitrechnet? Und wer trägt am Ende die Verantwortung für Preise, Inhalte und Steuern?
0:53 Diese vier Kapitel führen Sie dorthin. Zum Abschluss bauen Sie selbst eine Anforderungsmatrix — für einen Beispielshop, der uns durch das ganze Seminar begleiten wird.
Plattform und Ökosystem
1:03 Beginnen wir mit der Frage, was Shopify eigentlich ist. Die Antwort fällt anders aus, als viele erwarten — und sie hat Folgen für alles, was danach kommt, besonders für die Art, wie Sie Ihre Produktdaten anlegen. Stellen Sie sich einen Marktstand vor. Es gibt die Ware im Lager, eine Kasse und ein Kassenbuch — und davor kann jemand einen Stand aufbauen, einen zweiten am anderen Ende der Stadt, oder die Ware über einen Katalog anbieten.
1:29 Genau so ist Shopify gebaut. Im Kern liegen Produktdaten, Warenkorb, Checkout, Zahlung und Bestellungen. Darüber liegen die Oberflächen und Kanäle. Das klingt nach einer Feinheit, ist aber die wichtigste Einsicht dieses Moduls: Ihr Onlineshop ist ein Kanal von mehreren. Wer ihn für das Produkt hält, plant den Katalog zu eng.
1:50 Warum lohnt sich dieser Umweg über die Architektur, bevor wir irgendetwas einstellen? Weil jede spätere Arbeit daran hängt. Der Checkout ist der am stärksten geschützte Teil der Plattform — das schränkt ein, aber es ist auch der Grund, warum er zuverlässig funktioniert und warum Shopify ihn ständig verbessern kann. Und weil jeder Kanal dieselben Produktdaten liest, entscheidet deren Qualität mit, wie gut ein Marktplatz oder ein KI-Assistent Ihre Produkte darstellt.
2:16 Was die Plattform nicht kann, kaufen Sie als App dazu. Auch das ist eine Entscheidung mit Folgen — und keine kostenlose. Lesen Sie dieses Schaubild von unten nach oben, denn so ist auch die Abhängigkeit. Ganz unten der Commerce-Kern: Produkte, Bestände, Warenkorb, Checkout, Bestellungen. Darüber die Storefront — ein Theme oder eine eigene Oberfläche. Ganz oben die Kanäle.
2:39 Die vierte Schicht steht bewusst daneben: Erweiterungen greifen an definierten Punkten in alle anderen. Der springende Punkt ist die Richtung: Eine schwache Datenschicht können Sie oben nicht reparieren. Ein schönes Theme rettet keinen Katalog ohne Attribute. Deshalb kommt im dritten Modul der Katalog vor dem Design. Diese Liste ist nicht zum Abhaken da — sie zeigt ein Muster.
3:03 Jeder Kanal bedient eine andere Situation: Shop die wiederkehrende Kundschaft, Social die Entdeckung, Marktplätze die Reichweite, POS den Kauf im Laden. Interessant ist der vierte Eintrag. Agentic Storefronts sind kein Ausblick, sondern ein regulärer Kanal für die Auffindbarkeit in KI-Assistenten. Was alle verbindet: Sie lesen denselben Katalog, stellen aber je eigene Ansprüche an Pflichtfelder und Bilder. Ein Kanal ist deshalb nie nur zusätzlicher Umsatz.
3:32 Er ist zuerst zusätzliche Pflege — und die muss sich rechnen. Diese vier Fehler sehe ich in Projekten immer wieder, und sie haben eine gemeinsame Wurzel: Der Shop wird als Website gedacht statt als Datenbestand mit mehreren Schaufenstern. Wer den Katalog nur für das Theme pflegt, merkt das erst, wenn ein Marktplatz die Hälfte der Artikel ablehnt.
3:52 Wer das Ladengeschäft als zweites System führt, verkauft online Ware, die längst weg ist. Und der letzte Punkt ist der teuerste: Apps werden gerne als Funktionen verbucht. Sie sind aber laufende Kosten und laufende Abhängigkeiten — dazu kommen wir in Kapitel drei ausführlich.
Geschäftsmodelle und Umsetzungswege
4:09 Jetzt wird es konkreter. Zwischen dem Standardshop von der Stange und einer komplett selbst gebauten Oberfläche liegen zwei Zwischenstufen — und die Wahl dazwischen ist selten eine Frage des Geschmacks. Denken Sie an ein Haus. Sie können eine fertige Wohnung beziehen, Sie können sie umbauen, Sie können Anbauten kaufen — oder Sie bauen selbst, vom Fundament an.
4:29 Jeder Schritt nach rechts bringt mehr Freiheit und mehr Eigenverantwortung: für Hosting, Barrierefreiheit, Performance und für jedes künftige Update. Wichtig ist dabei eine Sache, die im Projektalltag gerne untergeht: Diese Entscheidung fällt nicht einmal für das ganze Projekt. Sie fällt je Anforderung. Eine einzige Sonderfunktion rechtfertigt keinen Eigenbau des gesamten Frontends.
4:52 Die interessante Spalte in dieser Tabelle ist die rechte. Was man gewinnt, steht meist im Angebot; was man übernimmt, steht selten dort. Ein Standard-Theme heißt: schnell live, aber Gestaltung im Rahmen des Themes. Eine Theme-Anpassung heißt: eigenes Erscheinungsbild, aber Pflege bei jedem Update. Und beim letzten Eintrag zitiere ich Shopify wörtlich — Headless sei die größte Kontrolle und zugleich die meiste Arbeit.
5:17 Das ist bemerkenswert offen für eine Produktdokumentation, und man sollte es ernst nehmen. Die Arbeit verschwindet nicht, sie wechselt nur den Besitzer. Diese Gegenüberstellung zeigt weniger einen technischen als einen organisatorischen Unterschied. Links rendert und hostet Shopify, und die Redaktion arbeitet im Editor — sie kann eine Landingpage am Freitagnachmittag ändern.
5:41 Rechts betreiben Sie das Frontend selbst, und jede Änderung läuft über ein Release. Das ist keine Wertung, sondern eine Frage Ihrer Organisation. Wenn das Marketing gewohnt ist, selbst zu arbeiten, dann kostet Headless nicht nur Entwicklungszeit, sondern auch Tempo. Hydrogen und Oxygen sind der kürzeste Weg dorthin — aber eben ein Weg dorthin, keine Abkürzung drum herum.
6:04 Der rote Faden dieser vier Schritte ist einfach: Sie sammeln erst die Anforderungen, die der Standard nachweislich nicht erfüllt — nachweislich, nicht gefühlt. Dann prüfen Sie je Anforderung, ob eine Einstellung, eine App oder Code nötig ist. Entscheidend ist der dritte Schritt: Halten Sie den Aufwand nicht gegen die Einführung, sondern gegen die laufende Pflege.
6:24 Eine Anpassung kostet einmal Entwicklung und dann bei jedem Update wieder. Und schreiben Sie am Ende auch die Nicht-Ziele auf. Was nicht dokumentiert ist, kommt in sechs Monaten durch die Hintertür zurück. Der erste Punkt ist der häufigste überhaupt: Headless wegen der Ladezeit, ohne das Theme je gemessen zu haben. Das ist ungefähr so, als würden Sie das Auto wechseln, weil Ihnen der Verbrauch zu hoch vorkommt — ohne je getankt und gerechnet zu haben.
6:50 Der zweite Punkt begegnet uns im B2B-Modul wieder: Geschäfts- und Endkunden werden getrennt gedacht, obwohl beide auf denselben Katalog zugreifen. Und der letzte Punkt ist ein menschlicher: Der Standardweg wirkt unambitioniert. Er ist aber in den allermeisten Fällen der, der nach drei Jahren noch trägt.
Tarife, Kosten und Abhängigkeiten
7:09 Kommen wir zum Geld — und zu etwas, das viele überrascht: Der Tarif bestimmt nicht nur den Preis, sondern auch, welche Funktionen überhaupt existieren. Bei den meisten Softwareprodukten kauft man mit dem höheren Tarif vor allem mehr Volumen. Bei Shopify ist das anders: Mitarbeiterkonten, Lagerstandorte, die Zahl der B2B-Kataloge, der Umfang der Checkout-Anpassung und die Grenzen des API-Zugriffs hängen am Tarif.
7:33 Das ist wichtig für die Projektplanung, weil eine Pflichtanforderung technisch nicht scheitern muss — sie scheitert am Tarif. Und diese Art von Hindernis fällt oft spät auf, meist genau dann, wenn die Lösung schon gebaut ist. Prüfen Sie deshalb früh, ab welchem Tarif eine Muss-Anforderung überhaupt verfügbar ist. Diese Zahlen sind ein Stand, kein Naturgesetz — sie gelten bei jährlicher Zahlung und hängen von Region und Laufzeit ab.
7:59 Interessanter als die absoluten Beträge ist die Bewegung: Der Grundpreis steigt kräftig, die Transaktionsgebühr sinkt nur langsam. Daraus folgt eine einfache Rechenübung, die jedes Projekt einmal machen sollte: Ab welchem Umsatz holt die niedrigere Gebühr den höheren Grundpreis wieder herein? Und achten Sie auf die letzte Spalte.
8:17 Basic bringt keine Mitarbeiterkonten mit — wer dort mit fünf Personen arbeitet, landet schnell beim geteilten Zugang, und den werden wir im nächsten Modul als Problem wiedersehen. Die Gesamtkosten eines Shops sind selten dort, wo man sie sucht. Tarif und Transaktionsgebühren sind der sichtbare Teil und meist der kleinere.
8:37 Darunter liegen Apps als monatliche Kosten, oft mit einer Staffel nach Bestellvolumen — die tut genau dann weh, wenn das Geschäft läuft. Dann die Entwicklung, einmalig plus Pflege bei jedem Plattform-Update. Und der größte Posten wird fast nie budgetiert: der Betrieb. Produktpflege, Support, Retouren, Prüfungen. Das ist keine Warnung vor Shopify — das gilt für jede Plattform. Aber es gehört in die Rechnung, bevor sie jemand unterschreibt.
9:05 Der erste Punkt betrifft eine Falle, die wir in Modul zehn noch genauer ansehen: Fremde Zahlungsanbieter kosten zusätzliche Gebühren, auch wenn Shopify Payments aktiv ist. Wer den Anbieter allein nach Konditionen wählt, vergisst diesen Aufschlag. Der dritte Punkt gehört zum B2B-Modul: Drei Kataloge klingen in der Planung reichlich und reichen im Betrieb oft nicht. Und der letzte Punkt verdient eine nüchterne Einordnung.
9:29 Liquid-Themes und Checkout-Erweiterungen binden Sie an die Plattform. Das ist kein Grund, es nicht zu tun — es ist ein Grund, es bewusst zu tun und aufzuschreiben.
Rollen im Shop-Projekt
9:39 Bleibt die Frage, die in Projekten am liebsten vertagt wird: Wer entscheidet, wer baut, und wer steht am Ende dafür gerade? In einem typischen Shop-Projekt sitzen vier Parteien am Tisch: das Unternehmen, eine Agentur, Entwicklerinnen und Entwickler, dazu die Anbieter der Apps. Die Arbeit verteilt sich, die Verantwortung nicht.
9:59 Shopify formuliert das in seiner Dokumentation an mehreren Stellen bemerkenswert deutlich: Die Plattform stellt Werkzeuge bereit — für Preise, Inhalte, Steuern und Datenschutz bleibt der Händler verantwortlich. Diesen Satz werden Sie in diesem Seminar noch dreimal hören, bei den Steuern, beim Datenschutz und bei den KI-Werkzeugen. Er ist die wichtigste Konstante der ganzen Woche.
10:21 Lesen Sie die rechte Spalte als das, was sie ist: Verantwortung, die nicht wandert. Die Agentur setzt um, aber sie entscheidet nicht über Ihr Sortiment. Die Entwicklung baut Erweiterungen, aber sie bestimmt nicht, welche Anforderung ein Muss ist. Der App-Anbieter steht für die Daten ein, die er sieht — deshalb ist die Frage, welche Daten das sind, eine fachliche und keine technische.
10:44 Und Shopify steht für Plattform, Checkout und Verfügbarkeit. Wenn in Ihrem Projekt eine dieser Zeilen keinen Namen hat, dann ist sie nicht verteilt. Sie ist offen. Diese fünf Schritte beschreiben eine Bestandsaufnahme, die gerne übersprungen wird, weil sie unspektakulär ist. Zuerst nehmen Sie auf, was da ist: Katalog, Adressen, Kundendaten, laufende Verträge.
11:06 Dann klären Sie, was bleiben muss und was bewusst entfällt — das Wort bewusst ist hier entscheidend. Der dritte Schritt trifft fast jedes Projekt: Kunden- und Bestellhistorie zu migrieren ist aufwendiger, als es aussieht. Und Schritt vier ist der, den man am teuersten nachholt: Über Weiterleitungen und Stichtag wird entschieden, bevor gebaut wird. Warum das so ist, sehen wir in Modul sieben.
11:30 Der erste Punkt ist unangenehm, aber häufig: Wenn im Haus niemand für Preise zuständig ist, entscheidet sie faktisch die Agentur. Nicht aus Anmaßung — sondern weil jemand entscheiden muss. Der zweite Punkt kostet direkt Geld: Weiterleitungen nach dem Umschalten zu planen heißt, die Rankings sind bereits weg. Der dritte beschreibt den Normalzustand vieler gewachsener Shops: Niemand verantwortet die Apps, und nach zwei Jahren weiß keiner mehr, wofür jede einmal installiert wurde.
11:58 Und der vierte ist der Grund, warum wir gleich eine Matrix bauen: Was nicht dokumentiert ist, wird neu diskutiert.
Übung
12:05 Genug Theorie. Sie bekommen jetzt ein Unternehmen, das uns durch alle 23 Module begleiten wird — und die erste Entscheidung, die dieses Unternehmen zu treffen hat. Steglicht ist ein mittelständischer Anbieter hochwertiger Büro- und Homeoffice-Produkte: rund zwanzig Artikel mit Varianten, zwei Ladengeschäfte, und seit einiger Zeit wachsende Nachfrage von Firmenkunden wie der Federhaus GmbH.
12:28 Der bestehende Shop ist gewachsen, kennt keine strukturierten Produktdaten, und Firmenanfragen landen im Sammelpostfach. Das ist keine Ausnahme, sondern der Normalfall im Mittelstand — und eine ziemlich gute Ausgangslage zum Üben. Denn alles, was diesem Unternehmen fehlt, werden wir in den kommenden Modulen nacheinander aufbauen.
12:47 Ihre Aufgabe ist eine Anforderungsmatrix für Steglicht. Das Lernziel steht bewusst nicht bei der Technik, sondern beim Ordnen: Anforderungen so sortieren, dass sich Standardfunktion, App und Eigenentwicklung sauber trennen lassen. Erfolgreich sind Sie, wenn mindestens zehn Anforderungen als Muss, Soll oder Nicht-Ziel eingestuft sind, jede mit Umsetzungsweg und benanntem Verantwortlichen.
13:10 Und wenn Sie früh fertig sind, kommt die Königsdisziplin: Ordnen Sie jeder Muss-Anforderung den Tarif zu, ab dem sie überhaupt verfügbar ist. Genau diese Zuordnung rettet später Projekte. Fünfundvierzig Minuten, fünf Schritte. Sammeln Sie zuerst Anforderungen aus Sortiment, Kundschaft und Ladengeschäft — auch das Ladengeschäft, es gehört dazu.
13:30 Dann stufen Sie ein und begründen die Einstufung; die Begründung ist wichtiger als die Einstufung selbst. Danach wählen Sie je Anforderung den Weg und notieren die Folgekosten. Schritt vier ist der, der weh tut: Markieren Sie die drei teuersten Anforderungen und prüfen Sie ehrlich, ob sie wirklich Muss bleiben. Und lesen Sie zum Schluss die Nicht-Ziele laut vor. Das klingt albern und wirkt erstaunlich gut.
13:55 Vier Fallen, die Sie in den nächsten Minuten selbst erleben werden. Erstens: Alles wird zum Muss, weil niemand gerne etwas streicht — dagegen hilft nur eine Obergrenze. Zweitens: Die Matrix nennt Funktionen statt Anforderungen und nimmt damit die Lösung vorweg. Schreiben Sie, was erreicht werden soll, nicht womit. Drittens fehlt das Ladengeschäft, weil das Projekt als Onlinethema gestartet ist. Und viertens bleiben die Nicht-Ziele ungeschrieben.
14:21 Wenn Sie aus diesem Modul eine Sache mitnehmen, dann diese: Das aufgeschriebene Nein ist die wertvollste Zeile der ganzen Matrix.
Dieses Modul als Schulung für Ihr Team
Das Video zeigt den Stoff. In der Schulung arbeitet Ihr Team damit — an Ihrem eigenen Code, mit Übungen und mit den Fragen, die ein Video nicht beantwortet. Sie wählen die Module aus Shopify in der Praxis, wir bauen daraus ein Programm.
5 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung