Guide: B2B-Webshop-Projekte erfolgreich mit Magento 2 umsetzen

Ich arbeite seit 2009 mit B2B-Kund:innen in diversen Branchen. In diesem Ratgeber gehe ich auf diverse Aspekte ein, die nach meiner Erfahrung wichtig sind, um ein B2B-Shop-Projekt erfolgreich umzusetzen. Auch wenn ich primär mit Magento 2 arbeite, sind die Inhalte größtenteils für andere Shop-Systeme genauso gültig.

Falls Sie dieser Text überzeugt und Sie Ihr Projekt mit unserer Agentur umsetzen möchten – egal, ob mit Magento 2 oder einer anderen Software – freue ich mich über Ihre unverbindliche Anfrage über das Formular „B2B-Projekt anfragen“ am Ende der Seite!

Geschätzte Lesezeit: 37 Minuten

Einleitung

Mein Ziel für diesen Guide ist, Ihnen so gut wie möglich meine Erfahrungen aus B2B-Webshop-Projekten weiterzugeben. Egal, ob Sie zum ersten Mal mit einem solchen Projekt konfrontiert sind, einen B2B-Shop mit Magento Open Source bzw. Adobe Commerce in Betracht ziehen oder allgemein Anregungen und Informationen zu einem bestimmten B2B-Thema suchen. Egal, ob Sie auf Kund:innen- oder Anbieter-Seite stehen. Ich habe festgestellt, dass man dazu wenig im Web findet, und möchte diese Lücke schließen.

Ein kleiner Disclaimer: was hier steht, spiegelt meine persönlichen Erfahrungen und Meinungen wider. Natürlich gibt es nicht nur einen richtigen Weg, einen solches Projekt umzusetzen, und jedeR setzt andere Schwerpunkte.

Aus welchen Abschnitten besteht nun dieser Erfahrungssammlung?

• In „Was macht B2B-Projekte besonders?“ arbeite ich heraus, worin sich B2B-Projekte von B2C-Projekten unterscheiden. Mit B2C-Shops, also EndkundInnen-Webshops, hat man schnell einmal Erfahrung, doch es gibt einige Differenzen zu B2B-Projekten.
• In „Vorgehensweise“ erkläre ich grob, wie ich als Kundin bzw. Kunde an ein solches Projekt herangehen würde.
• Mit „Magento 2 oder Individualentwicklung?“ gehe ich darauf ein, wann Magento 2 die geeignete Software für ein B2B-Shop-Projekt ist, und wann man Alternativen in Betracht ziehen sollte.
• „Systemlandschaft und angeschlossene Systeme“ geht darauf ein, dass B2B-Shops oft besonders tief in die eigenen Unternehmensprozesse integriert werden. Dieser Blick hinter die Kulissen soll helfen, die technischen Aspekte dieser Projekte etwas besser zu verstehen.
• „Typische B2B-Features“ schließlich setzt sich genauer mit Anforderungen auseinander, die in B2B-Projekten bevorzugt auftreten. Welche Fragen sind zu klären, was ist zu beachten?

Was macht B2B-Projekte besonders?

B2B-Webshops müssen zunehmend einen schwierigen Spagat hinbekommen.

Einerseits kennen wir alle Online-Shops aus unserer Endkund:innen-Perspektive („B2C“, also „business to customer“). Man erwartet, dass der Shop schnell funktioniert, schön anzusehen und zugleich einfach zu bedienen ist, alle Artikel günstig und sofort verfügbar sind undauch das drumherum mit Bezahlung, Lieferung und Retouren problemlos abläuft.

Andererseits haben wir B2B-Welt (B2B = „business to business“, also eine Geschäftsbeziehung zwischen Unternehmen). Oft hat man es mit komplexen Prozessen, Produkten, Kunden-Strukturen und gewachsenen Systemen zu tun. Es gilt, die Erwartungen aus dem B2C-Markt und die B2B-Erfordernisse unter einen Hut zu bringen, wenn man einen „State of the art“ Web-Auftritt verwirklichen möchte.

Konkret zeichnen sich B2B-Projekte durch diese besonderen Anforderungen aus:

• der Shop wird als Werkzeug gesehen, muss daher besonders funktional sein und schnell zum Ziel führen
• die Kundenbindung ist niedriger als im B2C-Bereich
• historisch gewachsene Systemlandschaften müssen eng integriert werden
• große Datenmengen (zB Sortimente), komplexe Preisfindungen und branchen-spezifische Feature-Anforderungen sind an der Tagesordnung
• B2B ist oft beratungsintensiv
• Hierarchien auf beiden Seiten bedingen gerne Genehmigungsprozesse, abgestufte Rechte und Freigaben
• Wichtige KundInnen können durch Sonderwünsche die Komplexität erhöhen

Shop als Werkzeug

B2B-Shops werden, weil im beruflichen Kontext genutzt, vorwiegend als Werkzeuge oder Anwendungen gesehen.

Auch wenn die Erfahrung des klassischen B2C-Einkaufserlebnisses an Relevanz gewinnt: der Fokus muss darauf liegen, dass der Shop als Bestell-Tool die Arbeit bestmöglich unterstützt, indem schnell und ohne Hindernisse bestellt werden kann – und das in unterschiedlichen Kontexten, womöglich vom Büro-Schreibtisch mit großem Bildschirm und Breitband-Anschluss bis zum Lager oder Kühlhaus mit mobilem Gerät und schlechter Netzverbindung (Stichwort „rugged computers“).

Ein gutes User Experience Design schafft es, diese Bedürfnisse zu vereinen. Sie kennen Ihre KundInnen und Ihre Domäne am besten. In Zusammenarbeit mit B2B-Shop-Experten müssen Sie erarbeiten, welche User den Shop konkret wie verwenden, was ihre Anforderungen und typischen „Customer Journeys“ sind und wie sich das in einem zeitgemäßen und ansprechenden User Interface umsetzen lässt.

Geschwindigkeit, Zuverlässigkeit und Kundenbindung

Im B2B-Bereich kommt es nicht alleine auf den allerbesten Stückpreis an (solange der Preis gut genug ist!), sondern besonders auch auf Geschwindigkeit und Verlässlichkeit in der Abwicklung.

Als B2C-Kund:in hätte man zwar ebenfalls gerne alles und sofort, aber in der Praxis ist in den meisten Branchen verschmerzbar, wenn der Shop einmal Zicken macht oder die Bestellung einen Tag später losgeschickt wird. Im B2B-Bereich ist die Kundenbindung oft geringer. Man benötigt seine Ware, und zwar schnell. Wenn der Shop für ein paar Tage nicht performt, kann das durchaus zu realen und signifikanten Umsatz-Einbußen einführen.

