Wdrożenie B2C i B2B na jednej platformie Magento 2
Połącz sprzedaż detaliczną i biznesową w jednym sklepie. Projektujemy i wdrażamy platformy Magento 2, w których wspólny rdzeń danych oraz integracji łączy się z osobnymi kontami, cenami, katalogami i procesami zakupowymi.
Najpierw sprawdzamy, które procesy warto połączyć, a które powinny pozostać odrębne. Dopiero na tej podstawie określamy architekturę, zakres funkcji i sposób połączenia Magento 2 z systemami firmy.
- analiza procesów
- architektura platformy
- obie ścieżki zakupowe
- integracje i dane
- QA i uruchomienie
B2C i B2B korzystają z tych samych danych, ale kupują inaczej
Klient indywidualny oczekuje krótkiej ścieżki zakupu, aktualnej oferty i wygodnej płatności. Klient firmowy może potrzebować własnego cennika, wielu użytkowników na jednym koncie, limitów zakupowych albo akceptacji zamówienia.
Wdrożenie porządkuje oba doświadczenia bez kopiowania całego katalogu i każdej integracji. Wspólny rdzeń obsługuje elementy wykorzystywane przez oba kanały.
Różnice są projektowane na poziomie witryny, konta, cen i procesu zakupowego. Dokładny podział powstaje po analizie modelu sprzedaży, systemów i sposobu pracy zespołów.
Wspólny rdzeń
Współdzielone mogą być
- dane produktowe
- stany i dostępność
- obsługa zamówień
- integracje
- panel administracyjny
- dane wykorzystywane w analityce
B2C
Sprzedaż detaliczna
Zakres może obejmować:
- zakup bez rejestracji lub standardowe konto klienta
- publiczne ceny, rabaty i promocje
- płatności internetowe i dostawy detaliczne
- merchandising, treści i wyszukiwanie produktów
- proces zakupowy zoptymalizowany pod krótką decyzję
B2B
Sprzedaż biznesowa
Zakres może obejmować:
- konta firmowe i użytkowników o różnych rolach
- indywidualne cenniki i warunki handlowe
- katalogi dostępne dla wybranych grup
- limity, akceptacje i ponawianie zamówień
- płatności oraz dostawy wynikające z umowy z klientem
- Planujesz wyłącznie sprzedaż D2C?Zobacz wdrożenie D2C na Magento 2
- Potrzebujesz samodzielnej platformy B2B?Zobacz wdrożenie B2B na Magento 2
Dwa osobne systemy zaczynają dublować dane, integracje i pracę zespołu
Rozdzielenie kanałów może ułatwić początek. Problemy pojawiają się wraz z rozwojem, gdy te same produkty, ceny, stany i zamówienia zaczynają być obsługiwane według różnych zasad.
Zespół e‑commerce ręcznie poprawia rozbieżności w katalogach. Sprzedaż uzgadnia warunki handlowe poza platformą. IT utrzymuje kilka połączeń z tym samym ERP lub PIM. Każda większa zmiana wymaga sprawdzenia, jak wpłynie na oba środowiska.
| Obszar | Obecna sytuacja | Konsekwencja |
|---|---|---|
| Dane produktowe | Opisy, zdjęcia i atrybuty są importowane do kilku miejsc. | Aktualizacje pojawiają się w różnym czasie, a część oferty zaczyna się rozjeżdżać. |
| Stany i zamówienia | Kanały wysyłają dane do osobnych kolejek lub integracji. | Zespół ręcznie wyjaśnia różnice w dostępności i statusach. |
| Ceny i warunki | Reguły sprzedaży są utrzymywane w kilku systemach. | Trudniej ustalić, która cena lub zasada ma pierwszeństwo. |
| Rozwój | Podobne funkcje powstają osobno dla B2C i B2B. | Koszt kolejnych zmian obejmuje kilka środowisk oraz kilka zestawów testów. |
01Dane produktowe
Obecna sytuacja
Opisy, zdjęcia i atrybuty są importowane do kilku miejsc.
Konsekwencja
Aktualizacje pojawiają się w różnym czasie, a część oferty zaczyna się rozjeżdżać.
02Stany i zamówienia
Obecna sytuacja
Kanały wysyłają dane do osobnych kolejek lub integracji.
Konsekwencja
Zespół ręcznie wyjaśnia różnice w dostępności i statusach.
03Ceny i warunki
Obecna sytuacja
Reguły sprzedaży są utrzymywane w kilku systemach.
Konsekwencja
Trudniej ustalić, która cena lub zasada ma pierwszeństwo.
04Rozwój
Obecna sytuacja
Podobne funkcje powstają osobno dla B2C i B2B.
Konsekwencja
Koszt kolejnych zmian obejmuje kilka środowisk oraz kilka zestawów testów.
Jedna architektura może rozdzielić kanały bez rozdzielania danych
Witryna B2C i portal B2B mogą mieć inne interfejsy, katalogi, ceny, role i procesy zakupowe. Wspólna warstwa Magento 2 obsługuje dane oraz integracje wykorzystywane przez oba kanały.
Architektura może opierać się na oddzielnych witrynach, widokach i zakresach katalogu. Część firm potrzebuje pełnego rozdzielenia kanałów. W innych przypadkach wystarczy wspólna oferta z innymi cenami i funkcjami dostępnymi po zalogowaniu.
Model architektury zależy od edycji Magento, systemów źródłowych, obecnej infrastruktury i wymaganej niezależności kanałów. Te decyzje podejmujemy przed przygotowaniem finalnej estymacji.
Kanały sprzedaży
- Witryna B2CKlient indywidualny
- Portal B2BKlient biznesowy
Magento 2wspólne dane i operacje
Warstwa integracyjna
Systemy źródłowe
- ERP
- PIM
- WMS
- CRM
Co składa się na poszczególne warstwy
- 01
Warstwa wspólna
- produkty i atrybuty
- informacje o dostępności
- zamówienia i statusy
- połączenia z systemami firmy
- zarządzanie treścią oraz konfiguracją
- monitoring najważniejszych procesów
- 02
Warstwa B2C
- publiczna oferta
- promocje
- płatności detaliczne
- wygodna ścieżka zakupowa
- treści wspierające wybór produktu
- 03
Warstwa B2B
- konta firmowe
- role i uprawnienia
- warunki handlowe
- katalogi i ceny przypisane do klienta
- proces zakupowy zgodny z organizacją odbiorcy
Jeżeli architektura ma dopiero powstać, punktem wyjścia bywa analiza przedwdrożeniowa. Zakres i harmonogram estymujemy po zamknięciu decyzji o warstwach i integracjach.
B2C i B2B w jednym sklepie czy w osobnych witrynach Magento 2?
To pierwsza decyzja architektoniczna projektu i najdroższa do zmiany później. Poniżej trzy scenariusze, których używamy najczęściej, razem z tym, co każdy z nich kosztuje w utrzymaniu.
- 01
Jeden storefront, funkcje B2B po zalogowaniu
Klient firmowy widzi ten sam sklep co detaliczny, ale po zalogowaniu dostaje własny cennik, warunki płatności, limity i szybkie zamawianie. Rozdzielenie kanałów odbywa się na poziomie grup klientów i reguł cenowych, a nie osobnych witryn.
Pasuje, gdy
- oba kanały sprzedają w większości ten sam asortyment
- różnice sprowadzają się do cen, warunków i sposobu zamawiania
- zespół obsługuje oba kanały tymi samymi procesami
Koszt utrzymania
Najniższy z trzech wariantów: jeden frontend, jeden zestaw treści i jedna ścieżka wdrażania zmian.
- 02
Osobne witryny B2C i B2B w jednym Magento 2
Każdy kanał ma własną witrynę — własną domenę, wygląd, katalog i konfigurację sprzedaży — ale obie stoją w tej samej instalacji, na wspólnym kodzie, integracjach i panelu administracyjnym. To poziom website w architekturze Magento.
Pasuje, gdy
- asortyment albo komunikacja obu kanałów realnie się różnią
- B2B potrzebuje własnej domeny lub wydzielonych metod płatności i dostawy
- zespoły detalu i hurtu pracują niezależnie od siebie
Koszt utrzymania
Jedna platforma do aktualizacji, ale dwa frontendy i dwa zestawy treści do prowadzenia.
- 03
Dwie niezależne platformy
Każdy kanał ma własne wdrożenie, własny kod i własne integracje. Wspólne pozostają wyłącznie systemy firmy: ERP, PIM czy WMS, o ile są do obu podłączone.
Pasuje, gdy
- kanały mają odrębne modele biznesowe, zespoły i budżety
- wymagania B2B są na tyle nietypowe, że wykluczają wspólną architekturę
- jedna z platform i tak musi zostać zbudowana od nowa
Koszt utrzymania
Najwyższy: podwojone integracje, aktualizacje, testy i praca zespołu przy każdej zmianie danych produktowych.
W większości projektów wybór stoi między wariantem 01 a 02, a rozstrzyga go to, czy kanały sprzedają ten sam asortyment i czy obsługuje je ten sam zespół. Decyzję zamykamy przed rozpoczęciem prac — razem z podziałem procesów, z którego wynika reszta zakresu.
Zakres zaczyna się od procesów, które różnią oba kanały
Lista funkcji powinna wynikać z rzeczywistych zasad sprzedaży. Kopiowanie rozwiązań z innej platformy często przenosi do nowego systemu procesy, które już wcześniej wymagały ręcznych obejść.
- 01
Konta klientów i firm
Trzeba ustalić, kto może utworzyć konto firmowe, jak przebiega jego weryfikacja oraz ilu użytkowników może działać w ramach jednej organizacji. Role powinny odzwierciedlać sposób składania i zatwierdzania zamówień u klienta.
Jeżeli konta firmowe są jedynym istotnym kanałem, sensowniejsze może być wdrożenie B2B na Magento 2.
- 02
Katalog i dostępność oferty
Oferta B2C może być publiczna, a część produktów B2B dostępna wyłącznie dla wskazanych klientów lub segmentów. Zakres obejmuje także jednostki sprzedaży, minimalne ilości, opakowania zbiorcze i dostępność.
- 03
Ceny oraz warunki handlowe
Cena może wynikać z grupy klienta, umowy, wolumenu, rynku albo danych przesyłanych z ERP. Przed wdrożeniem trzeba wskazać miejsce, w którym reguła jest utrzymywana i zatwierdzana.
- 04
Koszyk i zamówienie
Ścieżka detaliczna zwykle prowadzi do szybkiego zakupu. W B2B mogą pojawić się limity, zapytania ofertowe, akceptacje, numery zamówień klienta, odroczone płatności i ponawianie wcześniejszych zakupów.
Sam proces detaliczny opisujemy szerzej przy wdrożeniu D2C na Magento 2.
- 05
Interfejs i treści
Klient B2C potrzebuje sprawnego wyboru produktu. Użytkownik biznesowy częściej pracuje na indeksach, listach, historii zakupów i szybkich formularzach zamówienia. Oba interfejsy powinny odpowiadać temu, jak podejmowana jest decyzja.
- 06
Panel i raportowanie
Zespół klienta potrzebuje jasnego podziału zamówień, klientów, cen i treści. Zakres panelu powinien ograniczać ręczne działania, zamiast przenosić je z arkuszy do kolejnych ekranów administracyjnych.
Każdy typ danych musi mieć jedno wskazane źródło
Wspólna platforma wymaga ustalenia, który system odpowiada za produkt, cenę, stan, klienta i status zamówienia. Bez tej decyzji integracje zaczynają powielać reguły biznesowe w kilku miejscach.
Produkt może pochodzić z PIM, cena kontraktowa z ERP, dostępność z WMS, a dane klienta z CRM. Magento korzysta z tych informacji podczas sprzedaży i przekazuje dalej zamówienia oraz zmiany statusów.
Przed estymacją sprawdzamy format danych, dostępność API, częstotliwość synchronizacji i sposób obsługi błędów. Jakość integracji wpływa na pracę zespołu długo po uruchomieniu platformy.
Żaden z wymienionych systemów nie jest obowiązkowy. Część firm prowadzi oba kanały na jednym ERP, inne rozdzielają dane produktowe do PIM dopiero przy kolejnych rynkach lub markach.
Przykładowa macierz danych
Produkty i atrybuty
PIM lub ERPB2C i B2B
Decyzja do podjęciaKtóry system jest źródłem głównym
Stany i rezerwacje
ERP lub WMSDostępność oraz realizacja zamówienia
Decyzja do podjęciaJak często dane mają być aktualizowane
Ceny i rabaty
ERP, CRM lub MagentoOferta detaliczna i warunki B2B
Decyzja do podjęciaGdzie utrzymywane są reguły
Klienci i firmy
CRM, ERP lub MagentoKonta, role, segmenty
Decyzja do podjęciaKtóry system tworzy oraz aktualizuje rekord
Zamówienia i statusy
Magento, ERP, WMSObsługa sprzedaży oraz komunikacja
Decyzja do podjęciaJak obsługiwać błędy i ponowienia
Przykładowa macierz. Finalny podział wynika z architektury systemów klienta.
Najpierw ustalamy reguły sprzedaży, później budujemy platformę
Projekt B2C i B2B zawiera wiele zależności między sprzedażą, logistyką, finansami, e‑commerce i IT. Wczesne ustalenie zasad ogranicza liczbę zmian wykonywanych już podczas budowy platformy.
- 01
Diagnoza modelu sprzedaży
Porządkujemy obecne procesy, role zespołów, problemy obu kanałów i plany rozwoju. Rezultatem jest lista obszarów wspólnych oraz różnic wymagających osobnej obsługi.
Co zostaje po etapieLista obszarów wspólnych i różnic między kanałami
- 02
Architektura i zakres
Ustalamy strukturę witryn, źródła danych, mapę integracji, odpowiedzialność systemów oraz granice customizacji. Te ustalenia trafiają do zakresu i backlogu.
Co zostaje po etapieOpis architektury, mapa integracji, zakres i backlog
- 03
UX obu kanałów
Projektujemy ścieżki zakupowe B2C i B2B, konta, wyszukiwanie, koszyk, checkout oraz funkcje wykorzystywane po zalogowaniu. Prototyp pozwala zweryfikować proces przed developmentem.
Co zostaje po etapiePrototyp obu ścieżek zakupowych i projekt interfejsu
- 04
Development i integracje
Frontend, backend oraz integracje powstają w kolejności uwzględniającej zależności między systemami. Kod przechodzi przegląd, a postęp jest raportowany w ramach ustalonego procesu projektowego.
Co zostaje po etapieKod po code review, dokumentacja integracji, raporty postępu
- 05
Dane, testy i odbiory
Sprawdzamy scenariusze obu kanałów, uprawnienia, ceny, zamówienia i wymianę danych. Migracja oraz importy wymagają prób przed uruchomieniem produkcyjnym.
Co zostaje po etapieScenariusze testowe, wyniki próbnych importów, protokół odbioru
- 06
Start i dalszy rozwój
Uruchomienie obejmuje plan wdrożenia, kontrolę najważniejszych procesów i obsługę błędów wykrytych po starcie. Kolejne zmiany trafiają do uporządkowanego backlogu rozwojowego.
Co zostaje po etapiePlan uruchomienia, lista monitorowanych procesów, backlog rozwojowy
Po uruchomieniu
Odpowiedzialność nie kończy się w dniu publikacji
Stabilizacja, monitoring, obsługa zgłoszeń i wymagany poziom SLA są ustalane przed startem. Zakres utrzymania platformy opisujemy w AURORA CARE, a dalszy rozwój funkcji w AURORA EVOLUTION.
Projekt ma być możliwy do kontrolowania przed uruchomieniem
Wdrożenie obejmujące dwa kanały ma więcej zależności niż standardowy sklep. Kontrola wymaga jasnego zakresu, osób odpowiedzialnych za decyzje, kryteriów odbioru i procedury obsługi zmian.
- 01
Zakres i estymacje
Założenia, zależności oraz elementy wyłączone z zakresu powinny być widoczne przed rozpoczęciem prac. Zmiana wymagania musi mieć pokazany wpływ na budżet, termin i pozostałe funkcje.
- 02
Prowadzenie projektu
Stały Project Manager porządkuje decyzje, zadania i komunikację. E‑commerce Manager nie powinien pełnić roli osoby codziennie pilnującej pracy dostawcy.
- 03
Jakość techniczna
Kod przechodzi code review, a funkcje są sprawdzane przez QA. Dokumentacja obejmuje architekturę, integracje i elementy potrzebne do późniejszego rozwoju.
- 04
Utrzymanie po starcie
Monitoring, obsługa zgłoszeń, rozwój oraz wymagany poziom SLA powinny zostać ustalone przed uruchomieniem. Pozwala to uniknąć sytuacji, w której odpowiedzialność kończy się w dniu publikacji.
Fragmenty rzeczywistej dokumentacji, backlogu i raportów pokazujemy na etapie oferty, po anonimizacji danych klienta.
Przed startem sprawdzamy cały przebieg zakupu i obsługi zamówienia
Sam poprawnie działający checkout nie wystarcza. Test musi objąć ceny, role, stany, płatności, wymianę danych i dalszą obsługę zamówienia w systemach firmy.
Scenariusze są przygotowywane osobno dla B2C i B2B, a następnie łączone z testami integracji. Zakres listy zależy od funkcji, systemów oraz modelu wdrożenia.
B2C
- widoczność produktów i promocji
- warianty, koszyk i checkout
- płatność oraz dostawa
- konto klienta i komunikacja po zamówieniu
B2B
- rejestracja i weryfikacja firmy
- role oraz uprawnienia użytkowników
- ceny, katalogi i limity
- akceptacja, płatność oraz ponawianie zamówień
Integracje
- import produktów i cen
- aktualizacja dostępności
- przekazanie zamówienia
- zwrot statusów
- obsługa przerwanego połączenia i ponowienia
Operacje
- uprawnienia administratorów
- powiadomienia
- raporty
- monitoring
- procedura publikacji i wycofania wersji
Wspólne Magento ma sens, gdy oba kanały rzeczywiście współdzielą procesy
Połączenie B2C i B2B powinno upraszczać operacje firmy. Sam fakt prowadzenia dwóch kanałów nie przesądza jeszcze, że muszą znaleźć się w jednej architekturze.
Wspólna platforma jest dobrym kierunkiem, gdy
- 01oba kanały korzystają z tego samego katalogu lub dużej części wspólnej oferty
- 02stany, zamówienia i dane produktowe są obsługiwane przez te same systemy
- 03sprzedaż B2B wymaga kont, cen, uprawnień i procesów wykraczających poza zwykłe konto detaliczne
- 04zespół chce ograniczyć liczbę osobnych paneli oraz integracji
- 05firma planuje rozwój obu kanałów, marek lub rynków
Najpierw trzeba rozważyć inny wariant, gdy
- zamówienia B2B są nieliczne i sprawnie obsługiwane w obecnym procesie
- kanały działają w całkowicie osobnych spółkach oraz systemach
- wymagany jest pełny podział danych, zespołów i infrastruktury
- obecna platforma może zostać rozszerzona bez kosztownej przebudowy
- firma nie ma osoby odpowiedzialnej za decyzje procesowe i dane
Jeżeli oba kanały działają dziś na osobnych platformach, zaczynamy od porównania procesów, danych i kosztów. Dopiero potem rekomendujemy wspólną architekturę, rozbudowę obecnego systemu albo pozostawienie kanałów osobno.
B2C i B2B na Magento 2 w praktyce – case study Paxit
Paxit sprzedaje kartony klientom firmowym i indywidualnym, online i telefonicznie. Nowy sklep Magento 2 miał obsłużyć oba modele jednocześnie i połączyć ofertę produkowaną na zamówienie z systemem ERP.
- Punkt wyjścia
- Rozmowa zaczęła się od opieki nad istniejącym sklepem. Analiza pokazała, że techniczne zaniedbania poprzedniego wykonawcy blokują dalszy rozwój, więc wspólnie zdecydowaliśmy o budowie nowego Magento 2.
- Oba kanały w jednym sklepie
- Projekt graficzny i procesy powstały z uwzględnieniem klientów biznesowych i indywidualnych naraz, z indywidualnymi warunkami przypisanymi do kont.
- Katalog i ERP
- Paxit realizuje niemal każdy wzór i rozmiar kartonu, więc oferta musiała zostać połączona z ERP tak, aby obsługa szła automatycznie od zamówienia przez produkcję po wysyłkę i fakturowanie.
- Integracje i proces zakupu
- Magento 2 połączone z ERP, BaseLinkerem, Thulium i Trusted, z wyszukiwarką Doofinder oraz zamówieniem finalizowanym na jednej stronie.
- 1platforma dla obu kanałów
- 5systemów połączonych z Magento 2
- 2ścieżki zamówienia: online i telefon
Zobacz, jak przebiegała decyzja o nowym sklepie, projekt obu ścieżek zakupowych i połączenie oferty z systemem ERP.
Zobacz case study PaxitNajczęstsze pytania o połączenie B2C i B2B na Magento 2
Odpowiedzi dotyczą zakresu usługi, edycji platformy, integracji oraz warunków, od których zależą koszt, termin i sposób uruchomienia obu kanałów.
Omówmy połączenie B2C z B2BTak, jeżeli wspólna architektura wynika z procesów i danych firmy. Magento może rozdzielać witryny, katalogi, ceny, role oraz ścieżki zakupowe. Model wdrożenia zależy od edycji platformy, integracji i wymaganej niezależności kanałów.
Tak i najczęściej właśnie o to chodzi: produkt zakładany jest raz, a to, kto go widzi i w jakiej cenie, wynika z przypisania do witryny oraz z grupy klienta. Część asortymentu może pozostać wyłącznie hurtowa, a część wyłącznie detaliczna. Ważniejsze od samego katalogu jest ustalenie, który system jest źródłem produktów, cen i stanów — bez tego wspólny katalog szybko rozjeżdża się między kanałami.
Zakres może obejmować ceny przypisane do grupy lub konkretnego klienta, indywidualne katalogi, rabaty, limity i warunki płatności. Przed estymacją trzeba ustalić, gdzie te reguły są przechowywane i kto nimi zarządza.
Nie. Oba kanały mogą mieć osobne interfejsy, nawigację, treści oraz funkcje. Wspólna pozostaje wybrana warstwa danych, integracji i administracji. Tak działa Pronar Wheels: dwie odrębne witryny w jednej instancji Magento 2, na jednej integracji z SAP.
Decyzja powinna wynikać z wymaganych funkcji, kosztu licencji, zakresu customizacji i planów rozwoju. Część funkcji B2B może być dostępna w wybranej edycji, a część wymagać modułów lub osobnego developmentu. Porównanie powinno powstać przed zatwierdzeniem architektury. Zakres samej edycji Open Source pokazuje Demo Magento 2.
Często jest to możliwe, ale wymaga wcześniejszego audytu kodu, danych, checkoutu i integracji. Rozbudowa ma sens wtedy, gdy obecna baza techniczna jest stabilna i pozwala rozwijać drugi kanał bez utrwalania długu technologicznego. Jeżeli sklep został zbudowany niekompletnie, punktem wyjścia bywa dokończenie sklepu na Magento 2.
Sama decyzja o Magento nie oznacza automatycznej wymiany pozostałych systemów. Trzeba sprawdzić dostępne API, jakość danych i obecne integracje. Czasem wystarczy nowe połączenie, a czasem potrzebne jest uporządkowanie danych albo osobny PIM.
Estymacja powstaje po ustaleniu architektury i zakresu, bo to one decydują o kosztach: liczba witryn, zakres funkcji B2B, reguły cenowe, liczba integracji, zakres prac projektowych i wymagany poziom testów. Sama liczba produktów albo klientów nie wystarcza do wyceny. Jeżeli projekt ma się zmieścić w zamkniętym zakresie i stałej cenie, punktem odniesienia jest AURORA ONE — z zastrzeżeniem, że rozbudowane procesy B2B wychodzą poza ten standard.
Harmonogram przygotowujemy po analizie procesów i zależności. Największy wpływ mają integracje, gotowość danych produktowych i cenowych, liczba funkcji B2B oraz czas potrzebny zespołowi klienta na decyzje i odbiory. Przy dwóch kanałach dochodzi jeszcze jedno: uzgodnienie reguł sprzedaży pomiędzy działem detalicznym a hurtowym potrafi trwać dłużej niż sam development.
Wspólna platforma jest zwykle tańsza w utrzymaniu, bo nie dubluje integracji, aktualizacji, testów ani pracy nad danymi produktowymi. Dwa osobne sklepy bywają jednak rozsądniejsze, gdy kanały mają odrębne modele biznesowe, zespoły i budżety albo gdy wymagania B2B wykluczają wspólną architekturę. Trzy scenariusze i ich koszt utrzymania porównujemy w sekcji o architekturze obu kanałów.
Tak, jeżeli architektura oraz zależności pozwalają bezpiecznie podzielić projekt. Etapy muszą prowadzić do docelowego modelu. Rozwiązania tymczasowe nie powinny tworzyć kolejnych integracji i procesów, które po kilku miesiącach trzeba będzie usunąć.
Po starcie potrzebne są stabilizacja, monitoring, obsługa zgłoszeń oraz dalszy backlog rozwojowy. Zakres utrzymania i wymagany poziom SLA można ustalić w ramach AURORA CARE.
Planujesz przy tym sprzedaż na kolejnych rynkach? Zakres wielojęzycznej i wielosklepowej architektury opisujemy w AURORA CROSS. Przy zamkniętym, ustandaryzowanym zakresie warto sprawdzić AURORA ONE.
Zacznijmy od procesów B2C i B2B, które dziś trzeba połączyć
Na pierwszej rozmowie omawiamy kanały sprzedaży, obecne systemy, źródła danych i najważniejsze ograniczenia. Jeśli wspólna platforma nie będzie uzasadniona, powiemy to wprost.
Nie musisz mieć gotowej specyfikacji. Przydatne będą informacje o obecnej technologii, sposobie obsługi klientów firmowych, systemach do integracji oraz planach rozwoju obu kanałów.
Czego możesz oczekiwać po wysłaniu zapytania
- 1Kontakt w ciągu 1 dnia roboczego i pytania uzupełniające o oba kanały sprzedaży.
- 2Rozmowa o procesach, źródłach danych i systemach obsługujących zamówienia.
- 3Informacja, czy wspólna platforma Magento 2 jest uzasadniona i jakie dane są potrzebne do przygotowania zakresu.