Integracja z Jira wchodzi w Wasz workflow, nie obok niego
Jira zespołu technicznego to nie lista zadań, tylko schemat typów zgłoszeń, workflow z warunkami przejść i ekrany, na których część pól jest wymagana. Spinamy ją z CRM, obsługą klienta, repozytorium kodu i hurtownią tak, żeby automat szedł tą samą drogą co człowiek. Zgłoszenie od klienta dostaje powiązanie z zadaniem technicznym, a raport powstaje z zapytania JQL, nie z eksportu do arkusza.
- 2 do 6 tygodniod warsztatu do spiętej Jiry, zależnie od tego, ile projektów i ile workflow wchodzi w zakres
- 14 dniod warsztatu do pierwszej automatyzacji działającej na Waszym projekcie w Jirze
- 5 do 10 sekundtyle zajmuje BOND-owi odpowiedź na pytanie o stan zgłoszeń, bez otwierania tablicy
Problem
Dlaczego automat wywala się na zmianie statusu w Jirze?
Umowa jest podpisana, ktoś ręcznie zakłada epik w Jirze i przekleja do niego termin, wartość kontraktu i nazwę firmy z CRM. Zgłoszenie o błędzie przychodzi mailem do obsługi, ktoś opisuje je własnymi słowami jako nowe zadanie, i od tej pory ta sama sprawa żyje w dwóch miejscach. Klient pyta, kiedy poprawka wejdzie, a odpowiedź wymaga zajrzenia na tablicę zespołu, na listę wydań i w historię repozytorium.
Do tego dochodzi coś, czego nie widać z zewnątrz. Jira zespołu, który pracuje w niej od trzech lat, ma własny schemat typów zgłoszeń, workflow z kilkunastoma statusami, warunki przejść, walidatory i ekrany z polami wymaganymi. Człowiek radzi sobie z tym odruchowo, bo formularz mu podpowiada, czego brakuje. Scenariusz automatyzacji, który dostał polecenie „przenieś zgłoszenie do testów”, tej podpowiedzi nie ma.
Warstwa techniczna decyduje tu o całym harmonogramie. Dokumentacja Jira Cloud REST API v3 opisuje to wprost: statusu zgłoszenia nie da się ustawić z zewnątrz, można wyłącznie wywołać przejście, a jeśli przejście ma ekran, w tym samym wywołaniu trzeba podać pola z tego ekranu. Brakuje jednego pola wymaganego i API odmawia. Dlatego integracja z Jirą zaczyna się od odczytania listy przejść i pól dla konkretnego typu zgłoszenia, a nie od pisania scenariusza.
- Ten sam błąd żyje jako zgłoszenie od klienta i jako osobne zadanie zespołu
- Project manager przekleja z CRM termin, wartość kontraktu i nazwę firmy do nowego epiku
- Klient dowiaduje się o wydaniu poprawki wtedy, gdy sam zapyta
- Raport dla zarządu powstaje z eksportu do arkusza, raz w miesiącu
- Scenariusz automatyzacji przewraca się na polu wymaganym, o którym nikt mu nie powiedział
- Nikt nie wie, ile godzin pochłonął projekt, dopóki nie zamknie się miesiąc
Dlaczego teraz
Co się zmieniło, że nie trzeba przebudowywać projektów w Jirze?
Konfigurację Jiry da się dziś odczytać, zamiast ją zgadywać. Przez API pobieramy typy zgłoszeń dostępne w projekcie, listę przejść dla konkretnego zgłoszenia razem z polami wymaganymi na ekranie przejścia oraz schemat uprawnień, który mówi, co wolno użytkownikowi integracyjnemu. Zmiany odbieramy jako zdarzenia z webhooka, więc automat rusza w sekundę po tym, jak ktoś przeciągnie kartę na tablicy, a nie przy najbliższym odpytaniu.
Druga zmiana dotyczy tego, gdzie mieszka logika. Automatyzacja wbudowana w Jirę jest najlepszym miejscem na reguły dotyczące samej Jiry: podzadanie po zmianie statusu, przypisanie właściciela, komentarz przy przejściu. Kiedy reguła musi zapytać CRM o wartość umowy, system fakturowy o status płatności albo dopisać wiersz do hurtowni, logika idzie do n8n albo Make, a Jira zostaje miejscem zapisu wyniku. Warstwę techniczną opisujemy osobno na stronie o integracji przez API.
Trzecia zmiana jest nudna i najczęściej pomijana: uprawnienia. Jira rozdaje dostęp schematami przypisanymi do projektu, więc to samo przejście bywa dostępne dla jednej roli i zamknięte dla innej. Integracja pracuje jako osobny użytkownik z uprawnieniami zawężonymi do projektów w zakresie, nie na koncie administratora, bo tak było szybciej przy uruchamianiu. Dzięki temu w historii zgłoszenia widać, co zmienił człowiek, a co automat.
Czwarta rzecz to agent AI. JQL odpowie na każde pytanie o zgłoszenia, ale trzeba je najpierw napisać, a składni nie zna ani zarząd, ani obsługa klienta. BOND, nasz firmowy agent AI, zamienia pytanie zadane zwykłym zdaniem na zapytanie do Jiry i odpowiada w 5 do 10 sekund. „Które zgłoszenia od klientów czekają dłużej niż 5 dni” pyta wtedy osoba, która tablicy zespołu nigdy nie otwierała.
Co się zmienia
Co dostajecie ze spiętej Jiry?
Automat przechodzi workflow tak samo jak człowiek
Przed każdą zmianą statusu integracja pyta Jirę o dostępne przejścia dla tego konkretnego zgłoszenia i o pola wymagane na ekranie przejścia. Jeśli pola brakuje, uzupełnia je z systemu źródłowego albo zostawia zgłoszenie na miejscu z komentarzem, zamiast milczeć.
Lista przejść i pól wymaganych odczytana przez API przed pierwszym zapisem, dla każdego typu zgłoszenia osobno
Zgłoszenie biznesowe połączone z technicznym
Wygrana szansa w CRM zakłada epik z terminem, wartością kontraktu i nazwą klienta w polach, które u Was już istnieją. Zamknięcie epiku wraca do CRM jako zmiana etapu projektu, więc handlowiec nie pyta zespołu o status.
Powiązanie działa w dwie strony: identyfikator zgłoszenia zapisany w CRM, numer transakcji zapisany w Jirze
Zgłoszenie od klienta trafia do zespołu, który je naprawi
Jira Service Management jest osobnym światem: klient pisze przez portal albo mailem, zgłoszenie ląduje w kolejce z własnym typem wniosku i licznikiem SLA. Potwierdzony błąd dostaje powiązane zadanie w projekcie zespołu technicznego, a jego zamknięcie wraca do klienta jako odpowiedź w tym samym wątku.
Jedno zgłoszenie od klienta, jedno zadanie techniczne, powiązanie między nimi zamiast dwóch opisów tej samej sprawy
Raport bez budowania raportu
Zapytanie JQL jest przepisem na zestawienie: zgłoszenia po projekcie, typie, osobie, etykiecie, wersji i czasie w statusie. Wynik idzie tam, gdzie ktoś go czyta, czyli na Slacka w poniedziałek rano, do Google Sheets albo co dobę do BigQuery.
To samo zapytanie JQL zasila wiadomość na Slacku i tabelę w hurtowni, bez ręcznego eksportu
Widać, co weszło w wydanie i kiedy
Zgłoszenia spięte z repozytorium kodu i przypisane do wersji pokazują, która poprawka jest już wydana, a która czeka. Po wydaniu klient dostaje wiadomość z listą zamkniętych zgłoszeń, bez pisania jej ręcznie.
Lista wydania złożona z pola wersji w Jirze i powiązanych zmian w repozytorium
Godziny z Jiry zamienione na rentowność projektu
Zalogowany czas pobieramy co dobę do hurtowni i zestawiamy ze stawką z CRM oraz z fakturami. Kierownik widzi, który projekt zjada więcej godzin, niż zostało w budżecie, w tym samym tygodniu, a nie po zamknięciu miesiąca.
Czas per zgłoszenie i per sprint w BigQuery, obok wartości kontraktu z CRM
A u Ciebie
Co, jeśli nasza Jira wygląda inaczej?
Cztery zdania, które słyszymy najczęściej przy Jirze, i to, co na nie odpowiadamy.
Pod nimi systemy, z którymi spinamy Jirę najczęściej. Jeśli czegoś na liście nie ma, pytanie jest jedno: czy ma API albo webhooki.
Nasz workflow ma czternaście statusów i nikt go nie rusza.
I nie ruszymy. Integracja czyta workflow taki, jaki jest, razem z warunkami i walidatorami przejść. Jeśli w trakcie warsztatu okaże się, że dwa statusy znaczą u Was to samo albo że jedno przejście jest zablokowane dla wszystkich poza jedną osobą, mówimy to i zostawiamy decyzję Wam.
Mamy projekty zarządzane przez zespół, nie przez firmę.
To ważna różnica i pytamy o nią na starcie. W projekcie zarządzanym przez zespół typy zgłoszeń, workflow i pola są lokalne, więc to, co zbudujemy dla jednego projektu, nie przenosi się na kolejny automatycznie. W projekcie zarządzanym przez firmę schematy są wspólne, więc jedna zmiana dotyka wszystkich projektów, które ten schemat używają. Przy raportowaniu przez całą firmę drugi model jest wygodniejszy i tak Wam powiemy.
Jira jest dla developerów, obsługa klienta siedzi w skrzynce.
Wtedy najpierw pytamy, ile zgłoszeń od klientów przechodzi w miesiącu, i czy ktoś dziś potrafi powiedzieć, ile z nich czeka dłużej niż tydzień. Jeśli odpowiedź brzmi „nie wiem”, sensowne jest Jira Service Management jako osobny projekt z portalem i kolejkami, spięty ze zgłoszeniami technicznymi. Jeśli zgłoszeń jest kilka na tydzień, mówimy, że skrzynka wystarczy.
Chcemy AI, które samo zamyka zgłoszenia.
Nie robimy tego i mówimy dlaczego. Agent AI odpowiada na pytania o stan zgłoszeń, przygotowuje komentarz i proponuje przejście, ale zamknięcie zostawia człowiekowi, bo zamknięte zgłoszenie jest deklaracją wobec klienta. Automatycznie zamykamy tylko to, co ma jednoznaczną regułę, na przykład duplikat rozpoznany po identyfikatorze.
- Atlassian
- Jira Software, Jira Service Management, Confluence, Bitbucket
- CRM i sprzedaż
- HubSpot, Pipedrive, Salesforce, LiveSpace
- Praca zespołu
- Slack, Microsoft 365, Google Workspace, Notion, ClickUp, Asana
- Repozytorium kodu i wydania
- Bitbucket, GitHub, GitLab
- Dane, raporty i faktury
- BigQuery, Google Sheets, bazy SQL, Fakturownia, Comarch Optima
- Warstwa automatyzacji
- n8n, Make, Zapier, własne integracje przez API
Konfiguracja Jiry, z którą musi się liczyć każda integracja
To są rzeczy, które odczytujemy przed napisaniem pierwszej linii scenariusza. Każda z nich potrafi zatrzymać automat, który wygląda na poprawny.
| Element konfiguracji | Co z tego wynika dla automatu | Skąd to bierzemy |
|---|---|---|
| Schemat typów zgłoszeń | które typy są w projekcie i jakich pól wymaga każdy z nich | odczyt metadanych projektu przez API |
| Workflow i przejścia | statusu nie da się ustawić, można tylko wywołać przejście | lista przejść dla konkretnego zgłoszenia |
| Warunki i walidatory przejścia | przejście może być zablokowane dla użytkownika integracyjnego | próba przejścia na projekcie testowym |
| Ekran przejścia z polami wymaganymi | brak jednego pola oznacza odmowę zapisu | pola pobrane razem z listą przejść |
| Projekt zarządzany przez zespół albo przez firmę | czy schematy są lokalne, czy wspólne dla firmy | ustawienia projektu |
| Schemat uprawnień | kto może komentować, przenosić i zamykać zgłoszenia | schemat przypisany do projektu |
| Wersje i wydania | co weszło w wydanie i kiedy powiadomić klienta | pole wersji plus zmiany w repozytorium |
Przy pierwszym wdrożeniu bierzemy zwykle jeden projekt i jeden workflow. Kolejne dokładamy dopiero wtedy, gdy pierwszy działa na produkcji.
Jak to robimy
Pięć kroków od ręcznego przeklejania do spiętej Jiry
Każdy krok kończy się czymś, co możesz ocenić, zanim zdecydujesz o następnym.
Warsztat
Rozkładamy drogę zgłoszenia: skąd przychodzi, kto je zakłada, przez jakie statusy przechodzi i gdzie ktoś przekleja dane ręcznie. Osobno bierzemy zgłoszenia od klientów, bo to inny proces niż praca zespołu technicznego. Sprawdzamy, które projekty są zarządzane przez zespół, a które przez firmę.
Odczyt konfiguracji
Pobieramy przez API typy zgłoszeń, workflow, przejścia razem z polami wymaganymi, schemat uprawnień i listę pól własnych. To jest moment, w którym wychodzą pola wymagane, o których nikt już nie pamiętał, i przejścia dostępne wyłącznie dla jednej roli.
Projekt integracji
Ustalamy, co jest miejscem zapisu dla każdego pola: Jira, CRM albo system fakturowy. Wybieramy narzędzie: automatyzacja wbudowana w Jirę do reguł wewnątrz Jiry, n8n albo Make do wszystkiego, co wychodzi poza nią. Zakładamy osobnego użytkownika integracyjnego z uprawnieniami zawężonymi do projektów w zakresie.
Wdrożenie na projekcie testowym
Scenariusze uruchamiamy na kopii Waszego projektu, na prawdziwych zgłoszeniach z ostatnich tygodni. Sprawdzamy przypadki, które psują automaty: zgłoszenie bez wypełnionego pola wymaganego, przejście zablokowane warunkiem, duplikat i zgłoszenie zamknięte ręcznie w trakcie.
Produkcja i pomiar
Przełączamy z monitoringiem błędów i zostawiamy dokumentację, w której widać, co się dzieje przy każdym zdarzeniu. Po 30 i po 90 dniach patrzymy na liczby: ile zgłoszeń powstaje bez człowieka, ile odmów zwróciło API i ile zgłoszeń od klientów czeka dłużej niż SLA.
Przed i po
Jak zmienia się tydzień kierownika projektu
Przedtem
- Rano zakłada epiki dla umów podpisanych w poprzednim tygodniu
- Szuka, czy zgłoszenie od klienta ma już swoje zadanie u zespołu
- Buduje raport dla zarządu z eksportu do arkusza
- Pisze klientowi listę poprawek z wydania, przeglądając zgłoszenie po zgłoszeniu
Po zmianie
- Epik istnieje z terminem i wartością kontraktu w chwili zamknięcia transakcji w CRM
- Zgłoszenie od klienta ma powiązane zadanie techniczne i widoczny status
- Zestawienie z JQL czeka na Slacku w poniedziałek rano
- Wiadomość o wydaniu wychodzi z listy zgłoszeń przypisanych do wersji
Pierwsze zgłoszenia zakładane bez człowieka widać w dniu przełączenia. Liczbę odmów z API i czas obsługi zgłoszeń od klientów oceniamy po 30 dniach.
Dla osoby, która to zamawia
Co z tego ma dyrektor operacyjny
Pytanie „na czym stoi projekt klienta X” przestaje wymagać obchodzenia zespołu, bo odpowiedź jest w jednym miejscu i wynika ze statusów, które i tak są ustawiane. Zamiast ufać deklaracji z przeglądu tygodnia, patrzysz na czas, jaki zgłoszenia spędzają w każdym statusie.
Druga rzecz waży więcej przy rozmowie z zarządem. Godziny z Jiry zestawione z wartością kontraktu pokazują, który projekt jest rentowny, a który dowozimy z ambicji. To argument w rozmowie o cenniku i o obsadzie, którego dziś nie masz, bo dane siedzą w dwóch systemach naraz.
- Droga zgłoszenia spisana i taka sama dla całego zespołu, niezależna od jednej osoby
- Zgłoszenia od klientów w kolejce z licznikiem SLA, a nie w prywatnej skrzynce
- Wdrożenie na kopii projektu, więc produkcja pracuje do końca testów
- Rentowność projektu widoczna w tym samym tygodniu, nie po zamknięciu miesiąca
Ile to kosztuje
Warsztat ma cenę jawną, integracja wycenę po nim
Warsztat procesowy kosztuje 2500 zł netto za tydzień. Przy Jirze wystarcza zwykle jeden do dwóch tygodni, bo do drogi zgłoszenia dochodzi jeszcze mapa pól i uprawnień. Integrację wyceniamy po warsztacie, gdy wiadomo, ile projektów wchodzi w zakres, ile workflow trzeba obsłużyć i czy w grę wchodzi Jira Service Management.
Licencje Atlassian płacicie Atlassianowi, a koszt działania scenariuszy dostawcy narzędzia albo nikomu, jeśli n8n stoi na Waszej infrastrukturze. Bez naszej prowizji i bez marży na cudzych fakturach.
Warsztat procesowy
2500 zł netto
za tydzień, przy Jirze zwykle jeden do dwóch
Zamknięta całość. Kończy się spisaną drogą zgłoszenia, mapą pól i planem, który Wasz zespół może zrealizować bez nas.
- Mapa drogi zgłoszenia od klienta i od zespołu, z miejscami ręcznego przeklejania
- Spis typów zgłoszeń, przejść i pól wymaganych, które wchodzą w zakres
- Ustalenie, co jest miejscem zapisu dla każdego pola: Jira, CRM czy faktury
- Rekomendacja narzędzia: automatyzacja w Jirze, n8n, Make albo API
- Lista pól wymaganych i warunków przejść, które zablokują automat
- Wskazanie, czego u Was nie warto automatyzować i dlaczego
- Najczęściej wybierany
Warsztat i integracja Jiry
Wycena po warsztacie
zakres zależy od liczby projektów i workflow
Najczęściej wybierany wariant. Działająca integracja w 2 do 6 tygodni od warsztatu, przetestowana na kopii Waszego projektu.
- Wszystko z warsztatu
- Scenariusze w n8n, Make albo przez API, spięte z CRM i hurtownią
- Obsługa przejść i pól wymaganych zamiast prób ustawiania statusu
- Zgłoszenia od klientów z Jira Service Management powiązane z zadaniami technicznymi
- Zestawienia z JQL na Slacka, do Google Sheets albo do BigQuery
- Dokumentacja i szkolenie zespołu z samodzielnej zmiany reguł
Jira i agent AI
Wycena po warsztacie
dla firm, w których o status pytają codziennie osoby spoza zespołu
Wszystko z integracji plus BOND, firmowy agent AI, który odpowiada na pytania o zgłoszenia zwykłym zdaniem.
- Wszystko z integracji Jiry
- Agent AI czytający z Jiry, CRM i hurtowni, odpowiedź w 5 do 10 sekund
- Alerty o zgłoszeniach przekraczających SLA i o projektach po budżecie godzin
- Dostęp dla obsługi klienta i dla zarządu, bez znajomości JQL
Warsztat kończy się dokumentem, który obroni się bez nas: mapą drogi zgłoszenia, spisem pól i planem wdrożenia. Jeśli okaże się, że Jira jest za dużym narzędziem na Wasz zespół, bo nie ma wydań, nie ma zgłoszeń od klientów i nie ma potrzeby zapisu, kto co zmienił, mówimy to na warsztacie i pokazujemy prostszą drogę. Sprawa kończy się wtedy na warsztacie, a nie na integracji, której nie potrzebujecie.
Najczęstsze pytania
Czym jest integracja z Jira?
To spięcie Jiry z systemami, w których zaczyna się i kończy praca zespołu: CRM, obsługą klienta, repozytorium kodu, hurtownią danych i fakturami. Zgłoszenia powstają z danych, które już gdzieś są, przechodzą przez Wasz workflow bez ręcznego przeklejania, a zmiany wracają do systemu źródłowego. Człowiek zostaje przy decyzjach, a nie przy przepisywaniu terminów i nazw firm.
Ile trwa wdrożenie integracji z Jirą?
Tydzień do dwóch warsztatu i 2 do 6 tygodni wdrożenia, z testami na kopii Waszego projektu. Pierwsza automatyzacja działa zwykle 14 dni po warsztacie. Termin zależy głównie od liczby workflow i od tego, czy w zakres wchodzą zgłoszenia od klientów, bo Jira Service Management to osobny proces z własnymi typami wniosków i licznikami SLA.
Dlaczego automat nie może po prostu zmienić statusu zgłoszenia?
Bo Jira nie pozwala ustawić statusu z zewnątrz. Status zmienia się wyłącznie przez wywołanie przejścia, a przejście może mieć warunek, walidator i ekran z polami wymaganymi. Automat, który nie poda pola wymaganego, dostaje odmowę, i to jest najczęstsza przyczyna scenariuszy, które działały na demie, a stanęły na produkcji. Dlatego przed każdą zmianą pytamy Jirę o dostępne przejścia i o ich pola.
Czym różni się projekt zarządzany przez zespół od zarządzanego przez firmę?
W projekcie zarządzanym przez zespół konfigurację trzyma sam zespół i jest ona lokalna: typy zgłoszeń, workflow i pola nie są wspólne z innymi projektami. W projekcie zarządzanym przez firmę te same schematy obsługują wiele projektów, więc jedna zmiana dotyka ich wszystkich. Dla integracji różnica jest praktyczna: w pierwszym modelu każdy projekt trzeba odczytać osobno, w drugim jedna mapa pól obsługuje całą firmę.
Integrujecie też Jira Service Management?
Tak i traktujemy go jako osobny świat, bo taki jest. Klient pisze przez portal albo mailem, zgłoszenie wpada do kolejki z typem wniosku i licznikiem SLA, a odpowiedź wraca do niego w tym samym wątku. Potwierdzony błąd dostaje powiązane zadanie w projekcie zespołu technicznego, więc jedna sprawa nie staje się dwoma niezależnymi opisami.
Jak zrobić raport z Jiry bez budowania dashboardu?
Zapytaniem JQL. Filtruje zgłoszenia po projekcie, typie, osobie, etykiecie, wersji i czasie w statusie, a wynik kierujemy tam, gdzie ktoś go przeczyta: wiadomość na Slacku w poniedziałek rano, arkusz w Google Sheets, tabela w BigQuery odświeżana co dobę. Zaletą JQL jest to, że zapytanie da się przeczytać i poprawić, a wykres na dashboardzie trzeba zbudować od nowa.
Czy integracja pokaże, co weszło w wydanie?
Tak, jeśli zgłoszenia mają przypisaną wersję i są spięte z repozytorium kodu. Wtedy lista wydania powstaje z pola wersji i z powiązanych zmian, a wiadomość do klienta wychodzi z tej listy, bez pisania jej ręcznie. To także jedyny sensowny sposób, żeby odpowiedzieć klientowi na pytanie, czy jego poprawka jest już na produkcji, czy dopiero czeka.
Kiedy firma nie potrzebuje Jiry?
Gdy zespół ma kilka osób, nie ma wydań ani środowisk, zgłoszeń od klientów jest kilka na tydzień i nikt nie potrzebuje zapisu, kto zmienił status i kiedy. Wtedy Jira wprowadza koszt konfiguracji bez korzyści, a lżejsze narzędzie do zadań wystarczy. Mówimy to na warsztacie, zamiast wyceniać integrację narzędzia, którego nie warto u Was utrzymywać.
Sprawdźmy, gdzie w Waszej Jirze ginie czas
Bezpłatna konsultacja trwa 30 minut. Opowiadasz, ile macie projektów, skąd przychodzą zgłoszenia i kto dziś przekleja dane między Jirą a CRM. Pokazujemy, co da się spiąć od razu, a co wymaga najpierw uporządkowania pól i uprawnień. Nie musisz na tym etapie udostępniać systemów.
Prowadzimy najwyżej dwa wdrożenia równocześnie, żeby przy każdym ktoś realnie siedział.
Umów bezpłatną konsultacjęPS. Jeśli w tym tygodniu ktoś u Was ręcznie zakładał zgłoszenie z danymi, które już były w CRM, to jest dokładnie ten problem. Integracja, która zna Wasze przejścia i pola wymagane, robi to sama i nie zostawia dwóch wersji tej samej sprawy. Od tego zaczyna się warsztat.