Wichtig ist daher ein Dienstleister, der hochqualitativ arbeitet, Änderungen am Shop gewissenhaft testet und bei Problemen diese Änderungen zurücknehmen kann („Rollbacks“). Eine Monitoring & Alerting Lösung zum Automatisieren und frühzeitigen Aufdecken von herannahenden Problem ist deswegen unerlässlich.

Enge Verzahnung mit historisch gewachsenen Systemlandschaften

B2B-Shops hängen meist an einer Vielzahl von weiteren Systemen in der Systemlandschaft. Diese Systeme sind zudem oft historisch gewachsen, wurden – teils mit Workarounds, teils mit händischen Anpassungen – für die eigenen Anforderungen zurecht gebogen und entsprechen manchmal nicht mehr dem modernen Stand der Technik. Ein Austausch gegen eine neue Software ist nicht in Sicht.

Aufgrund von Datenmengen, technischen, finanziellen oder zeitlichen Begrenzungen muss hier oft eine ungewollt enge Beziehung zwischen dem B2B-Shop und anderen Systemen aufgebaut werden. Ideal wäre eine entkoppelte Lösung, die nicht bedingt, dass Änderung X in Prozess Y automatisch eine Umstellung in mehreren Systemen zugleich bedingt. Abhilfe schafft eine erfahrene B2B-Shop-Agentur, welche diese Herausforderung bereits einmal gelöst hat und in enger Kooperation mit Ihrer IT eine Lösung ausarbeitet, die diesem Ideal zumindest möglich nahe kommt.

Große Datenmengen, komplexe Preisfindung, Branchen-spezifische Feature-Anforderungen

Diese Aussagen gelten für die meisten B2B-Projekte:

• Es gibt große Datenmengen, zum Beispiel im Sinn von großen Sortimenten oder vielen Artikelvarianten, umfangreichen Produktinformationen oder aufgrund historischer Kunden- und Bestell-Daten. Zur Einordnung: es geht oft um sechs- oder siebenstellige Produkt-/Variantenanzahlen oder Produkt-Informations-Daten im Gigabyte-Bereich.
• Der Satz „die Preisfindung ist komplex“ findet sich in fast jedem Lastenheft im B2B-Bereich. Preislisten mit Hierarchien, Anfangs- und End-Zeitpunkten, Prioritäten und Stopp-Kriterien, Fallback-Preislisten, Staffelpreisen, kundenspezifischen Preisen, kategoriespezifischen Preisen und viele mehr kommen häufig zum Einsatz.
• Es gibt Feature-Anforderungen, die im B2B-Bereich üblich sind (aber von jedem Unternehmen unterschiedlich umgesetzt werden) oder die nur in einzelnen Branchen vorhanden sind.

Auf diese Themen gehe ich im Abschnitt „Typische B2B-Features“ näher ein. Was sie gemein haben: sie lassen sich in einer Standard-Software selten so allgemeingültig abbilden, so dass alles direkt von der Stange verwendet werden kann. Damit beschäftige ich mich im Kapitel „Magento 2 oder Individualentwicklung?“. Daher spielt der Dienstleister, welcher die Funktionalität hinzu programmiert, eine große Rolle für B2B-Projekte.

Beratungsintensive Produkte

Je nach Branche ist B2B ein sehr beratungsintensives Geschäft. In diesen Fällen dient der Shop häufig als Tool, um Standard-Bestellungen bzw. jene von Kleinkunden zu automatisieren und somit den Vertrieb für größere Kund:innen und komplexe Anfragen freizuspielen. Dann ist der Shop vor allem für die Anbahnung und als begleitende Informations-Plattform nützlich.

Eine wichtige Aufgabe kommt der gemeinsamen Konzeption zwischen Ihnen und dem Dienstleister zu: was sind die „Edge Cases“ in Ihrem Geschäft? Müssen alle Bestellungen über den Shop abgewickelt werden, oder reicht es nach dem Parento-Prinzip, den Großteil der Aufträge darüber abzuwickeln? Das sind nur zwei von vielen Fragen zu diesem Thema.

Berechtigungsprozesse

Viele Unternehmen haben mehrere Mitarbeiter:innen, die Einkäufe erledigen. Sie arbeiten in verschiedenen Abteilungen und haben unterschiedliche Positionen. Manchmal bedingt das Berechtigungsprozesse, in denen Person A den Einkauf von Person B genehmigen muss, bzw. Unterschiede im Sortiment pro Einkäufer:in.

Ich gehe im Detail weiter unten darauf ein, aber eine Unterscheidung zwischen einzelnen Einkäufer:innen und eventuellen daraus resultierenden Berechtigungsprozessen können einen Rattenschwanz an weiteren nötigen Anforderungen nach sich ziehen.

Besonders ist darauf zu achten, ob Ihre Systeme diese Unterscheidungen überhaupt treffen können, ob die Daten und Geschäftslogik in Ihren Systemen und dem Shop doppelt gespiegelt werden oder ob sie nur von einer Seite abgewickelt werden. Nicht zuletzt kann ein Herunterbrechen auf User- statt auf Firmen-Ebene bei Ihnen bedeutende zusätzliche Administrations-Aufwände bedeuten.

Spezielle Anforderungen einzelner, wichtiger Kunden

Manchmal gibt es wenige, aber wichtige Kund:innen, welche spezielle Anforderungen an den Webshop haben. Um diesen entgegen zu kommen, werden extra Anpassungen im User Interface oder in der Funktionalität vorgenommen.

Meine Empfehlung: verzichten Sie soweit wie möglich auf Anpassungen für einzelne Kund:innen. Überlegen Sie in diesem Fall, ob es sinnvoll ist, die Anpassung für alle Kund:innen auszurollen oder ob es eine Alternative gibt.

Vorgehensweise

Konzept erstellen

Wichtig ist, dass Sie sich so gut wie möglich vorab klar darüber werden, was Sie von Ihrem B2B-Shop erwarten. Schon alleine dieses Thema wäre einen eigenen Guide wert, doch hier finden Sie einige Fragen, deren Antworten Sie vorab ausarbeiten können:

• Was sind Ihre Ziele und Anforderungen?
• Was sind die Ziele und Anforderungen Ihrer KundInnen?
• Welche bereits existierenden Vorbedingungen gibt es (ein bestehender Shop, Corporate Design/Identity, technische/finanzielle/zeitliche Einschränkungen, …)?
• Wenn Sie bereits einen Shop in Betrieb haben: welche Features, Inhalte und Daten müssen sie unbedingt behalten, worauf wollen Sie stärker setzen, was kann bei einem Relaunch weg gelassen werden (je mehr, desto kürzer die Projekt-Durchlaufzeit des neuen Shops)?
• Wer sind ihre Konkurrenten? Was machen diese besser, was machen Sie besser?
• Gibt es Websites, die Ihnen gut gefallen (egal ob in Hinsicht auf Features, Design, …) – und was gefällt Ihnen daran gut?

