- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
Software house, agencja IT, studio deweloperskie — firmy budujące oprogramowanie dla klientów mają specyficzne wymagania od systemu ticketowego, których standardowy helpdesk nie spełnia. Support klienta, zarządzanie projektem i wewnętrzne zgłoszenia techniczne to trzy różne przepływy pracy — i niekoniecznie jeden system je wszystkie obsłuży dobrze. Wiele agencji działa chaotycznie: Jira do tasków, email do supportu, Slack do komunikacji z klientem, a priorytetyzacja „kto głośniej krzyczy, ten ma szybciej”. Ten artykuł opisuje wymagania systemu ticketowego specyficzne dla software house’u i jak je zrealizować.
Trzy przepływy pracy w software house — i dlaczego jeden system je nie obsłuży
Support posprzedażowy: klient zgłasza błąd w działającym systemie, oczekuje odpowiedzi zgodnie z SLA, potrzebuje widoczności w jakim statusie jest jego sprawa. Tutaj ważna jest: szybkość, transparentność dla klienta, historia korespondencji, powiązanie z umową SLA. Zarządzanie projektem: zespół deweloperski pracuje na taskach, epikach, sprintach — z rozpiską „kto co robi”, estymacjami, review i code deploy. Tu ważne są: widoczność dla całego zespołu, integracja z GitHubem/GitLab, burn down chart, velocity. Zgłoszenia wewnętrzne: dostęp do serwerów, zmiany konfiguracji, problem z narzędziem — „IT helpdesk” dla samej firmy. Tu ważne są: priorytety, SLA wewnętrzne, asset management.
Dobierzemy i wdrożymy system ticketowy dla agencji IT — z widokiem klienta, SLA per umowa i integracją z repozytorium. Zacznij od bezpłatnej konsultacji.
Próba obsługi wszystkich trzech przepływów jednym systemem prowadzi do kompromisów. Jira jest świetna do zarządzania projektem, ale jest za złożona i za droga na support klientów z widokiem dla klienta. Zendesk jest dobry do supportu, ale nie nadaje się do zarządzania sprintami. GLPI jest dobry do wewnętrznego helpdesku IT, ale nie ma natywnych widoków dla klienta zewnętrznego. Dojrzała agencja często utrzymuje dwa systemy: jeden do zarządzania projektem (Linear, Jira, ClickUp) i jeden do supportu klientów (Zendesk, Freshdesk, Zammad) — z synchronizacją między nimi w krytycznych punktach.
Widok klienta — najczęściej zaniedbywany element
Klient software house’u płaci za usługę i ma prawo wiedzieć, co się dzieje z jego zgłoszeniami. Brak widoku dla klienta — czyli portalu, przez który klient widzi status swoich ticketów, historię zgłoszeń i SLA — to jeden z najczęstszych braków w agencjach IT. Efekt: klient wysyła maila „co z moim zgłoszeniem z zeszłego tygodnia?”, co generuje dodatkowy ticket i dodatkową pracę dla PM-a. Dobry portal klienta w systemie supportowym zawiera: listę otwartych i zamkniętych ticketów, status każdego i ostatnią aktualizację, możliwość dodania komentarza lub pliku, statystyki SLA (ile ticketów w terminie, ile po terminie). Zendesk, Freshdesk i Zammad mają ten widok out of the box — w GLPI wymaga konfiguracji, ale jest możliwy.
Integracja systemu ticketowego z repozytorium kodu
W software house każdy bug zgłoszony przez klienta powinien zamienić się w issue w repozytorium — i każde zamknięcie issue w repozytorium powinno automatycznie zamykać lub aktualizować ticket klienta. Ta bidirectionalna synchronizacja jest fundamentem „link ticket–code” — wzorca, bez którego support i development żyją w równoległych, niesynchronizowanych światach. GitHub i GitLab mają natywne integracje z Jira (dwukierunkowa synchronizacja), Linear (GitHub native integration), Zammad (webhook → GitHub issue) i Zendesk (GitHub integration przez Zapier lub natywną). Konfiguracja tej integracji to projekt na kilka godzin — i jest warta każdej minuty, bo eliminuje „a już poprawione?” i „kiedy wchodzi fix?” z maili do PM-a.
SLA per klient — konfiguracja i egzekucja
Software house obsługuje klientów z różnymi umowami SLA — jeden ma support 8×5, drugi 24/7, trzeci „best effort bez gwarantowanych czasów”. System ticketowy musi odzwierciedlać te różnice: dla każdego klienta lub grupy klientów inny czas reakcji i rozwiązania per priorytet, inny calendar (godziny robocze vs 24/7), inne eskalacje. Zendesk i Freshdesk mają rozbudowane moduły SLA z automatycznym tagowaniem naruszeń i raportowaniem. Zammad ma podstawowe SLA. GLPI ma moduł SLA, ale konfiguracja jest mniej intuicyjna. Przy wyborze systemu — jeśli masz zróżnicowane umowy SLA — sprawdź głębokość modułu SLA jako kryterium decyzji.
Egzekucja SLA to nie tylko „system śledzi czas” — to też procesy wewnętrzne. Kto jest on-call? Kto eskaluje przy naruszeniu? Kto informuje klienta o opóźnieniu? Bez tych procesów system ticketowy z SLA to tylko dashboard pokazujący, jak bardzo jesteś spóźniony. Procedury on-call i eskalacji dla agencji IT to temat, który omawialiśmy szczegółowo przy temacie monitoringu i SLA — ale zasady są identyczne: jasne role, jasne progi, jasna komunikacja z klientem.
Rekomendacja: stack dla małej i średniej agencji IT
Dla agencji 5–25 osób z 10–30 klientami aktywnych umów serwisowych: Linear lub GitHub Issues do zarządzania projektami i taskami deweloperskimi, Freshdesk (Growth, ~15 USD/agent) lub Zammad (open source, on-premise) do supportu klienta z widokiem klienta i SLA, integracja między nimi przez Zapier lub webhook, Slack lub Teams do komunikacji wewnętrznej. Łączny koszt dla 5 agentów supportu: 75–150 USD/miesiąc (SaaS) lub jednorazowo ~5 000–10 000 zł wdrożenie + 50 USD/miesiąc hosting (open source). Dla agencji, które obsługują klientów z umowami SLA, ROI z dobrego systemu ticketowego to nie opcja — to warunek skalowalności bez chaosu.
