Onlineshop entwickeln lassen: den gesamten Bestellzyklus gestalten

Verkaufsregeln vor der Shop-Einrichtung festlegen

Wenn Sie einen Onlineshop entwickeln lassen und das Projekt nur mit einer Kategorienliste und einigen Produktbildern beginnen, kann dies dazu führen, dass geschäftliche Entscheidungen während der Entwicklung immer wieder geändert werden. Zunächst klären wir, was das Unternehmen verkauft, in welche Länder oder Regionen es liefert, wie es Preise berechnet und welches Team die Bestellungen vorbereitet. Digitale Produkte, physische Waren, personalisierte Produkte und Waren in Großhandelskartons werden nicht in denselben Kaufprozess gezwängt. Der Einrichtungsumfang muss erklären, wie sich diese Unterschiede auf die Kunden und die betrieblichen Abläufe auswirken.

• Vorbereitung auf Händler- und Anbieterseite: Das Zahlungskonto, der Vertrag mit dem Versanddienstleister und die erforderlichen Unternehmensunterlagen werden vom Shopbetreiber bereitgestellt. Die Antragsbedingungen können je nach Anbieter variieren; die technische Entwicklung garantiert keine Freigabe des Geschäftskontos.
• Katalogquelle: Es wird festgelegt, aus welcher Datei oder welchem System Produktname, SKU, Barcode, Variantenbeziehung, Bild und Beschreibung übernommen werden. Eine vorhandene Datei bedeutet nicht, dass die Daten sauber sind; doppelte Codes und fehlende Optionen werden vor dem Import geprüft.
• Preis und Lieferung: Steuerdarstellung, Versandkostenschwelle, Liefergebiet, Ausnahmen vom kostenlosen Versand und kombinierbare Aktionen werden dokumentiert. Kunden sollen am Ende des Kaufprozesses nicht auf unerwartete Bedingungen stoßen.
• Retouren und Kundenkommunikation: Die Verantwortlichen für Rückgabeanfrage, Prüfung, Annahme und Erstattung werden festgelegt. Ob für jedes Produkt dieselben Rückgaberegeln gelten, wird mit der Rechtsberatung des Unternehmens geprüft.
• Texte und Zustimmungsnachweise: Vorvertragliche Informationen, Verkaufsbedingungen, Datenschutzhinweise und erforderliche Einwilligungstexte werden von den zuständigen Personen bereitgestellt. Die Software kann den Zeitpunkt der Zustimmung und die zugehörige Textversion dokumentieren; das Entwicklungsteam übernimmt nicht die Verantwortung für die rechtliche Richtigkeit der Texte.

Im ersten Gespräch zum Leistungsumfang nehmen wir nicht alle denkbaren Module auf, sondern erarbeiten den Ablauf, den Kunden für den Kauf und das Team für den Abschluss der Bestellung benötigen. Der Leitfaden zu Shopfunktionen (auf Türkisch) kann dabei als Checkliste dienen. Werden Zahlungs-, Bestands- und Lieferstatus einer Bestellung getrennt definiert, lassen sich noch offene Entscheidungen vor dem Start leichter erkennen.

Geschäftsregeln statt Funktionslisten bestimmen die Systemwahl

Ein gemieteter Shopdienst, ein Open-Source-Shop und eine individuelle Entwicklung stehen für unterschiedliche Verantwortungsmodelle. Bei der Auswahl reicht es nicht, nur die anfänglichen Einrichtungskosten zu betrachten: Datenexport, Verantwortung für Updates, Abhängigkeiten von Erweiterungen und Regeln, die vom üblichen Ablauf abweichen, müssen gemeinsam berücksichtigt werden. Unnötige Individualsoftware für einen einfachen Katalog kann die Betriebskosten ebenso erhöhen wie der Versuch, komplexe Händlerpreise dauerhaft mit provisorischen Erweiterungen abzubilden.

Bei der Entwicklung durch HazırSoft können Systeme auf Basis von PHP/Laravel und MySQL eingesetzt werden; die Technologiewahl allein ist kein Qualitätsmerkmal. Entscheidend ist eine nachvollziehbare Gestaltung: Wo wird der Preis berechnet, welches System ist die maßgebliche Bestandsquelle und welcher Vorgang verändert den Bestellstatus? Wenn vorhandene Komponenten ausreichen, werden sie passend angepasst, statt unnötig neu entwickelt. Abweichende Geschäftsprozesse werden in den Umfang der individuellen Entwicklung aufgenommen.