Formulieren Sie Ihre Anforderungen und Erwartungen möglichst vollständig aus. Das muss kein klassisches Lastenheft sein, denn das Duo Lastenheft/Pflichtenheft ist einer agilen Arbeitsphase nicht unbedingt zuträglich, aber Sie sollten bereits ein recht klares Bild haben, was Sie erreichen möchten. Sichern Sie ab, dass die Stakeholder:innen des Projekts diese mittragen, und sorgen Sie dafür, dass das Projekt-Team alle nötigen AnsprechpartnerInnen nach außen umfasst.

Das ist die Basis, um alles Weitere mit Ihrem B2B-Webshop-Dienstleister zu definieren. Dieser wird Ihnen weitere Fragen stellen und mit Ihnen in eine „Requirements Engineering„-Phase eintreten, sprich: Sie sollten gemeinsam weiter daran feilen, bis für beide Seiten das Projekt greifbar genug ist, um eine Kosten- und Zeitschätzung abgeben zu können.

Exkurs: Kosten, Laufzeit und Projekterfolg

An dieser Stelle möchte ich kurz zwei Themen zu Projektkosten und Projektlaufzeiten ansprechen, weil hier ein gemeinsames Verständnis meiner Meinung nach sehr wichtig für ein erfolgreiches Projekt sein kann und beides bei vielen Projekten, nicht nur im Web-Bereich, über das Ziel hinausschießt: die Verkürzung der „time to market“ und der Umgang mit Kostenschätzungen.

Erstens kann man die „time to market“ verkürzen, indem man aus dem vollständigen Anforderungen ein Minimum an nötigen Features auswählt, mit denen das Projekt bereits live gehen kann und einen Mehrwert darstellt – also ein „Minimum Viable Product“ (MVP). Häufig stellt sich in der Praxis nämlich heraus, dass bestimmte Dinge besonders gut oder schlecht funktionieren, oder sich die Prioritäten im Verlauf des Projekts ändern.
Schafft man es, sich zu einem Vorgehen mit MVP durchzuringen, dann kann man Zeit und Geld durch unnötig verrichtet Arbeiten sparen und dabei den maximalen Wert aus dem Projekt herausholen.

Zweitens sollte man akzeptieren, dass jede Kostenschätzung genau das ist – eine Schätzung. Eine Zahl, die nachher nicht stimmen wird. Es gibt immer Überraschungen, Unwägbarkeiten und Änderungen in den Anforderungen.

Natürlich möchte man realistische und überblickbare Kosten haben. Fixpreis-Projekte mit fixem Umfang werden aber immer einen Verlierer haben. Entweder den Dienstleister, weil er zu knapp kalkuliert hat oder nicht alle Anforderungen und Probleme vorab kannte. Oder Sie, weil der Dienstleister große Puffer einplanen musste, um selbst nicht draufzuzahlen.
So oder so: In dem Modell wird eine Seite benachteiligt, was einer langfristigen guten Zusammenarbeit nicht zuträglich ist.

Der beste Kompromiss ist nach meiner Erfahrung eine Kostenbandbreite in der Schätzung kombiniert mit laufender transparenter Arbeit und Kostenschätzung durch den Dienstleister, um das geschenkte Vertrauen zu rechtfertigen. Laufen die Kosten aus dem Ruder, muss man natürlich reden und eine Lösung suchen. Entstehen die Mehrkosten durch Verfehlungen einer Seite, kann man entsprechend Kosten nachlassen, das Budget anpassen oder den Umfang (vorerst) einschränken, um im Budget zu bleiben.

Für Software und Dienstleister entscheiden

Gehen Sie mit einem oder mehreren Anbietern in die Anbahnungsphase. Mein Tipp: gehen Sie lieber mit zwei oder drei Anbietern in Detailgespräche, als von fünf oder gar zehn Anbietern Angebote einzuholen. Ohne nähere Gespräche können Sie nämlich davon ausgehen, dass die Angebote nicht dasselbe Endergebnis beschreiben und somit die angegebenen Kosten und Leistungen nicht vergleichbar sind.

Zudem werden die meisten Anbieter Rückfragen stellen, um offene Fragen im Konzept zu klären. Die Resultate aus diesen Rückfragen sollten Sie wiederum den anderen Anbietern zur Verfügung stellen, damit die Angebote vergleichbar bleiben.

Seien Sie sich beim Abwägen zwischen den Angeboten bewusst: Ihre Anforderungen werden sich im Laufe des Projekts ändern und nicht vorher gesehene Punkte werden aufkommen, und damit werden sich auch die Kosten ändern. Das hört man nicht gerne, aber es ist so.

Beschäftigen Sie sich sowohl mit der angebotenen Software, als auch mit den Dienstleistern. Holen Sie sich, wo möglich, Referenzen ein und machen Sie sich schlau, ob jemand in Ihrem Netzwerk bereits Erfahrungen mit der Software oder dem Dienstleister hat. Erstens ist nicht jede Software für jedes Projekt geeignet, und zweitens lässt sich manchmal ein Projekt mit unterschiedlichen Softwares ähnlich gut umsetzen, und die Kompetenz des Dienstleisters und die gute Zusammenarbeit spielt die größere Rolle.

Für die Entscheidung gilt wie in vielen anderen Branchen: achten Sie nicht nur auf den Preis. „Wer billig kauft, kauft zweimal“ ist ein abgedroschener Spruch, aber er bewahrheitet sich bei IT-Projekten häufig. Webshop-Projekte im Allgemeinen und B2B-Projekte im Speziellen erfordern Erfahrung und eine gute Chemie zwischen Kunde und Dienstleister. Sie kennen Ihre Domäne, und Ihr Dienstleister muss dafür wissen, wo es im (B2B)-E-Commerce lang geht. Fehlt das Know-How, oder funktioniert die Kommunikation nicht, dann entstehen schnell Mehrkosten, die das ursprünglich günstige Angebot nicht mehr so günstig da stehen lassen.

Die Umsetzung

Mit der Beauftragung beginnt die intensive Kommunikation und Detailarbeit so richtig. Meist wird aus dem Konzept ein Feinkonzept erarbeitet, sprich man geht die einzelnen Themenbereiche noch einmal konkret durch, entwirft das User-Interface etc.

