Case study CRM i ERP: zrzut pulpitu administracyjnego (środowisko demo na izolowanej kopii — dane fikcyjne)

Blog / Case Studies

Case study: CRM + ERP w firmie eventowej

Od prostego CMS do spójnego ekosystemu: warstwa CRM, ERP operacyjny (TTDB), moduł produkcyjny drinkbaru i panel SEO — bez rozjechanego Excela i „tablicy korkowej” w głowie.

7 maja 2026Aktualizacja: 7 maja 202612 min czytaniaPoziom: ZaawansowanyCzas wdrożenia: Iteracyjny rozwój od MVP CMS do pełnego ERP
CRMERPcase studyeventy

TL;DR

Jak dla marki eventowej połączyłem sprzedaż, realizację i zaplecze magazynowe w jednym autorskim systemie: CRM na leady, ERP TTDB na operację, Kamikaze (drinkbar) na produkcję i moduł SEO na widoczność.

  • Zobaczysz, jakie działania dają największy efekt najszybciej.
  • Dostaniesz jasny kontekst: dla kogo to rozwiązanie i kiedy je wdrażać.
  • Na końcu dostaniesz konkretny następny krok do realizacji.

Case study: gdy prosty CMS przestaje wystarczać

W branży eventowej sezon robi różnicę między „jesteśmy w kontakcie” a „nie mamy jak tego dowieźć”. Na początku wystarcza strona, formularz i skrzynka mailowa. Gdy jednak rośnie liczba zapytań, powtarzalnych usług i jednoczesnych realizacji, Excel i notatki w telefonie zaczynają kosztować więcej niż wdrożenie porządnego zaplecza.

Ten wpis opisuje ewolucję od prostego CMS do zintegrowanego systemu CRM + ERP dla firmy eventowej: jedna baza prawdy, jeden panel, a na froncie nadal lekka, sprzedażowa strona. To nie jest teoria — to układ modułów, który realnie utrzymuję i rozwijam w ekosystemie m.in. magic-moments.pl, tutaj jednak skupiam się na warstwie CRM / ERP / produkcji / SEO, którą właściciele widzą jako „to, co ogranicza chaos”.

Statystyki — co realnie dzieje się na stronie i w lejku

Kontekst: jedna firma, wiele równoległych procesów

Żeby uczciwie opisać problem, warto nazwać trzy równoległe tory pracy:

  • Sprzedaż i obsługa leadów — szybka odpowiedź, kwalifikacja, brief, follow-up.
  • Realizacja eventu — ludzie, terminy, checklisty, komunikacja z klientem.
  • Zaplecze produkcyjne i magazyn — np. drinkbar: receptury, stany, koszty, logistyka.

Gdy te tory dzieją się w osobnych narzędziach, powstaje tarcie: ten sam lead jest opisany inaczej w mailu i w arkuszu, a magazyn nie „wie”, co handlowiec obiecał na piśmie. CRM + ERP ma jeden cel: spiąć te tory tak, by każda decyzja była widoczna w systemie, a nie tylko w głowie zespołu.

ERP TTDB — leady, realizacja i „kto za co odpowiada”

Warstwa CRM: od zapytania do zlecenia bez utraty kontekstu

Warstwa CRM w tym modelu nie jest „kolejnym narzędziem sprzedażowym”. Jest mostem między marketingiem a realizacją:

  • Zapytania z formularzy i kalkulatorów lądują w jednym obiegu — z historią statusów i przypisaniem.
  • Pola briefu są wymuszone tam, gdzie to ma sens (data, lokalizacja, zakres), żeby nie drukować domysłów.
  • Handlowiec i koordynator widzą ten sam rekord — nie ma przepisywania treści z maila do „oficjalnej wersji”.

Dzięki temu firma eventowa może skalować sezon bez proporcjonalnego wzrostu chaosu komunikacyjnego. To szczególnie ważne, gdy w grę wchodzą nietypowe pakiety i dodatki — konfiguracja usługi musi przetrwać drogę od rozmowy do realizacji.

ERP TTDB: operacja, która musi mieć twardy stan

TTDB (u nas: „To Ty Dziś Błyszczysz” — operacyjny humor nazewniczy, ale serce systemu jest poważne) to warstwa ERP pod codzienną pracę zespołu: lista zadań, stany zleceń, miejsca, gdzie coś „wisi” i wymaga decyzji. Dla eventów „wiszącym” elementem bywa nie tylko data, ale też zależność od dostawców, transportu i przygotowań logistycznych.

W panelu TTDB chodzi o to, by:

  • dało się filtrować to, co pilne, zamiast przewijać długą listę „wszystkiego”,
  • statusy były jednoznaczne — każdy w zespole wie, co oznaczają,
  • historia zmian była czytelna — kto, kiedy i co ustawił (bez polowania na screeny z czatu).

To jest warstwa, której nie zastąpi sam CRM — CRM kończy się tam, gdzie zaczyna się fizyczna realizacja i kolejka operacyjna.

Kamikaze / drinkbar — produkcja, magazyn i marża

Kamikaze (drinkbar): gdy produkcja musi znać liczby

Moduł Kamikaze (drinkbar ERP) jest przykładem na to, że event to nie tylko „wyjście na salę”, ale też koszt materiału, czasu i magazynu. W sezonie liczy się marża na zestawie, a nie tylko efekt „wow” na Instagramie.