Bei Migrationsprojekten prüfen wir den Datenexport des bisherigen Systems frühzeitig. Der Erhalt von Produktkennungen, die Zuordnung alter URLs, Zustimmungsnachweise der Kunden und die Lesbarkeit der Bestellhistorie sind eigenständige Aufgaben. Lässt sich das Verfahren zur Passwortverschlüsselung nicht in das neue System übernehmen, kann ein sicherer Ablauf zum Zurücksetzen der Passwörter erforderlich sein. Ebenso wichtig wie übereinstimmende Datensatzanzahlen sind korrekte Beziehungen zwischen Produkten und Varianten sowie zwischen Bestellungen und Positionen. Für die Umstellung wird außerdem entschieden, in welchem System offene Bestellungen abgeschlossen werden.

Zahlungserfolg anhand geprüfter Benachrichtigungen feststellen

Dass ein Kunde im Zahlungsprozess die Erfolgsseite erreicht, ist allein kein Beleg für den Zahlungseingang. Die serverseitige Benachrichtigung des Anbieters muss anhand einer Signatur oder eines anderen Verifizierungsverfahrens geprüft werden; Betrag, Währung und Bestellkennung müssen mit dem erwarteten Datensatz übereinstimmen. Eine erneut gesendete Benachrichtigung darf weder eine neue Bestellung noch einen zweiten Bestandsabzug auslösen. Auch wenn die Netzwerkverbindung abbricht und der Browser des Kunden nicht zum Shop zurückkehrt, wird ein Transaktionsprotokoll benötigt, mit dem sich der tatsächliche Zahlungsstatus prüfen lässt.

Technische und geschäftliche Grenzen bei der Anbieterwahl

iyzico, PayTR oder virtuelle POS-Lösungen von Banken werden anhand des Unternehmenskontos, der API-Möglichkeiten des Anbieters und des Verkaufsmodells bewertet. Ratenzahlungen, ausländische Karten oder unterschiedliche Währungen werden nicht für jedes Konto gleichermaßen unterstützt. Soll ein Anbieter aus dem Ausland eingesetzt werden, werden das Tätigkeitsland des Unternehmens und die Eignung des Kontos gesondert geprüft. Eine Zahlungsmethode, deren Verfügbarkeit für das Unternehmenskonto nicht bestätigt ist, wird nicht als verbindliche Funktion in den Lieferumfang aufgenommen.

Fehlgeschlagene Zahlungen und Erstattungen gehören ebenfalls zum Bestellablauf

• Bestellung mit ausstehender Zahlung: Es wird festgelegt, wie lange der Bestand reserviert bleibt, wie er nach Ablauf der Frist freigegeben wird und wie eine verspätete Erfolgsmeldung behandelt wird.
• Stornierung und Teilerstattung: Bestellstornierung, Versandstornierung und Rückzahlung sind unterschiedliche Vorgänge. Bei der Rückgabe einer Position muss klar sein, wie der Rabatt- und Versandkostenanteil berechnet wird.
• Erneuter Zahlungsversuch: Die erneute Zahlung für denselben Warenkorb nach einem fehlgeschlagenen Versuch wird unter Berücksichtigung der Risiken doppelter Bestellungen oder doppelter Belastungen gestaltet.

Statt Kartendaten im Shop zu speichern, werden die sicheren Zahlungskomponenten des Anbieters bevorzugt. Wird eine Funktion wie eine gespeicherte Karte benötigt, prüfen wir den vom Anbieter zugelassenen Token-Mechanismus, anstatt unverschlüsselte Kartendaten zu speichern. Im Verwaltungsbereich werden Zahlungsstatus und Bearbeitungsstatus der Bestellung getrennt angezeigt; das operative Team soll eine Bestellung mit ausstehender Zahlung nicht versehentlich versenden. Für den Zahlungsabgleich bleiben die Transaktionsnummer des Anbieters und die Verknüpfung zur Bestellung zugänglich.