Regelmäßige und engmaschige Abstimmung ist hier das „A und O“. Die Wahrscheinlichkeit, dass das Projekt nach Ihren Wünschen umgesetzt wird, wenn der Dienstleister nach der Beauftragung im stillen Kämmerchen verschwindet und nach neun Monaten „es ist fertig“ ruft, gehen gegen null. Erfolgversprechender sind agile Arbeitsweisen, in denen mit Epics, regelmäßigen Abstimmungen und Abnahmen sowie in Iterationen gearbeitet wird.

Magento 2 oder Individualentwicklung?

Sehen wir uns nun genauer an, welche Anforderungen in B2B-Projekten für mich relevant sind, um die passende Software zu empfehlen.

Wir setzen als B2B-E-Commerce-Agentur vorwiegend Magento ein – aber nicht ausschließlich. Manchmal ist Magento nicht der beste „Fit“ für Ihr Projekt, und es bietet sich eine Individual-Entwicklung an, die genau auf Ihren Anwendungsfall zugeschnitten ist. Technologisch werden diese auf Basis der Programmiersprachen PHP oder JavaScript umgesetzt, jedenfalls aber mit modernen Open-Source-Technologien, um ein gutes Ergebnis zu erhalten und für Sie einen „Lock-In“ auf uns als Anbieter zu vermeiden. Und manchmal macht es auch Sinn, Ihre B2B-Funktionalitäten in ein CMS einzubauen, zum Beispiel TYPO3 oder WordPress.

Sprechen wir also über die Grundanforderungen, die für mich primär entscheidend sind, welche Software passend für ein B2B-Projekt ist. Hier geht es vor allem um die Machbarkeit des Projekts im jeweiligen System. Die vielen weiteren Anforderungen sind für mich in der Regel bei B2B-Webshops nicht mehr systementscheidend, weil sie meistens ohnehin individuell zu implementierbar sind, und das ist in allen genannten Lösungen möglich.

Grundanforderungen

Geschäftsbeziehung: B2B, B2C, …

Die erste Frage ist, an wen Sie verkaufen: handeln Sie ausschließlich im B2B-Bereich, oder haben Sie auch B2C-Kund:innen? Das kann in einem System umgesetzt werden, manchmal aber auch in zwei getrennten Shops. Das hängt davon ab, wie ähnlich die Ansprüche, die Sortimente, die Customer Journey, das Branding, … sind.

Oder möchten Sie einen Marktplatz oder eine Dropshipping-Lösung realisieren? Das wird oft in den gleichen Topf geworfen, kann aber in der Umsetzung durchaus gravierende Auswirkungen haben.

Märkte: Länder, Sprachen, Währungen

In welche Länder verkaufen Sie, welche Sprachen unterstützen Sie, welche Währungen sind verfügbar (oder werden es sein)? Das sollte so weit wie möglich vorausgeplant und entsprechend aufgeteilt werden – vor allem, was die Frage betrifft, ob Sie Ihren Shop anhand von Ländern/Regionen oder anhand von Sprachen strukturieren möchten. Oft spielen Ihre Unternehmensstrukturen und die Strategie eine Rolle.

Das klassische Beispiel für uns im DACH- bzw. mitteleuropäischen Raum: Deutschland und Österreich kommen beide gut mit deutscher Sprache und Euro aus, Italien und Frankreich mit der jeweiligen Sprache und Euro. Für die Schweiz bieten Sie optimalerweise die Sprachen Deutsch, Italienisch und Französisch an, sowie Schweizer Franken als Währung.

Je nachdem, ob Sie in den Ländern die gleichen Sortimente, Preise, Lagerstände, Formulierungen, Geschäftsbeziehungen, … haben oder nicht, empfiehlt sich eine andere Struktur für das Setup. In vielen Fällen ist das später noch änderbar, aber meistens wesentlich aufwändiger – wenn zum Beispiel Kunden, Bestellungen, Warenkörbe oder Sortimente nachträglich verschoben werden müssen.

Mengengerüste: Mandanten, Produkte, Kunden

Relevant für die Machbarkeit eines Projekts ist, welche Datenmengen in der Datenbank zusammen kommen. Das hängt einerseits stark von Ihrem Unternehmen ab, andererseits davon, wie die jeweilige Software die Features umsetzt. Deswegen interessiere ich mich bei der Entscheidung für eine Software für die Mengengerüste Ihres Unternehmens.

Wie viele Mandanten benötigt werden bzw. wie oft Daten in der Datenbank doppelt vorgehalten werden müssen, ergibt sich technisch bedingt aus den oben erwähnten Faktoren (Länder, Sprachen, Währunge, …) bzw. noch weiteren Faktoren. Eventuell muss man in einer Standard-Software wie Magento kreativ werden, wie Länder, Sprachen und Währungen abgebildet werden, um möglichst wenig Daten-Duplizierungen zu erzeugen.

Ähnliches gilt Produkte: haben Sie Millionen Produkte im Angebot, und diese werden mit Sprachen, Währungen, … multipliziert, kann das für den Webserver eine Herausforderung werden.

Zu unterscheiden gibt es hier für die Systementscheidung unter anderem:

• Wie viele Produkte habe Sie mit/ohne Varianten?
• Welche Produkte davon landen im Webshop?
• Welche Produkte oder Varianten verfügen über einen eigenen Lagerstand und eine eigene SKU-Nummer?
• Gibt es Produkte, die „dynamisch“ angelegt werden können, die sie zum Beispiel eigentlich gar nicht als eigene Lager-Einheit im Sortiment haben, die aber trotzdem konfiguriert werden kann?
• Gibt es bei Ihnen Streckengeschäft (Drop-Shopping bzw. Streckenhandel, Direkthandel)?

Nicht zuletzt spielen Ihre Kunden eine wichtige Rolle. Ist für Sie ein Kunde im Webshop eine Firma, oder einzelne Einkäufer/User, oder beides? Wieviele gibt es? Wie stark unterscheiden sich Sortimente, Preise, unterschiedliche Rechte pro Firma/Einkäufer?

Big Picture: User Interface und (branchenspezifische) Features

Schließlich ist ein Überblick über Ihre Ansprüche an das User Interface sowie die wichtigsten Features wichtig, die zudem häufig branchenspezifisch sind. Ziel ist grob herauszuarbeiten, wie weit das geplante B2B-System einem klassischen Webshop entspricht und wie weit die eigenen Anforderungen einzigartig sind.

Magento 2 ist für Standardfälle gut gerüstet und extrem anpassbar. Trotzdem müssen die Komplexitäten und Individualitäten des eigenen Projekts andiskutiert werden. Vor allem branchenspezifische Features, welche eine stark eigene Logik verlangen, können Grund für eine Individualentwicklung sein, falls ein großer Teil des Standardumfangs nicht benötigt wird.

