Servisní eskalace · týmová práce

Daktela × Freelo:
eskalovaný ticket jako úkol pro realizační tým

Podpora řeší tickety v Daktele, ale vybrané technické případy předává týmu ve Freelu přepisem?

Prověříme, zda lze po interním potvrzení eskalace předat jen potřebné údaje do jediného úkolu v určeném projektu. Neúplné zadání má skončit jako dohledatelná výjimka, ne ztracený nebo duplicitní úkol. Nejde o hotový konektor.

Popsat eskalaci ticketu

Posuzovaný tok

Vybraný ticket v Daktele

↓

Potvrzení eskalace · rozsah údajů · duplicity

↓

Jeden úkol ve Freelu / výjimka

Ne každý ticket patří realizačnímu týmu

Běžná komunikace zůstává v Daktele. Smysl má oddělit až případ, který podpora vědomě předá k technické práci. Samotná změna ticketu ještě není schválením ani zadáním úkolu.

Jasný okamžik předání

Určíme, kdo potvrzuje eskalaci a jak poznat, že aktualizace ticketu není jen další odpovědí zákazníkovi.

Minimum kontextu

Řešitel potřebuje ID ticketu a schválený stručný popis, ne nekontrolovanou kopii komunikace a osobních údajů.

Jeden úkol, ne série kopií

Opakovaná událost nesmí vytvořit další úkol; chybějící podklady mají být viditelné pro člověka.

Nejdřív prověříme jednodušší cestu

Daktela nabízí pravidla Events s HTTP akcemi; Freelo popisuje tvorbu úkolů přes API i automatizační nástroje. Pokud postačí konfigurace události nebo Make či n8n, není důvod začínat zakázkovým vývojem.

Jak je označená a potvrzená eskalace v konkrétní Daktele
Kdo může číst ticket a vytvořit úkol v určeném projektu Freelo
Jak se určí cílový projekt a odpovědný řešitel
Jak se chrání zákaznické údaje a rozhodují neúplné případy

Co by jeden vymezený tok dělal

Až po ověření pravidel, dostupných polí a oprávnění navrhneme, zda a jak aktualizovaný ticket předat. Nejde o automatické kopírování všech ticketů ani o řízení zákaznického SLA.

Potvrzená eskalace

Spouštěčem je vybraná aktualizace ticketu se zvlášť potvrzeným pravidlem eskalace, nikoli každá změna jeho stavu.

Omezené údaje

Předat lze jen schválený stručný popis, ID ticketu, prioritu a případný termín. Přílohy ani celý obsah komunikace do návrhu nepatří.

Určený projekt

Před vznikem úkolu musí být jasné, do kterého projektu a seznamu úkolů patří a zda už k ticketu úkol neexistuje.

Výjimka pro člověka

Neschválený nebo neúplný případ se předá k rozhodnutí. U opakované události se zabrání novému úkolu; postup při změně původního úkolu se musí určit zvlášť.

Časté otázky

Stačí nastavení Daktely nebo Make/n8n?

Možná ano. Nejdřív porovnáme stávající pravidla a nástroje s požadovaným schválením, mapováním projektu, deduplikací a řešením chyb. Vlastní řešení doporučíme jen pro konkrétní nesplněnou potřebu.

Pošle se do Freela celý ticket včetně příloh?

Ne v tomto návrhu. Rozsah se omezí na nutné schválené údaje, aby se zbytečně nekopírovala zákaznická komunikace nebo citlivé přílohy.

Synchronizují se stavy a SLA zpět do Daktely?

Ne. Popisujeme jednosměrné předání vybrané eskalace do úkolu; zpětná synchronizace, přílohy ani pravidla SLA nejsou součástí navrženého toku.

Je propojení hotové a kolik stojí?

Nejde o hotový konektor. Cenu lze určit až po ověření konkrétního ticketu, přístupů, schvalovacího pravidla, cílového projektu, testování a odpovědnosti za výjimky.

Související, ale jiný proces

Eskalace není fakturace ani nový projekt

Daktela × Fakturoid řeší předání fakturovatelného ticketu do dokladu. Pipedrive × Freelo naopak vytváří projekt z vyhrané zakázky, ne úkol ze servisní eskalace.

Daktela × Fakturoid →Pipedrive × Freelo →

Předáváte složitější servisní tickety řešitelům ručně?

Popište jediný typ eskalace, kdo ji potvrzuje a co musí řešitel vědět. Posoudíme, zda stačí současné nastavení, nebo dává smysl kontrolovaný tok.