Bestandsquelle und Versandverantwortung im Mehrkanalvertrieb

Dass ein Produkt gleichzeitig im Onlineshop und auf einem Marktplatz angezeigt wird, bedeutet nicht, dass die Bestände jederzeit vollkommen übereinstimmen. API-Verzögerungen, Abfragelimits und manuelle Lagervorgänge können kurzfristige Abweichungen zwischen den Systemen verursachen. Deshalb wird zunächst die maßgebliche Bestandsquelle ausgewählt; anschließend werden verkaufbare Menge, Sicherheitsbestand und Regeln zur Kanalverteilung festgelegt. Der Reservierungs- und Verteilungsansatz, der das Risiko einer gleichzeitigen Freigabe des letzten Artikels für zwei Kanäle verringern soll, wird nach dem Verkaufsvolumen des Unternehmens gestaltet.

Bei der Marktplatzanbindung reicht es nicht aus, nur den Produkttitel zu übertragen. Kategorieattribute, kanalspezifische Produktkennungen, Variantenoptionen und Preisregeln werden zugeordnet. Identische Preise im eigenen Shop und auf dem Marktplatz werden nicht vorausgesetzt; Provisionen oder Aktionsbedingungen können unterschiedlich sein. Eingehende Bestellungen werden mit ihren Kanalkennungen gespeichert. Wird derselbe Datensatz erneut empfangen, darf keine zweite Bestellung entstehen. Fehlgeschlagene Übertragungen müssen in einer für das operative Team sichtbaren Aufgabenliste erscheinen.

Bei der Versanddienstleisteranbindung sind Barcode-Erstellung, Paketvorbereitung und tatsächliche Zustellung getrennte Ereignisse. Muss eine Bestellung auf mehrere Pakete aufgeteilt, aus unterschiedlichen Lagern versendet oder eine Position später verschickt werden, muss das Modell dies abbilden können. Die Erstellung eines Barcodes reicht möglicherweise nicht aus, um automatisch eine Versandmeldung an den Kunden zu senden; gemeinsam wird festgelegt, in welcher Phase die Benachrichtigung erfolgt.

Bevor Zustellstatus des Versanddienstleisters direkt den Statuswerten des Shops zugeordnet werden, wird eine Zuordnungstabelle erstellt. Eine nicht zustellbare Sendung, eine Kundenretoure und eine Rückführung ins Lager erfordern unterschiedliche Abläufe. Werden Rechnungs- und ERP-Anbindungen ergänzt, wird geklärt, welches System die führenden Datensätze für Bestellungen, Versand und Buchhaltung enthält. So erzeugt die Aktualisierung einer Ansicht nicht versehentlich einen neuen Beleg in einem anderen System.

Katalog-, Aktions- und Händlerregeln beherrschbar machen

Das Produktmodell muss die für Kunden sichtbaren Optionen mit der im Lager geführten Einheit verbinden. Zu Beginn wird festgelegt, dass Farb- und Größenvarianten eigene Bestandskennungen erhalten, wie Filterattribute von kaufbaren Optionen getrennt werden und wie sich die Bestandteile eines Produktpakets auf den Bestand auswirken. Eine später hinzugefügte Option darf die historischen Angaben einer bestehenden Bestellung nicht verändern. Deshalb bleiben Name, Preis und relevante Optionsangaben zum Kaufzeitpunkt in der Bestellposition erhalten.

• Bestandsbewegung: Physische Lagermenge, für Bestellungen reservierte Menge und zum Verkauf freigegebene Menge sind unterschiedliche Größen. Ob ein zurückgesendetes Produkt wieder verkauft werden kann, lässt sich gegebenenfalls erst nach der Prüfung entscheiden.
• Überschneidende Aktionen: Gutschein, Mengenrabatt und kostenloser Versand können in einem Warenkorb zusammenkommen. Prioritäten, Obergrenzen und ausgeschlossene Produkte werden eindeutig definiert; die im Verwaltungsbereich sichtbare Preisberechnung muss mit dem Zahlungsschritt übereinstimmen.
• Berechtigungen und Nachvollziehbarkeit: Ein Lagermitarbeiter darf möglicherweise Bestellungen vorbereiten, aber keine Preislisten ändern. Bei kritischen Vorgängen wie Retourenfreigaben und Preisänderungen werden der verantwortliche Benutzer und der Zeitpunkt protokolliert.
• Kundenerlebnis: Gastbestellungen, Adressprüfung und Bestellverfolgung werden entsprechend dem Geschäftsmodell gestaltet. Fehlermeldungen müssen erklären, welches Feld wie zu korrigieren ist; nicht jeder Fehler wird auf eine allgemeine Fehlermeldung reduziert.