Entscheidung für ein System

Auch wenn es noch viele Details zu klären gibt: nach der Besprechung der oben erwähnten Punkte habe ich ein gutes Bild, ob Magento 2 prinzipiell für dieses B2B-Projekt gut geeignet ist oder ob es aus technischer Hinsicht eine große Herausforderung wäre und besser zum Beispiel als Individualentwicklung umgesetzt werden sollte. Ich gehe im weiteren Verlauf des Guides noch auf viele Punkte ein (Systemlandschaft, typische B2B-Features, …) – diese können die Details der Umsetzung beeinflussen, sie sind aber meist nicht mehr entscheidend für die Auswahl der Software.

Wenn Magento 2 ein guter „Fit“ ist,und das ist häufig der Fall wenn nichts gegen die technische Machbarkeit spricht, dann ist zu evaluieren, welche Edition die passendste ist: Magento Open Source oder Adobe Commerce.

Adobe Commerce macht dann Sinn, wenn das mitgelieferte B2B-Modul gut den Anforderungen entspricht (es ist in der Commerce-Lizenz inkludiert) oder wenn Features wie Kundensegmente benötigt werden.

Weichen hingegen Ihre Ansprüche stark von dem ab, was Magento im Commerce-Standard bietet (wenn zum Beispiel ihre B2B-Features anderes gelöst werden müssen), dann kann auf das lizenzkostenfreie Magento Open Source zurück gegriffen werden und die Ersparnis in die Entwicklung Ihrer maßgeschneiderten Lösung investiert werden.

Systemlandschaft und angeschlossene Systeme

B2B-Projekte haben gegenüber einem reinen B2C-Projekt häufig mehr angebundene Systeme, APIs und Schnittstellen, beziehungsweise werden diese enger angebunden. Für die Projektbeteiligten ist es wichtig, die technischen Abläufe und Gegebenheiten hinter den Kulissen so transparent wie möglich darzustellen. Auch Nicht-TechnikerInnen benötigen ein grobes Verständnis für die Systemlandschaft und das Zusammenspiel der Systeme, um bei Problemen schnell die richtigen Ansatz-Stellen für eine Lösung zu finden. Zugleich muss der Technik-Bereich robuste Schnittstellen bauen, damit kritische Unternehmensprozesse effizient abgewickelt werden und diese Probleme erst möglich gar nicht auftreten.

Worauf ist nun bei der Systemlandschaft und angeschlossenen Systemen zu achten?

Hosting

Das „Hosting„, also die Bereitstellung der technischen Infrastruktur und der Betrieb der Software, wird in größeren Unternehmen häufig gerne von der hauseigenen IT übernommen – zum Beispiel, weil bereits andere Software wie das ERP selbst gehostet oder eigene Datenzentren betrieben werden.

Ich rate allerdings davon ab, falls nicht schon umfangreiche Erfahrungen mit dem Hosting von Webapplikationen gesammelt worden sind. Der Betrieb eines unternehmensinternen Knowledge-Management o.ä. ist nicht mit dem Betrieb eines nach außen hin erreichbaren Online-Shops zu vergleichen! Besonders bei funktionsreichen Systemen wie Magento 2 ist Erfahrung wichtig, um den Shop performant und sicher zu betreiben. Ich empfehle, den Webshop entweder bei einem auf die Software spezialisierten Hosting-Provider laufen zu lassen oder gegebenfalls einen Hosting-Partner ins Boot zu holen, der beim Einrichten und Betrieb in der eigenen Infrastruktur unterstützt.

Anbindungen an unternehmensinterne Systeme

Schnittstellen zu anderen Software-Komponenten sind das „A und O“ für gut laufende Webshops. Sie reduzieren Arbeit, beschleunigen Abläufe und machen KundInnen und Angestellte damit zufriedener.

Für jede dieser Komponente können je nach Unternehmen ein oder mehrere Systeme angeschlossen sein:

• ERP (Warenwirtschaftssystem)
• Lagerstandsverwaltung
• CRM (Customer Relationship Management)
• PIM (Product Information Management)
• DAM (Digital Management Management)
• Industrielle Fertigung, Hardware-Steuerung, Point of Sale (POS), …

Zu klären ist jeweils unter anderem:

• Welches ist das führende System (= wer hat die Datenhoheit)?
• Wo werden Daten hauptsächlich gewartet, gegebenenfalls angereichert?
• Wo werden Daten validiert?
• Wer wird wie informiert, falls es Datenprobleme gibt? Was sind akzeptable Datenfehler, was nicht?
• In welchem Dateiformat bzw. Standard werden Daten übertragen? (XML, JSON, CSV, Text mit fester Bandbreite; EDI, Edifact, branchenspezifischer Standard…)
• Über welches Protokoll und mit welcher Technologie werden Daten übertragen? (SFTP, FTP, HTTP, …; Dateien, REST, SOAP, GraphQL, Enterprise Service Bus (ESB), …)
• Wer stößt die Kommunikation an, erfolgt diese per Pull/Push?
• Passiert das zeitgesteuert, eventbasiert, und/oder durch manuelle Auslösung?
• Erfolgt die Verarbeitung synchron (in Echtzeit, sofort; aktives System erwartet sofortige Rückmeldung) oder asynchron (zB Queue-System)?
• Werden Voll-Updates und/oder Delta-Updates übermittelt?
• Was passiert, wenn die Kommunikation fehlschlägt? Gibt es Standardwerte, die bei Echtzeit-Schnittstellen verwendet werden können?

Die Klärung dieser Fragen ist wichtig, um den Aufwand für die Implementierung schätzen zu können. Bitte unterschätzen Sie nicht den Abklärungsaufwand, auch im Laufe der Umsetzung. Die Dokumentation ist oft nicht vollständig oder aktuell, oder es tauchen im Rahmen der Feinabstimmung bisher nicht bekannte Probleme, Sonderfälle u.ä. auf.

Anbindungen an Dritt-Systeme

Auch externe Anbindungen gibt es bei Shop-Systemen wie Sand am Meer. Hier nur eine kleine Auswahl an möglichen Themen:

• UID-Prüfung
• Newsletter-Anbieter
• Marketing- / Remarketing-Tools
• Tracking-Tools
• Bonitätsabfragen
• Zahlungsanbieter (Payment Service Provider, PSPs)
• Versand- und Logistik-Anbieter
• Steuerberechnungs-Anbieter (v.a. beim Verkauf in die USA)

Zusätzlich zu den eben besprochenen internen Anbindungen ist zu bedenken:

