Określenia „reseller”, „partner” i „integrator” bywają używane wymiennie, choć mogą oznaczać inny zakres. Sama etykieta nie dowodzi certyfikacji, specjalnych limitów API, szybszego supportu ani odpowiedzialności za utrzymanie sklepu. Wszystko trzeba potwierdzić w aktualnym programie Shoper i konkretnej umowie.
Co zweryfikować przed współpracą
Poproś wykonawcę o:
- oficjalną nazwę programu i możliwość potwierdzenia statusu;
- zakres sprzedaży licencji lub pośrednictwa;
- listę usług wdrożeniowych i utrzymaniowych;
- opis dostępów potrzebnych do sklepu;
- zasady kontaktu z supportem Shoper;
- osobną wycenę licencji, wdrożenia i opieki;
- procedurę zakończenia współpracy oraz przekazania dostępów.
Nie zakładaj, że partner ma „ukryte endpointy”, nielimitowane API, dostęp do infrastruktury SaaS albo gwarantowany priorytet zgłoszeń. Takie uprawnienia muszą wynikać z aktualnej dokumentacji lub umowy.
Samodzielne wdrożenie a wykonawca
| Obszar | Samodzielnie | Z wykonawcą |
|---|---|---|
| Konfiguracja | zespół uczy się platformy i odpowiada za decyzje | wykonawca może dostarczyć proces oraz doświadczenie |
| Migracja | sklep buduje mapę danych i URL-i | wykonawca powinien przedstawić zakres, testy i rollback |
| Integracje | odpowiedzialność pozostaje po stronie sklepu | odpowiedzialność trzeba podzielić między strony |
| Wsparcie | kontakt zgodny z planem i umową platformy | pierwsza linia może należeć do wykonawcy |
| Utrzymanie | sklep monitoruje zmiany | możliwa opieka według uzgodnionego SLA |
Czas i koszt zależą od liczby produktów, jakości danych, wariantów, integracji, grafiki, przekierowań i odbiorów. Nie da się uczciwie podać jednego przedziału bez audytu.
API i integracje
Przed podpisaniem umowy ustal:
- z jakiego oficjalnego API korzysta integracja;
- jakie są aktualne limity i mechanizm uwierzytelnienia;
- kto przechowuje sekrety;
- jak obsługiwane są ponowienia i limity;
- co dzieje się po błędzie ERP lub marketplace;
- gdzie znajdują się logi bez danych wrażliwych;
- kto utrzymuje kod po zakończeniu projektu.
Wykonawca nie powinien uzależniać sklepu od prywatnych narzędzi bez eksportu, dokumentacji i procedury przejęcia.
Support i SLA
„Priorytetowe wsparcie” powinno zostać przetłumaczone na mierzalny kontrakt:
- godziny dostępności;
- kanał zgłoszeń;
- klasy incydentów;
- czas reakcji, a osobno czas przywrócenia;
- zakres wyłączeń;
- eskalację do operatora platformy;
- sposób raportowania.
SLA wykonawcy nie oznacza automatycznie SLA Shopera. Jeżeli usunięcie awarii zależy od operatora SaaS, umowa powinna jasno opisywać tę granicę.
Dostęp i własność
Sklep powinien zachować własność domeny, konta, danych, kodu opłaconych modyfikacji i kluczowych integracji zgodnie z umową. Dostępy przyznawaj imiennie, z najmniejszym potrzebnym zakresem i możliwością odebrania.
Przy odbiorze wymagaj:
- mapy konfiguracji;
- rejestru integracji i sekretów bez ujawniania ich wartości;
- mapy przekierowań;
- wyników testów zakupowych;
- kopii materiałów i repozytorium;
- instrukcji awaryjnej;
- protokołu zwrotu dostępów.
Dobry partner nie jest „zewnętrznym CTO” z samej nazwy. Jest wykonawcą o jasno zdefiniowanej odpowiedzialności, dowodach kompetencji i bezpiecznej ścieżce wyjścia. Tak prowadzimy wdrożenie sklepu Shoper.
Źródła referencyjne i dalsza weryfikacja
Materiały poniżej prowadzą do dokumentacji właścicieli platform i instytucji. Są punktem kontroli aktualności, a nie automatycznym potwierdzeniem każdego zdania w artykule.
Opublikowano: · Zaktualizowano:
Masz pytania do tego artykułu lub chcesz żebym spojrzał na Twój sklep?
Napisz do CyberSolus →