Im B2B-Einkauf sind Berechtigungen ebenso wichtig wie Preise

In einem Händlerportal kann ein Unternehmen mehrere Benutzer haben. Getrennte Rollen für Bestellvorbereitung und Freigabe, händlergruppenspezifische Preise, Mindestkartonmengen und Zahlungsziele unterscheiden sich von einem B2C-Shop. Wird ein Kundenkontosaldo angezeigt, müssen dessen Quelle und Aktualität klar sein; eine Ansicht ohne ERP-Anbindung wird nicht als finanzielle Echtzeitauskunft dargestellt. Beim Übergang vom Angebot zur Bestellung wird außerdem festgelegt, bis zu welchem Datum der Preis gilt und ob Bestand reserviert wird.

Projektbeispiele können als Ausgangspunkt für das Gespräch über das Geschäftsmodell dienen. Nicht jedes Modul, das in einem anderen Shop zu sehen ist, gehört jedoch in allen Projekten zum Standardlieferumfang. Wir wählen die Funktionen anhand der Teamrollen und realer Bestellszenarien aus. Die Bedienbarkeit der Verwaltungsoberfläche wird nicht nur daran gemessen, wie wenige Schaltflächen sie zeigt, sondern auch daran, ob sie Fehlbedienungen verringert und die benötigten Informationen im richtigen Schritt sichtbar macht.

Auffindbarkeit und Kaufperformance auf Katalogseiten

Filter bieten Kunden hilfreiche Auswahlmöglichkeiten, können aber viele ähnliche URLs erzeugen. Weder die Freigabe jeder Filterkombination für Suchmaschinen noch die pauschale Zuordnung aller Kombinationen zu einer einzigen Kategorie per Canonical-Tag ist automatisch die richtige Entscheidung. Ausgewählte Seiten mit Nachfrage und eigenständigem Inhalt werden von vorübergehenden Sortierparametern unterschieden. Das Verhalten von Varianten-URLs, Paginierung und nicht vorrätigen Produkten wird nach der tatsächlichen Katalogstruktur gestaltet. Dauerhaft entfernte Produkte und vorübergehend ausverkaufte Produkte werden nicht derselben Weiterleitungsregel unterworfen.

• Produkttitel, Beschreibung und Alternativtext der Bilder müssen bearbeitbar sein; leere oder doppelte Felder müssen beim Massenimport sichtbar werden.
• Preis und Verfügbarkeit in den strukturierten Produktdaten müssen mit den Angaben übereinstimmen, die Kunden auf der Seite sehen.
• Produktbilder für mobile Geräte müssen in passenden Größen bereitgestellt werden; Preis oder Kaufschaltfläche dürfen sich beim Laden der Seite nicht unerwartet verschieben.
• Der Cache darf einem Kunden nicht den individuellen Preis eines anderen Kunden anzeigen; dynamische Warenkörbe und zugriffsbeschränkte Händlerbereiche müssen vom allgemeinen Katalog getrennt werden.

Maßnahmen für die organische Suche und Shopping-Anzeigen können dieselbe Produktdatenquelle nutzen, haben jedoch unterschiedliche Erfolgskriterien. Beim Kaufereignis müssen Transaktionskennung und Währung korrekt übertragen werden; das erneute Laden der Zahlungsseite darf nicht als weiterer Verkauf gezählt werden. Geschwindigkeit und Barrierefreiheit werden anhand realer Seitentypen bewertet. Technische Verbesserungen garantieren weder eine bestimmte Platzierung noch eine bestimmte Verkaufsmenge. Wir erläutern, welches Hindernis beseitigt wird und welches Verhalten anschließend beobachtet werden soll.