• Je nach Anbieter kommt es mehr oder weniger häufig zu Ausfällen oder Verbindungsproblemen.
• Bei der Bearbeitung von Problemen sitzt man häufig nicht so nahe an der Quelle und kann nur mit einem Helpdesk Support aufnehmen.

Typische B2B-Features

Bisher haben wir recht viel über allgemeine Themen gesprochen. Was sind nun aber konkrete Funktionalitäten, die vor allem im B2B-Bereich gefragt sind, und was ist hier zu beachten?

Firmen-/User-Struktur

Beginnen wir mit einer zentralen Frage, welche sich auf viele der weiteren Punkte auswirkt: unterscheiden Sie bei Ihren KundInnen zwischen Unternehmen und MitarbeiterInnen der Unternehmen?

Klassische Webshop-Software, die vor allem auf EndkundInnen spezialisiert ist, kennt nur „den Kunden“. Der Kunde hat einen Account, der hat eine Mail-Adresse, ein Passwort und so weiter. Der Webshop kennt keine Zusammenhänge zwischen Kunden-Accounts.

Kaufen mehrere MitarbeiterInnen eines Unternehmens bei Ihnen ein, gibt es zwei Möglichkeiten:

1. Alle MitarbeiterInnen legen einzelne, persönliche Accounts an, die miteinander nichts zu tun haben.
2. Die MitarbeiterInnen verwenden einen gemeinsamen Firmen-Account.

Welche Lösung für Sie die beste ist, hängt von mehreren Fragen ab, unter anderem:

• Ist überhaupt zu unterscheiden, wer einkauft (zum Beispiel wegen unterschiedlichen Sortimenten, Preisen, …)?
• Kann Ihr ERP die Unterscheidung einzelner EinkäuferInnen abbilden, oder ist in Ihren anderen Systemen nur das Unternehmen als Kunde hinterlegt?
  • Falls zweiteres: muss der Webshop trotzdem einzelne EinkäuferInnen-Accounts abbilden? Hierfür gibt es einige Gründe, warum das trotzdem nötig sein kann.
• Können EinkäuferInnen für mehrere Unternehmen einkaufen, und wenn ja, können das getrennte Accounts sein?

Im Idealfall kommen Sie mit einer einfachen Lösung aus, welche nicht zwischen Firmen und MitarbeiterInnen unterscheiden können muss.

Falls Sie dieses Feature benötigen, hilft das B2B-Modul von Magento Commerce. Hier können Unternehmen angelegt werden und einzelne MitarbeiterInnen mit jeweils eigenen Accounts zugeordnet werden.

Registrierungsprozess

Während in EndkundInnen-Shops Accounts sehr einfach und direkt über ein Registrierungsformular (meist mit einer Bestätigungsmail) angelegt werden können, sieht der B2B-Prozess meist etwas anders aus.

Drei Modelle, auf die man häufig stößt:

1. Nach dem Abschicken des Registrierungsformulars wird ein Mail mit einer Anfrage an den Webshop-Betreiber gesendet, aber kein Account angelegt. Die Kundin / der Kunde wird zuerst im ERP angelegt und dann von dort an den Webshop übertragen.
2. Neue Accounts werden im Webshop direkt angelegt, jedoch noch ohne B2B-Konditionen. Diese werden nach einer UID-Prüfung oder weiteren Abklärungen freigeschaltet und der Kunde wird im ERP angelegt.
3. Neue Accounts werden im Webshop direkt angelegt. Der Kunde wird jedoch im ERP erst bei der ersten Bestellung angelegt, um Datenmüll zu vermeiden.

An dieser Stelle besteht häufig Änderungs- oder Erweiterungsbedarf für die Webshop-Software, um die Erfordernisse des Projekts abzubilden.

Preisfindung

Die Preisfindung in B2B-Projekten ist in der Regel weit komplexer als in B2C-Projekten. Zusätzlich zu Aktionen, Staffelpreisen, Rabatten, Gutscheinen u.ä. gibt es fast immer:

• Kundenspezifische Preise. Meist als firmenspezifische Preise, manchmal sogar auf Einkäufer-Ebene, und manchmal ohne regelbasierte Logik.
• Multiple, hierarchische Preislisten beliebiger Tiefe mit Priorisierungen, Zeiträumen, „Stopp-Kriterien“ pro Kunde.
• Vereinbarungen, die auf Bedürfnisse einzelner KundInnen eingehen, und von Standardregeln nicht abgebildet sind („gratis Speditions-Versand bis zum zweiten Donnerstag eines Monats, wenn zuvor in diesem Monat noch keine Bestellung“). Diese stammen häufig noch aus Vor-E-Commerce-Zeiten, als ohnehin jeder Auftrag manuell zusammengestellt werden musste.

Fragen, die unter anderem zu klären sind, und Herausforderungen, die sich daraus ergeben:

• Müssen dem Kunden die für ihn gültigen Preise auf allen Seiten angezeigt werden, oder nur auf Anfrage (per Button) bzw. im Warenkorb/Checkout?
  • Gilt das auch für Produktlisten?
  • Ist der „finale“ Preis ein Sortier- und/oder Filter-Kriterium?
  • Reicht es, dass die Preislisten einmalig beim Login / Start einer Session eingelesen werden?
• Ist es wirtschaftlich sinnvoll, die Preisfindungs-Logik des ERP im Webshop abzubilden?
• Kann der Webshop die Preise in Echtzeit beim ERP abfragen?
  • Kann das ERP die Last der Anfragen bewältigen?
  • Kann das ERP die Preisfindung schnell genug abschließen, um eine gute Website-Performance zu gewährleisten?
  • Gibt es Fallback-Preise, wenn die ERP-Anbindung nicht funktioniert?
• Gibt es Standard-Preislisten für Gäste?

Preisfindung ist natürlich ein Knackpunkt für Webshop-Projekte. Entsprechend frühzeitig muss sichergestellt werden, dass die Preisfindungslogik sauber, verlässlich und performant eingebunden werden kann.

Sortimente

Die Beschränkung des Sortiments für Kundengruppen, Kunden oder Einkäufer kann SEO-Auswirkungen haben sowie Auswirkungen auf den Implementierungsaufwand, wenn zum Beispiel externe Suchanbieter verwendet werden.

• Gibt es kundenspezifische Sortimente?
  • Sind diese auf Firmen-Ebene und/oder Einkäufer-Ebene unterschiedlich?
  • Können KundInnen Produkte sehen, die sich nicht kaufen können? Sind sowohl wirtschaftliche als auch Suchmaschinen-Thematiken bei dieser Entscheidung berücksichtigt worden?
  • Was passiert bei Konflikten, wenn Sortimente regelbasiert gesteuert werden?

Lagerstände