System wspiera m.in.:

  • Receptury i kalkulacje — żeby wycena nie była „na oko”,
  • Stany i alerty — żeby krytyczny brak wyszedł przed wieczorem przed imprezą, a nie w trakcie,
  • Spójność z ofertą — żeby to, co sprzedał dział handlowy, dało się fizycznie zrealizować.

To jest typowy obszar, gdzie „pusty panel” na zrzucie ekranu kłamie — dlatego pod materiały demonstracyjne przygotowuję w pełni zasilone środowisko testowe (fikcyjne dane, bez danych klientów z produkcji), żeby pokazać realny rytm pracy, a nie szkielet.

SEO w panelu: porządek, który skaluje organic

Warstwa SEO w administracji to nie magiczny przycisk „zrób top1”. To raczej dyscyplina treści: meta, spójność wewnętrznych powiązań, podgląd tego, co idzie do indeksu, i miejsce na iterację. Dla firmy eventowej SEO często pracuje ramię w ramię z contentem edukacyjnym i landingami usług — jeśli panel utrudnia utrzymanie porządku, jakość organiczna się „rozjeżdża” wraz z sezonem.

Dlategy moduł SEO jest traktowany jak część tego samego produktu operacyjnego co CRM i ERP: jeden login, jedna struktura danych, mniej miejsca na błąd ludzki przy publikacji.

SEO w panelu — porządek w meta i treściach pod indeks

Głos klientki: dlaczego spójny system ma znaczenie

„Na początku myślałam, że najważniejsza będzie sama strona. Okazało się, że ratuje nas to, że wszystko jest w jednym miejscu — od zapytania, przez umowę, po magazyn i drinkbar. Nie musimy już dogadywać się na trzech czatach.”

Agata Mierzwińska, Magic Moments (fragment rozmowy o wdrożeniu; cytat redakcyjnie skrócony pod case study)

To, co opisuje Agata, jest najlepszym testem dla architektury: czy osoba nietechniczna czuje spokój, że „system pamięta”, zamiast że „ja muszę pamiętać za wszystkich”.

Liczby i efekt (w kontekście całego ekosystemu)

W case study magic-moments.pl pokazałem już twardy sygnał z warstwy sprzedażowej: 15 zapytań ofertowych miesięcznie już w pierwszym miesiącu po ożywieniu domeny, przy zerowym budżecie na Ads w tym oknie — bo front i narzędzia konwersji zrobiły swoje.

Warstwa CRM + ERP, o której mówimy tutaj, jest odpowiedzią na kolejne pytanie: jak utrzymać jakość obsługi i marżę, gdy liczba zapytań i jednoczesnych realizacji rośnie. Same liczby marketingowe nie zastąpią porządku operacyjnego — ale porządek operacyjny pozwala nie zmarnować leadów, które marketing i SEO już dostarczyły.

Jak powstają zrzuty do tego artykułu (etyka i bezpieczeństwo)

Żeby nie mieszać produkcji z marketingiem, materiały wizualne do sekcji administracyjnych powstają na odseparowanej kopii projektu i osobnej bazie demo (mm_admin_screenshots): fikcyjni klienci, sztuczne SKU, zsyntetyzowane metryki. Żadnych danych osobowych klientów i żadnych sekretów produkcyjnych na zrzutach.

Miniatury w galerii mają ten sam rozmiar co w case study Magic Moments (880×495 px, letterbox); pełne zrzuty są w układzie 1920×1200 pod szeroki pulpit admina. Grafiki powstają z tych samych arkuszy stylów co panel (admin-panel.css / admin-style.css z kopii projektu) i treści demo spójnej z scripts/mm-admin-screenshots-seed.sql — polecenie npm run captures:crm-erp-admin. Pełny render PHP z żywą bazą: npm run captures:crm-erp-admin-live (wymaga php -S i MySQL).

Potrzebujesz spójnego CRM / ERP zamiast kolejnych plików Excel?

Jeśli Twoja firma eventowa (lub pokrewna usługowo-produkcyjna) dobija do ściany „mamy leady, ale ginie kontekst”, napisz — najpierw uporządkujemy proces (co ma być prawdą w systemie), potem dobierzemy zakres modułów: CRM, ERP, produkcja, SEO, integracje.

Umów krótką rozmowę — kontakt

Dla kogo

Dla firm, które chcą poprawić jakość strony i komunikacji bez technicznego chaosu i bez zgadywania, co wdrażać najpierw.

Kiedy stosować

Gdy ruch na stronie nie przekłada się na zapytania lub gdy treści wyglądają poprawnie, ale nie prowadzą użytkownika do decyzji.

Najczęstsze błędy

  • Publikowanie ściany tekstu bez hierarchii i bez sekcji decyzyjnych.
  • Brak jasnego następnego kroku po przeczytaniu wpisu.
  • Niespójny styl modułów (każdy wpis wygląda inaczej i miesza odbiorcę).

Następny krok

Przejdź od czytania do działania

Jeśli chcesz, przygotuję dla Ciebie plan wdrożenia pod Twój przypadek: co poprawić najpierw, co odłożyć i jak mierzyć efekt.