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.
Blog / Case Studies
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.
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ść.
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”.
Żeby uczciwie opisać problem, warto nazwać trzy równoległe tory pracy:
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.
Warstwa CRM w tym modelu nie jest „kolejnym narzędziem sprzedażowym”. Jest mostem między marketingiem a realizacją:
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.
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:
To jest warstwa, której nie zastąpi sam CRM — CRM kończy się tam, gdzie zaczyna się fizyczna realizacja i kolejka operacyjna.
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.:
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.
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.
„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”.
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.
Ż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).
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.
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