Case study · hurtownia stomatologiczna B2B
Hurtownia, która sprzedaje
wiertła po kodzie, kształcie i zabiegu
DrillStom jest wyłącznym importerem wierteł diamentowych MDT w Polsce i sprzedaje tylko do gabinetów oraz klinik. Zbudowaliśmy sklep od zera na Medusie: katalog techniczny, matrycę wariantów zamiast rozwijanych list, sprzedaż w opakowaniach, konta firmowe i wystawianie dokumentów. Sklep działa pod adresem drillstom.pl, więc każdy ekran z tej strony można otworzyć i sprawdzić.
- B2B
- Wyroby medyczne
- Medusa
- Integracja ERP
- Katalog techniczny
Od pierwszego commita do działającego sklepu
3 miesiące
Kategorii katalogu
35
Kart produktu w sitemapie
177
Wariantów jednego kształtu na jednym ekranie
25
Punkt wyjścia
Katalog techniczny, którego żaden szablon sklepowy nie umie obsłużyć
Wiertło stomatologiczne nie jest produktem w sensie, w jakim rozumie go typowy sklep internetowy. Jeden kształt to kod z drukowanego katalogu, pięć gradacji ziarna, pięć średnic, trzy typy chwytu i opakowanie po pięć sztuk. Kupujący zna kod, bo ma go na pudełku, i chce zamówić kilka wariantów naraz. Standardowa karta produktu z rozwijanymi listami wymaga od niego dwudziestu pięciu przejść przez ten sam formularz.
Problem
Sprzedaż działała, ale w całości poza internetem. Zamówienia przychodziły telefonem i mailem, ceny brały się z PDF-owego katalogu producenta, a każdy kod trzeba było przepisać ręcznie do faktury. Przy kilkunastu pozycjach na zamówienie to nie jest niedogodność, to jest etat.
- Kupujący zna kod z pudełka, na przykład 368 albo 801, a nie nazwę handlową. Wyszukiwarka sklepowa po nazwach nie pomaga.
- Jeden kształt występuje w 25 wariantach: 5 gradacji ziarna na 5 średnic. Rozwijane listy zamieniają jedno zamówienie w 25 osobnych decyzji.
- Wiertła idą po pięć w opakowaniu, a część konkurencji podaje ceny za sztukę. Bez przeliczenia obok oferta wygląda drożej, niż jest.
- To wyroby medyczne. Sprzedaż jest dozwolona wyłącznie do gabinetów i klinik, więc sklep musi weryfikować, kto zamawia.
- Faktury i listy przewozowe powstawały ręcznie, po zamówieniu, z przepisywaniem kodów i danych firmy.
- Katalog producenta ma swój układ, ułożony według chwytu i kształtu. Kupujący myśli tym układem, a nie kategoriami wymyślonymi przez agencję.
Cel
Nie „mieć sklep", a przenieść do internetu ten sposób zamawiania, który już działa przy telefonie, i odebrać z biurka ręczną część pracy. Cel ustawiliśmy w Blueprincie, przed pierwszą linijką kodu, i zamknęliśmy w pięciu zdaniach, które dały się sprawdzić po starcie.
- Kupujący znajduje wiertło trzema drogami: po kodzie, po kształcie albo pod konkretny zabieg.
- Całe zamówienie na jeden kształt, także dwadzieścia pięć wariantów, powstaje na jednym ekranie.
- Cena jest widoczna bez logowania, brutto za opakowanie, z przeliczeniem na sztukę obok.
- Faktura i przesyłka powstają z zamówienia automatycznie, bez przepisywania kodów.
- Katalog rozbudowuje zespół klientki, bez zgłoszenia do programisty.
Jak odpowiedzieliśmy
Zamiast dopasowywać branżę do szablonu, przenieśliśmy do modelu danych logikę drukowanego katalogu MDT. To jedna decyzja, z której wynika prawie wszystko pozostałe: układ kategorii, kształt karty produktu i matryca wariantów.
01
Blueprint: model danych przed interfejsem
Najpierw rozłożyliśmy katalog producenta na osie: kod ISO 6360, kształt głowicy, gradacja ziarna z zakresem w mikronach, średnica, długość części pracującej, typ chwytu. Dopiero na tym stanął model produktu w Medusie. Pierwsza wersja kategorii stała na dwóch osiach i okazała się nietrafiona; przebudowaliśmy ją na trzydzieści pięć kategorii w układzie, którego używa klientka.
02
Trzy wejścia do katalogu zamiast jednego menu
Wyszukiwarka przyjmuje kod, nazwę kształtu i gradację. Obok stoją dwie osobne ścieżki: przeglądanie po kształcie i dobór według zabiegu. Filtry po chwycie, kształcie i gradacji zawężają wynik bez opuszczania listy, a liczniki przy każdej opcji od razu pokazują, ile zostanie produktów.
03
Matryca wariantów w miejsce rozwijanych list
Komponent, który odwzorowuje tabelę z drukowanego katalogu: wiersze to gradacje, kolumny to średnice, komórka to konkretny wariant z dostępnością i liczbą opakowań. Opisujemy go osobno niżej, bo to najmocniejszy element tego wdrożenia.
04
Opakowanie jako jednostka handlowa
Cena, koszyk, faktura i list przewozowy liczą opakowania, nie sztuki. Przeliczenie na sztukę pokazujemy obok, żeby kupujący mógł porównać ofertę z konkurencją, która liczy inaczej. To reguła w modelu cenowym, nie adnotacja w opisie.
05
Brama profesjonalisty
Przy wyrobach medycznych sklep musi rozstrzygnąć, kto jest po drugiej stronie. Weryfikacja stoi przed zakupem, a nie przed obejrzeniem katalogu: ceny widać od razu, bo ukrywanie ich za logowaniem odcina też wyszukiwarki i modele językowe.
06
Integracje, które zdejmują pracę z biurka
Fakturownia dostaje zamówienie z pozycjami, kodami i danymi firmy. Apaczka dostaje przesyłkę. Obie strony działają na tych samych danych, więc nie ma miejsca, w którym ktoś przepisuje kod 368 z ekranu na papier.
Katalog
Trzy drogi do tego samego wiertła
Kupujący w gabinecie nie szuka „wiertła stożkowego". Szuka kodu, który zna z pudełka, kształtu, który widzi w głowie, albo wiertła pod konkretny zabieg. Katalog obsługuje wszystkie trzy wejścia naraz. Trzydzieści pięć kategorii ułożyliśmy według układu, którego używa klientka, a nie według dwóch osi, jak było w pierwszej wersji. Cały katalog jest dostępny bez logowania, więc 228 adresów z sitemapy może indeksować Google i pobierać modele językowe.
Wyróżnik wdrożenia
Matryca wariantów: dwadzieścia pięć decyzji
zamienione w jeden ekran
To komponent zbudowany pod tę branżę, nie funkcja z półki. Grupa docelowa zamawia z drukowanej tabeli producenta od kilkudziesięciu lat i myśli jej układem: gradacja w wierszach, średnica w kolumnach, na przecięciu konkretne wiertło. Odwzorowaliśmy tę tabelę w sklepie, razem z dostępnością i liczbą opakowań w komórce. Kupujący widzi wszystkie dwadzieścia pięć wariantów jednego kształtu naraz i zaznacza kilka bez opuszczania ekranu.
Wiersze i kolumny z katalogu, nie z panelu
Wiersze to realne gradacje danego produktu, z kodem ISO 6360 i zakresem ziarna w mikronach: K0 to 20 do 38 µm, K5 to 152 do 181 µm. Kolumny to średnice występujące w tym kształcie. Matryca nie pokazuje wariantów, których dany produkt nie ma, więc nie ma pustych przecięć do zgadywania.
Sylwetka w rzeczywistych proporcjach
Nad każdą kolumną stoi rysunek wiertła zachowujący prawdziwy stosunek średnicy do długości części pracującej. Różnica między ⌀014 i ⌀023 jest wtedy widoczna, a nie tylko zapisana. Pod nagłówkiem stoi osobny wiersz z długością części pracującej, bo to druga liczba, która rozstrzyga zakup.
Kolor gradacji zgodny z pierścieniem na wiertle
Gradacja ma kolor, ten sam, który producent nadaje pierścieniowi na chwycie. Kupujący rozpoznaje go z pudełka. Kontrast pary tło i tekst w zaznaczonej komórce sprawdziliśmy pod WCAG AA, bo kolor jest tu nośnikiem informacji, nie dekoracją.
Dostępność w komórce, nie po kliknięciu
Każda komórka ma kropkę stanu magazynowego. Widać od razu, których wariantów nie ma, więc kupujący nie buduje zamówienia, które rozsypie się w koszyku. Przy brakującym wariancie działa powiadomienie o dostępności.
Liczba opakowań wprost w komórce
Po zaznaczeniu komórka zamienia się w licznik minus, liczba, plus. Wartość to opakowania, nie sztuki, z przypomnieniem, że jedno opakowanie to pięć sztuk. Zamówienie na dwanaście pozycji powstaje w dwanaście kliknięć w jednej tabeli.
Przełącznik matryca albo lista
Nie każdy chce tabeli, więc obok stoi klasyczna lista wariantów. To jeden przełącznik na karcie produktu i wspólne dane pod spodem, więc żaden z dwóch widoków nie jest osobną implementacją do utrzymania.
Ten jeden komponent jest odpowiedzią na pytanie, po co w ogóle budować sklep na Medusie, zamiast wynająć szablon. Matrycy nie da się zrobić konfiguracją. Trzeba mieć dostęp do modelu wariantów i do karty produktu, a to jest dokładnie ta granica, na której kończą się platformy zamknięte.
Karta produktu i kategorie
Dane techniczne, które rozstrzygają zakup
W tej branży karta produktu jest dokumentem, nie opisem marketingowym. Kod, norma ISO 6360, marka, wielkość opakowania i długość części pracującej stoją w nagłówku, bo od nich zależy decyzja. Cena jest brutto za opakowanie, z przeliczeniem na sztukę obok, a stały klient widzi informację o indywidualnych warunkach bez konieczności logowania.
01
Nagłówek, który odpowiada przed przewinięciem
Kod 368, ISO 6360 257, marka MDT, opakowanie 5 szt. Cztery liczby w jednej linii pod tytułem, przed zdjęciem i przed opisem. Cena brutto za opakowanie stoi wyżej niż galeria, bo w hurcie to ona jest treścią karty. Ramka o warunkach indywidualnych mówi wprost, że ceny widać bez logowania, a stali klienci mogą mieć ustalone własne.
02
Kategorie w układzie katalogu producenta
Wiertła diamentowe na turbinę to pięćdziesiąt osiem produktów, więc kategoria musi filtrować, a nie tylko wypisywać. Zakładki na górze prowadzą po typie chwytu, panel z lewej po kształcie i gradacji, a liczniki przy każdej opcji pokazują, ile produktów zostanie po jej włączeniu. Karty w siatce mają zdjęcia realnych wierteł, nie rendery, bo w tej branży pierścień na chwycie jest informacją.
Stos
- Medusa 2.8.4
- Next.js 15
- PostgreSQL
- Fakturownia
- Apaczka
- Railway
Warunki
Na jakich zasadach to powstało
Nie chodzi o metodykę na slajdzie, a o cztery ustalenia, które rozstrzygnęły przebieg projektu. Każde z nich stosujemy tak samo przy kolejnych wdrożeniach, więc to najbliższa rzecz do odpowiedzi na pytanie „jak się z wami pracuje".
- Czas realizacji
- 3 miesiące
- Od pierwszego commita do sklepu przyjmującego zamówienia. Bez środowiska przejściowego, o czym uczciwie niżej.
- Model rozliczenia
- stały zakres
- Zakres zamknięty w Blueprincie, przed kodem. Zmiany poza nim idą jako osobne zlecenia, więc projekt nie puchnie w trakcie.
- Wycena
- przed startem
- Jedna stała kwota za domknięty zakres, znana przed pierwszą linijką kodu, a nie odkrywana po fakcie na podstawie przepracowanych godzin.
- Opieka po starcie
- osobna umowa
- Utrzymanie, aktualizacje bezpieczeństwa i rozwój katalogu podpisane po starcie, a nie wymuszone jako warunek wdrożenia.
Budżetu tej realizacji nie podajemy. To informacja klientki, nie nasza, i nie publikujemy jej bez potrzeby, nawet gdy dobrze by wyglądała w case study. Nasze widełki dla porównywalnego zakresu stoją otwarcie w cenniku, więc skalę można sprawdzić bez zaglądania komuś w fakturę.
Stan po starcie
Co stoi w sklepie i czego świadomie nie podajemy
Sklep działa i jest rozwijany dalej. Sam wrzesień 2026 przyniósł zmiany w kasie, w cenniku dostawy i w danych strukturalnych pod wyszukiwarki. Liczby niżej opisują zakres i sposób pracy, a nie wynik sprzedażowy.
228
adresów w sitemapie
Cały katalog indeksowalny: 177 kart produktu i 35 kategorii. Nic nie jest schowane za logowaniem.
25
wariantów na jednym ekranie
Pięć gradacji na pięć średnic w jednej tabeli, zamiast dwudziestu pięciu przejść przez rozwijane listy.
0
ręcznie przepisywanych kodów
Fakturownia i Apaczka dostają zamówienie z pozycjami i danymi firmy bezpośrednio ze sklepu.
212
zmian przez pull requesty
Każda zmiana przez gałąź i przegląd, nie przez wrzucenie pliku na produkcję.
Czego ten case nie mówi
Nie podajemy przychodu, konwersji, liczby zamówień ani porównania „przed i po". Nie mamy dostępu do tych danych i nie zamierzamy ich szacować. Publikujemy to, co znamy z własnej faktury, a nie to, co znalibyśmy z ich rachunku wyników. Druga rzecz do powiedzenia wprost: projekt nie ma jeszcze testów automatycznych ani środowiska przejściowego, więc regresję logiki rabatów i dostaw wychwytuje dziś człowiek, a nie bramka w CI. To pierwsza pozycja na liście prac, bo w sklepie B2B najdroższy błąd jest cichy.
FAQ
Pytania, które dostajemy po tym case study
Ile kosztuje wdrożenie sklepu B2B na Medusie?
Budżetu DrillStom nie podajemy, bo to informacja klientki. Nasze własne widełki są jawne: wdrożenie od 60 000 zł netto, typowo 80 000 do 200 000 zł. Cenę podnoszą przede wszystkim trzy rzeczy: liczba rynków i walut, liczba systemów po drugiej stronie integracji oraz to, czy cennik zależy od klienta. Sama liczba produktów wpływa najmniej. Cały model wyceny stoi w cenniku, a rachunek rozkładamy w tekście ile kosztuje wdrożenie sklepu internetowego.
Jak długo trwa zbudowanie hurtowni internetowej od zera?
Tutaj trzy miesiące od pierwszego commita do sklepu przyjmującego zamówienia. Czas wydłużają głównie integracje z systemami, których nie kontrolujemy, oraz dane produktowe wymagające porządkowania. Przy migracji z gotowej platformy, na przykład z Shopera albo IdoSell, pracujemy w okolicach trzydziestu dni, bo katalog i klienci już istnieją.
Czy Medusa nadaje się do sprzedaży wyrobów medycznych?
Tak, i to jest jeden z powodów, dla których ją wybraliśmy. Sprzedaż wyrobów medycznych wymaga weryfikacji nabywcy przed zakupem, a to logika, której nie da się dołożyć konfiguracją w platformie zamkniętej. W DrillStom weryfikacja stoi przed zakupem, ale nie przed obejrzeniem katalogu: ceny są widoczne bez logowania, bo schowanie ich odcina również wyszukiwarki i modele językowe.
Jak sprzedawać produkty w opakowaniach zbiorczych, a nie w sztukach?
Opakowanie musi być jednostką handlową w modelu cenowym, a nie adnotacją w opisie. Wtedy cena, koszyk, faktura i list przewozowy liczą to samo. Przeliczenie na sztukę pokazujemy obok, bo część konkurencji podaje ceny jednostkowe i bez tego oferta wygląda drożej, niż jest. W DrillStom jedno opakowanie to pięć sztuk i ta informacja stoi przy cenie oraz w każdej komórce matrycy.
Czym jest matryca wariantów i kiedy warto ją zbudować?
To tabela, w której wiersze i kolumny są dwiema osiami wariantu, a komórka jest konkretnym produktem z dostępnością i liczbą opakowań. Ma sens wtedy, gdy klienci zamawiają wiele wariantów jednego kształtu naraz i znają je z drukowanej tabeli producenta. Poza wiertłami tak wygląda zamawianie profili, łożysk, uszczelek, śrub i wielu materiałów budowlanych. Jeśli klient zamawia jeden wariant, matryca tylko przeszkadza.
Czy taki sklep można rozbudowywać bez programisty?
Katalog tak: produkty, kategorie, opisy, zdjęcia, ceny i dostępność są w panelu Medusy i prowadzi je zespół klientki. Logika, czyli reguły cenowe, integracje i komponenty takie jak matryca, wymaga programisty, bo to kod, a nie ustawienie. Taką granicę rysujemy w każdym Blueprincie, żeby po starcie nie było rozczarowania.
Czy da się przenieść taki sklep z Shopera albo IdoSell?
Tak, i to jest nasz typowy projekt migracyjny w okolicach trzydziestu dni. Przenosimy katalog, klientów, adresy URL z przekierowaniami i historię zamówień, a dopiero potem dokładamy rzeczy, których na starej platformie nie było. Porównanie obu platform i tego, co realnie blokuje, zebraliśmy w tekście Shoper czy IdoSell, a wszystkie nasze porównania stoją w hubie porównań platform.
Jak wyglądają integracje z Fakturownią i Apaczką?
Zamówienie ze sklepu trafia do Fakturowni z pozycjami, kodami i danymi firmy, a przesyłka do Apaczki. Obie integracje działają na tych samych danych zamówienia, więc nie ma miejsca, w którym ktoś przepisuje kod z ekranu. Ten sam wzorzec stosujemy przy innych systemach księgowych i przewoźnikach; opisujemy go na stronie usługi platformy B2B.
Podobny katalog, podobny problem?
Jeśli sprzedajesz produkty techniczne w wielu wariantach, w opakowaniach zbiorczych albo do odbiorców, których trzeba weryfikować, to jest dokładnie ta rozmowa, którą prowadzimy najczęściej. Zaczynamy od Blueprintu: zakres, budżet i granica między tym, co poprowadzi Twój zespół, a tym, co zostaje kodem.