Magento 2 bietet in der Open Source Edition und in der Commerce Edition das Feature „Multi Stock Inventory“ (MSI). Hinter dem Begriff versteckt sich eine ausgefeilte Multilager-Funktionalität, in der ein oder mehrere Lager definiert werden können, die zu einem oder mehreren Lagerständen aggregiert werden.

Magento bietet Algorithmen, um die passendsten Lager für einen Versand auszuwählen, zum Beispiel anhand von Google Maps. Eigene Algorithmen können implementiert werden. Falls Sie diese Logik in Ihrem ERP abbilden bzw. der Versand manuell bestimmt wird, können Sie das über die Magento-Schnittstelle abbilden.

• Gibt es einen oder multiple Lagerstände?
• Sind diese Lagerstände an Länder, Regionen, Kunden, … gebunden?
• Wer bestimmt, welches Lager für eine Bestellung zieht? Das ERP, der Webshop? Nach welcher Logik wird dies entschieden?
• Gibt es weitere Lagerstände neben den „Webshop-Lagerständen“, zum Beispiel Hersteller-Lagerstände?
• Spielt der Lagerstand überhaupt eine Rolle für die Webshop-KundInnen oder kann man von „Always in stock“ ausgehen?

Streckenartikel

Streckenartikel werden im Streckengeschäft verwendet (auch bekannt als Drop-Shipping oder Direkthandel). Diese Produkte haben HändlerInnen in der Regel selbst nicht Lager, oft auch gar nicht im eigenen Sortiment, sie werden aber bei Bedarf für den Kunden beschafft. Die Abwicklung erfolgt normalerweise direkt vom Handelspartner zum Kunden.

• Wie bilden Sie im ERP Streckenartikel ab?
• Welche Produktinformationen gibt es für Streckenartikel?
• Sind diese im Webshop immer zu sehen, oder werden sie bei Bedarf angelegt?
• Werden die Streckenartikel im weiteren Verlauf (Lagerstand, Zahlung, Versand, …) anders als normale Artikel behandelt?

Streckenartikel sind kein Standard-Feature von Magento und müssen maßgeschneidert implementiert werden.

Ersatzartikel

Ersatzartikel sind im B2C-Bereich vor allem im Lebensmittelhandel zu finden. Sie spieln im B2B-Lebensmittelhandel eine Rolle sowie in anderen Branchen, wenn es gleichwertige Ersatzteile gibt, die zum Beispiel bei Lieferengpässen stattdessen angeboten werden.

Es empfiehlt sich, KundInnen eine Standard-Einstellung zu erlauben, ob Ersatzartikel akzeptiert werden. Außerdem sollte diese Einstellung auf Bestell-Ebene, eventuell sogar auf Warenkorb-Posten-Ebene überschreibbar sein.

Zu berücksichtigen sind Kostenunterschiede, die sich durch Ersatzartikel gegenüber der ursprünglichen Bestellung eregeben können.

Einkaufslisten

Einkaufslisten erlauben es, wiederkehrende Bestellaufgaben zu beschleunigen. So können sich KundInnen Listen nach Anlass, Jahreszeit, Dienstleistung, … zusammenstellen und den Warenkorb einfacher befüllen. Es sollte möglich sein, mehrere Listen parallel zu warten und neben den Produkten auch ihre Stückzahl abzuspeichern. Werden eine oder mehrere Artikel der Einkaufsliste in den Warenkorb gelegt, dann sollten sie nicht aus der Einkaufsliste verschwinden (anders als bei einem „Wunschzettel“ oder „Merkzettel“).

Magento Commerce bietet dieses Feature mit dem Namen „Requisition List“.

Bestelltabellen für Varianten

Viele Produkte gibt es in mehreren Ausführungen, zum Beispiel in Größe und Farbe. Bei diesen Stammartikeln und ihren Varianten spricht Magento von „Konfigurierbaren Produkten“ und „Simplen Produkten“.

Während PrivatkundInnen selten viele Varianten eines Produkts auf einmal kaufen, ist das bei GeschäftskundInnen anders. Es empfiehlt sich daher, ein komfortables User Interface für die schnellere Bestellung zu implentieren, zum Beispiel in Form von Bestelltabellen auf der Produktseite.

Die tabellarische Darstellung eignet sich für eine („Größe“) oder zwei Dimensionen („Größe“, „Farbe“). Ab einer dritten Option / Dimension kommt die Implementierung eines „Konfigurators“ in Frage, der die UserInnen durch die Auswahl führt.

Dieses Features ist nicht im Magento-Standard-Umfang enthalten.

Angebote & Preisverhandlungen

Preise im B2B-Geschäft nicht immer in Stein gemeißelt. Deswegen benötigen manche Unternehmen die Funktionalität, dass KundInnen ein Angebot für ihren Warenkorb anfordern können.

Magento Commerce enthält dieses Feature als „Request a Quote„. KundInnen fordern ein Angebot für ihren Warenkorb an und können optional einen Text oder Dateien hinzufügen. HändlerInnen oder ihre AdministratorInnen können das Angebot bearbeiten, indem sie Produkte hinzufügen oder entfernen, Stückzahlen ändern, einen Rabatt gewähren oder die Versandart einstellen. Beide Seiten können in beliebig vielen Runden Nachrichten schreiben und so verhandeln. Letztendlich wird das Angebot akzeptiert oder abgelehnt.

Rechte und Genehmigungsprozesse

Können mehrere Menschen für ein Unternehmen einkaufen, dann sind unter Umständen unterschiedliche Rechte, Limits oder Genehmigungsprozesse notwendig.

Das implementiert Magento Commerce im B2B-Modul mit den Rollen und Rechten für Firmenstrukturen. Sie können Hierarchien von Abteilungen und MitarbeiterInnen abbilden und unter anderem steuern, wer bestellen und Bestellungen freigeben darf.

Ein Feature, das im B2B-Bereich eigentlich immer benötigt wird: dass nur eine Rechnungsadresse hinterlegt werden kann, und vor allem, dass die Rechnungsadressen nicht durch den User änderbar sind.

Zahlungsarten

Neben den klassischen Zahlarten werden, wenn der Shop intern verwendet wird, manchmal Kostenstellen als Auswahlmöglichkeit im Checkout benötigt.

Unabhängig davon soll manchmal eine Bestell-Obergrenze pro Unternehmen oder sogar pro User möglich sein.

Schnellbestellungen

Gelegentlich werden Bestell-Listen außerhalb des Webshops zusammengestellt bzw. in anderen Tools generiert. Deswegen sind Schnellbestellungen ein beliebtes Feature, bei denen man sich nicht manuell durch den Shop klicken muss.

