Für die meisten polnischen KMU ist Allegro (der dominierende lokale Marktplatz, in seiner Rolle vergleichbar mit Amazon im DACH-Raum) der zweite oder sogar der erste Vertriebskanal. Der Schmerz beginnt nicht mit dem ersten Angebot, sondern rund um die fünfzigste Bestellung pro Tag — wenn jemand im Unternehmen die Hälfte einer Vollzeitstelle damit verbringt, Bestellungen ins ERP zu übertragen und die Lagerbestände zwischen den Kanälen synchron zu halten.
Wir sehen das in fast jedem Handelsprojekt. Ein Unternehmen startet mit ein paar Angeboten, der Umsatz wächst, sechs Monate später gibt es 40 aktive Angebote und einen Vertriebsmitarbeiter, der einen Tag pro Woche nur klickt: Adresse aus Allegro in Comarch Optima kopieren, Rechnung ausstellen, Versandetikett generieren, zurück zu Allegro, „versandt" markieren. Und wenn Freitagabend jemand auf Allegro die letzte Einheit eines Produkts kauft, das gerade im Ladengeschäft verkauft wurde — gibt es einen Oversell, eine Entschuldigungs-E-Mail und bis zum Morgen eine negative Bewertung.
Das Problem verschwindet nicht von allein. Es skaliert mit dem Umsatz.
Was ohne Integration schiefgeht
Drei Klassiker in dieser Reihenfolge.
Lagerbestände laufen zwischen den Kanälen auseinander. Das ERP weiß, was im Regal steht, Allegro zeigt einen anderen Bestand, weil er einmal täglich um 8:00 Uhr manuell aktualisiert wird. Der Ladenverkauf schrumpft den Bestand tagsüber, Allegro zeigt weiterhin volle Verfügbarkeit. Konkret: Bei einem unserer Kunden — einem 18-köpfigen Elektronikhändler — kamen bei 30–40 Allegro-Bestellungen pro Tag im Schnitt 3 Oversell-Fälle pro Monat vor. Jeder davon bedeutet eine negative Bewertung oder eine einwöchige Sperre von Verkaufsvorteilen.
Manuelles Übertragen frisst Stunden. Eine Allegro-Bestellung muss als Verkaufsbeleg ins ERP eingetragen, Kundendaten ergänzt, eine Rechnung ausgestellt, ein Versandetikett generiert und die Sendungsnummer zurück nach Allegro geschoben werden. Acht bis zwölf Klicks pro Bestellung. Bei 30 Bestellungen pro Tag sind das rund 8 Stunden pro Woche einer Person, rein mechanisch.
Aktionspreise driften. Sie starten eine Promotion im Ladengeschäft, jemand vergisst, Allegro zu aktualisieren. Kunden bemerken den Unterschied, ein Teil reklamiert. Umgekehrt genauso — eine Wochenendaktion auf Allegro läuft am Montag an der Kasse nicht mehr, das alte Etikett hängt aber weiter.
Keins dieser Probleme ist einzeln eine Katastrophe. Zusammen, über sechs Monate, kosten sie mehr als eine ordentliche Integration.
Wann BaseLinker (oder ähnlich) — wann eigene API
Der polnische Markt für solche Middleware ist reif — BaseLinker, Sky-Shop, Selly, IdoSell. Alle tun ungefähr dasselbe: Bestellungen aus Allegro (und anderen Marktplätzen) einlesen, in einem Panel bündeln, die Bestellung ins ERP schieben und den Versandstatus zurückgeben. Für die meisten KMU ist das die richtige erste Investition — nicht eine Custom-Integration.
BaseLinker (oder ein Wettbewerber) reicht, wenn:
- Sie Standardprodukte verkaufen, ohne Konfiguratoren.
- Ihr ERP Comarch Optima, Subiekt GT/Nexo, enova365 oder WF-Mag ist — dafür gibt es fertige Konnektoren.
- Das Volumen bis ca. 500 Bestellungen pro Tag aus Allegro bleibt.
- Keine ungewöhnliche Rabattlogik, keine Vertragspreise, kein komplexes VAT-Marge-Handling.
Eine eigene Integration gegen die Allegro-REST-API lohnt sich, wenn:
- Sie konfigurierbare Produkte verkaufen (Möbel nach Maß, Elektronik mit Optionen) — Middleware kommt mit Varianten schlecht klar.
- Ihr ERP schwach unterstützt wird (Microsoft Dynamics AX, stark modifiziertes Business Central, hauseigene Anwendungen).
- Sie spezifische Logik brauchen: unterschiedliche Quellläger je Angebot, Versandprioritäten, Anbindung an ein Produktionssystem.
- Das Volumen über 500 Bestellungen pro Tag liegt — dann nähern sich die Lizenzkosten der Middleware den Betriebskosten einer eigenen Integration an.
In der Praxis sollten ca. 80% der KMU, in die wir hineingehen, mit BaseLinker starten. Der Rest wächst mit einem konkreten Grund in eine eigene Integration hinein — nicht „weil es cooler klingt".
Wie eine gute Integration aussieht
Ohne in Code zu gehen: Eine gute Allegro-↔-ERP-Integration hat vier Flüsse, die getrennt behandelt werden.
- Produktkatalog: ERP (oder PIM) → Allegro. Neue Produkte, Basispreis-Updates, Beschreibungen, Bilder, Varianten. Üblicherweise nächtlicher Sync plus ereignisbasierte Pushes bei Preisänderungen.
- Lagerbestände: ERP → Allegro. Echtzeit oder nahezu Echtzeit. Jede Lagerbewegung im ERP (Ladenverkauf, Warenausgabe) landet sofort in Allegro. Der kritischste Fluss — Oversells hängen davon ab.
- Bestellungen: Allegro → ERP. Eine neue Allegro-Bestellung erzeugt einen Verkaufsbeleg im ERP (meist Lieferschein oder Rechnung), reserviert die Ware, generiert das Versandetikett. Ohne Klicken.
- Versandstatus: ERP → Allegro. Sobald das Etikett generiert wird, geht die Sendungsnummer automatisch zurück an Allegro und der Kunde bekommt die „versandt"-Mail.
Jeder der vier Flüsse sollte funktionieren, auch wenn einer der anderen ausfällt. Sie wollen keine Integration, die bei einem einzigen Fehler komplett liegt.
Fallen, die wir immer wieder sehen
Race Condition beim Bestand. Das ERP pusht „5 Stück", im gleichen Moment verkauft Allegro das sechste. Lösung: Reservierung des Bestands im ERP schon bei Status „neue Bestellung", nicht erst bei Rechnungsstellung. Wer das nicht hat, liegt am Black Friday.
Aktionspreise zurückrollen. Sie starten eine Promotion mit 199 statt 249. Die Integration schiebt den neuen Preis nach Allegro. Die Promo endet am Montag — wer sorgt dafür, dass der Preis auf 249 zurückspringt? Das muss von Anfang an entworfen sein, sonst „kleben" Aktionspreise wochenlang an Allegro fest.
Sonderzeichen in Beschreibungen. Comarch Optima hält die Produktbeschreibung in einem Textfeld mit harten Zeilenumbrüchen. Allegro will HTML mit einer konkreten Whitelist von Tags. Ohne Transformation bekommen Sie Beschreibungen wie „ <br/>Waschmaschine<br/>". Kleinigkeit — aber der Kunde schreibt zurück „das ist Kauderwelsch".
Mehrere Läger auf einem Allegro-Konto. Das Unternehmen hat ein Allegro-Verkäuferkonto, aber drei Läger (Warschau, Krakau, Dropship-Lieferant). Wer versendet die Bestellung — Warschau oder Krakau? Die Regel muss in der Integration liegen (z. B. nächstgelegenes Lager per PLZ des Käufers), sonst entscheidet der Vertrieb jeden Tag manuell.
Was es tatsächlich kostet
Konkreter Fall. Derselbe 18-köpfige Elektronikhändler. Vor der Integration: eine Person Vollzeit für Allegro — Bestellungen, Versandetiketten, Statusaktualisierungen, Bestandspflege, Bearbeitung von Oversell-Reklamationen. Nach dem BaseLinker-Rollout mit Comarch-Optima-Konnektor: 1 Tag pro Woche für dieselbe Person, plus eine halbe Stunde täglich für Sonderfälle (ungewöhnliche Bestellungen, Reklamationen).
Kosten: BaseLinker im passenden Tarif für das Volumen — ca. 250 PLN/Monat. Einrichtung und Konfiguration (Schema-Mapping, Kategorien-Mapping, Test mit echten Bestellungen) — einmalig etwa 6–10 Tsd. PLN, je nach Ausgangslage. Zeitgewinn — ca. 24 Stunden pro Woche freigespielte Kapazität, plus kein Oversell in den sechs Monaten nach Go-Live.
Amortisation: 2–3 Monate, wenn man ehrlich nur die eingesparte Zeit rechnet. Deutlich schneller, wenn man auch verlorenen Umsatz aus Oversells und die Bearbeitung von Reklamationen einbezieht.
Wie Sie anfangen
Fangen Sie nicht mit der Tool-Auswahl an. Fangen Sie mit zwei Fragen auf Papier an:
- Wie viele Allegro-Bestellungen pro Tag bearbeiten wir, und wer klickt sie manuell? In Stunden pro Woche umrechnen — das sind Ihre „Nichtstun-Kosten".
- Wie viele Oversells oder Bestandsdiskrepanzen hatten wir in den letzten 3 Monaten? Mehr als einer — dann haben Sie ein Problem, nicht nur Kosten.
Wenn beide Antworten „mehr als null" sind, ist der nächste Schritt nicht „Integration bestellen", sondern „zweiwöchigen Pilot mit BaseLinker auf 10 ausgewählten Angeboten fahren". Damit verifizieren Sie, ob Kategorien- und Bestands-Mapping mit Ihrer ERP-Konfiguration funktionieren, ohne das restliche Geschäft zu gefährden. Erst nach dem Pilot — die Entscheidung über den vollen Rollout.
Das ist eins der Projekte, bei denen der Großteil des Risikos nicht in der Technik liegt, sondern im Anpassen des Prozesses ans Tool. Empfohlen mit jemandem, der schon ein paar davon gemacht hat — nicht damit er alles übernimmt, sondern damit Sie die Fehler auslassen, die andere vor Ihnen gemacht haben.
Bestellungen von Marktplätzen manuell zu übertragen ist nicht „unser Prozess". Es ist operative Schuld, die mit dem Umsatz wächst.