Häufig verwenden Unternehmen Tools, die als Ergebnis ein Excel- oder CSV-File generieren (oder die Liste wird direkt in Excel zusammengestellt). Deswegen bietet es sich für die Schnellbestell-Funktionalität an, dass entweder diese Dateien direkt verarbeitet werden oder der Inhalt per Copy & Paste in ein Textfeld kopiert werden kann.

Ein solches Feature bietet Magento Commierce unter dem Namen „Quick Order„. Dort kann eine solche vorbereitete CSV-Datei hochgeladen werden, oder man kann über die Bestellmaske anhand der SKU schneller die benötigten Produkte zusammensuchen als über den herkömmlichen Weg.

PunchOut-Kataloge

Verwenden Unternehmen SAP, dann haben sie manchmal gerne die Möglichkeit, über so genannte PunchOut-Kataloge beziehungsweise das Open Catalog Interface (OCI) Bestellungen direkt aus ihrem SAP vorzunehmen. Der Bestellprozess wird für die EinkäuferInnen vereinfacht, da Adress-Daten, Zahlungsinformationen u.ä. nicht extra angegeben werden und das eigene System nicht verlassen werden muss.

Magento bietet standardmäßig keine PunchOut-Funktionalität, aber sie kann in einem B2B-Shop natürlich implementiert werden.

Rechnungslegung

Für Online-Bestellungen und deren Rechnungen werden gerne eigene Nummernkreise vergeben, damit es nicht zu Überschneidungen mit Offline-Bestellungen kommt. Das ist natürlich in Magento 2 möglich.

Und dann stellt sich noch die Frage: wer generiert die Rechnungen (zum Beispiel als PDF) und versendet sie per E-Mail (falls das im Projekt gewünscht ist)? Das hängt tatsächlich vom unternehmenseigenen Workflow ab, ich sehe beides in etwas gleich häufig.

Mein Rat ist im Blick zu behalten, welches System die letzte Wahrheit enthält. Normalerweise ist dies das ERP. Sofern es in der Lage ist, die Rechnungen konsistent zu den anderen E-Mails zu verschicken, kann das sinnvoll sein. Soll der Webshop den Versand übernehmen, dann ist sicherzustellen, dass geänderte Rechnungsdaten (Änderungen am Auftrag, Rabattierungen, Korrekturen, …) vom ERP in den Webshop zurück übertragen werden.

Logistik-Anbindungen / Versand

Analog zur Rechnungslegung wird auch die Vorbereitung für den Versand beziehungsweise die Information der KundInnen darüber manchmal im ERP, manchmal im Webshop abgewickelt.

In diesen Bereich fällt zum Beispiel der Etikettendruck. Durch den automatischen Druck der Labels wird der Versand erleichtert.

Es folgt der Versand einer E-Mail an die KundInnen, wenn Artikel versendet wurden. Die E-Mail sollte einen Tracking-Link bzw. die Sendungsnummer enthalten. Einen Mehrwert bieten Sie, wenn diese Sendungen auch im Kundenkonto für die jeweilige Bestellung sichtbar sind, zum Beispiel mit Tracking-Link, Datum, Versanddienstleister und Gewicht.

Auch weitere Bestellstatus-Updates können als Service im Kunden-Konto oder per E-Mail mitgeteilt werden, zum Beispiel wenn bei Ihnen mehrere Stationen durchlaufen werden welche für die KundInnen relevant sind. Achten Sie beim Mail-Versand darauf, KundInnen nicht unnötig mit Mails zu belasten: versenden Sie zum Beispiel in der Regel am gleichen Tag, dann werden sich die KundInnen von mehreren Mails an demselben Tag zu diversen Status-Updates vermutlich gestört fühlen.

Bestellarchiv und Offline-Bestellungen

Geht ein Webshop online, dann sind dort standardmäßig nur neu aufgegebene Online-Bestellungen vorhanden. Um den KundInnen besseren Service zu bieten und dem Omnichannel-Ansatz zu folgen, empfiehlt es sich Bestellungen aus alten Shops und anderen Absatzkanälen auch im Shop verfügbar zu machen.

• Wie weit zurückliegend sollen alte Bestellungen im Webshop verfügbar sein?
• Sind die Artikel von alten Bestellungen noch im Webshop verfügbar und kann eine Verknüpfung der Bestell-Posten mit den Webshop-Artikel hergestellt werden (ist relevant für das Wiederbestell-Feature)?
• Liegen für alte Bestellungen oder Bestellungen aus anderen Kanälen alle relevanten Informationen für eine sinnvolle Darstellung vor?

Vorbereitung für verschiedene Szenarien

Wir wissen, dass EndkundInnen in verschiedensten Situationen in Webshops bestellen: am Desktop-PC, unterwegs in den öffentlichen Verkehrsmitteln, auf Geräten mit eingeschränkten Nutzungsmöglichkeiten, mit Kind am Arm, einer temporären oder körperlichen Beeinträchtigung, … Für B2B-Webshops kommen noch einmal weitere Szenarien dazu.

Einerseits gibt es weitere Nutzungskontexte. Eingekauft wird je nach Branche nicht nur am Büro-Schreibtisch mit großem Bildschirm und Breitband-Anschluss, sondern auch im Lager oder Kühlhaus mit mobilem Gerät und schlechter Netzverbindung (Stichwort „rugged computers“). Es kann spezielle Scan-Geräte für die Erfassung von Artikeln geben, oder das Interface an besondere Nutzung wie zum Beispiel auf der Baustelle anzupassen sein.

Zudem ist der Webshop oft die beste Anlaufstelle für das Sortiment für unterschiedliche Stakeholder. Nicht nur die KundInnen sind hier zum Einkauf unterwegs, ebenso kann es die Informationsquelle für die oder den CEO sein oder eine Unterstützung für den Vertrieb im Außendienst.

Reporting

Nicht zuletzt können in den Webshop diverse Dashboards und Reportings eingebaut werden. Das reicht von typischen KPIs zur Geschäftsentwicklung über die Analyse von KundInnen und Bestellungen bis hin zu Steuer-Reports.

Berücksichtigen Sie, ob der Webshop das beste System dafür ist. Eventuell haben Sie bereits ein anderes Reporting-Tool wie BIRT im Einsatz oder der Webshop ist Ihre „Single source of truth“ für diese Daten.

B2B-Projekt anfragen

Möchten Sie mit mir bzw. unserer Web-Agentur LIMESODA über Ihr B2B-Projekt sprechen? Dann zögern Sie bitte nicht und melden Sie sich im folgenden Formular. Die Anfrage ist natürlich unverbindlich und wir melden uns möglichst schnell bei Ihnen.