KAMSY PortalRozhodovací mapa

Podklad pro Tomáše · srpen 2026

Co rozhodnout pro další etapu portálu

Portál už funguje. Tohle není seznam chyb ani slib, že musíme postavit všechno. Je to mapa patnácti rozhodnutí, která ovlivní bezpečnost, provoz i další rozpočet — včetně variant, doporučení a důvodu proč.

15otevřených rozhodnutí
4řešit jako první
4provozní pravidla
7až podle potřeby

Společný rámec

Čtyři zásady, které drží řešení pohromadě

Jedno místo pravdy

Freelo plánuje práci, Fakturoid fakturuje a portál drží zákazníky, docházku, dokumenty a servisní historii. Stejná agenda nemá žít ve dvou systémech.

Historii nepřepisovat

Vygenerovaná smlouva, protokol i provizní nárok jsou dobové záznamy. Oprava vytváří novou verzi, původní zůstává dohledatelný.

Nejmenší nutný přístup

Zákazník, partner, brigádník a technik vidí jen to, co potřebují. Citlivé operace zůstávají auditované a pod kontrolou administrátora.

Automatizovat až jasné pravidlo

Nejdřív si řekneme, kdo rozhoduje a co je správný výsledek. Teprve potom automatizujeme — jinak jen rychleji vyrábíme nepořádek.

Rozhodovací seznam

Patnáct témat, jedno po druhém

První čtyři body doporučujeme uzavřít nejdřív. Další lze naplánovat podle reálného provozu a rozpočtu.

01priorita

Automatická záloha mimo server

Nejdůležitější

Šifrovaná záloha vzniká 1. a 15. den v měsíci, ale kopie mimo server je zatím ruční.

Možnosti

  1. Nechat ruční stažení — nejlevnější, ale závislé na tom, že si někdo vzpomene.
  2. Automaticky kopírovat na Hetzner Storage Box v odděleném účtu.
  3. Automaticky kopírovat k jinému poskytovateli, například do Backblaze B2, aby porucha jednoho dodavatele nezasáhla obě kopie.

Doporučení

Po každé záloze automatický šifrovaný přenos do odděleného úložiště.

Nastavit retenční pravidlo, kontrolu úspěchu a pravidelný zkušební restore. Samotná záloha na stejném serveru neřeší ztrátu disku, účtu ani celého stroje.

RozhodnoutStorage Box, nebo jiný poskytovatel? Jak dlouho kopie držet a kdo dostane upozornění při chybě?
02priorita

Tomášův kvalifikovaný elektronický podpis

Bezpečnost

Tomáš certifikát má. Musíme ale určit, kde bude privátní klíč a kdo fyzicky potvrzuje každý podpis.

Možnosti

  1. Lokální podpis kartou/tokenem na Tomášově počítači — silná osobní kontrola, méně automatizace.
  2. Vzdálený kvalifikovaný podpis u kvalifikovaného poskytovatele — pohodlnější, ale závislý na jeho službě a cenách.
  3. Certifikát a PIN na webovém serveru — technicky snadné, ale neúměrně rizikové a nedoporučené.

Doporučení

Soukromý klíč a PIN nedávat přímo na server portálu.

Preferovat vzdálené kvalifikované podepisování nebo kontrolovaný lokální krok. Současně rozhodnout o časovém razítku, dlouhodobé ověřitelnosti a viditelné podobě podpisu v PDF.

RozhodnoutKdo je poskytovatel certifikátu, na čem dnes Tomáš podepisuje a musí podpis fungovat i z mobilu?
03priorita

Zapomenuté heslo

Přístupy

Administrátor už umí vytvořit jednorázový odkaz. Uživatel si o něj ale nemůže bezpečně požádat sám e-mailem.

Možnosti

  1. Ponechat pouze ruční obnovu administrátorem pro všechny role.
  2. Samoobslužný krátkodobý e-mailový odkaz jen pro zákazníky a partnery.
  3. Samoobsluha i pro zaměstnance — pohodlnější, ale citlivější kvůli interním přístupům a 2FA.

Doporučení

Samoobslužný reset nejdřív zákazníkům a partnerům.

Odpověď nesmí prozradit, zda účet existuje. Odkaz má být náhodný, jednorázový, krátce platný a po použití zneplatnit staré relace. Obnovu 2FA řešit odděleně.

RozhodnoutMají zaměstnanci dál volat administrátorovi, nebo chceme samoobsluhu také pro ně?
04priorita

Které další e-maily má portál posílat

Komunikace

SMTP funguje pro denní docházku. Každá další událost ale potřebuje jasného příjemce a pravidlo.

Možnosti

  1. Jen interní upozornění: údržba, chyba zálohy, čekající kontrola dokumentu.
  2. Účtové e-maily: pozvánka a obnova hesla.
  3. Zákaznické události: zveřejněný protokol, smlouva nebo servisní zásah.

Doporučení

Začít obnovou účtu a interními připomínkami údržby.

Zákaznické notifikace zapínat po jednotlivých typech, s náhledem textu a možností událost neposlat. Nezapínat vše najednou.

RozhodnoutKteré dvě zprávy mají největší praktickou hodnotu a z jaké adresy mají chodit?
05provoz

Freelo versus plánování v portálu

Proces

Potřebujeme zabránit tomu, aby technici měli dvě různá místa pro stejné úkoly a termíny.

Možnosti

  1. Freelo zůstane samostatné bez propojení — jednoduché, ale část údajů se přepisuje ručně.
  2. Jednosměrné propojení: portál založí úkol ve Freelu a sleduje jeho stav.
  3. Plná obousměrná synchronizace nebo vlastní plánovací modul v portálu — nejdražší a nejrizikovější na konflikty.

Doporučení

Freelo ponechat jako zdroj plánování a propojit ho úzce přes API/webhooky.

Portál zůstane zdrojem zákazníků, docházky a servisní historie. Začít jedním projektem, jedním seznamem a jasnou mapou stavů.

RozhodnoutKterý projekt a To-Do seznam ve Freelu použít, jaké jsou stavy a jak mapovat techniky?
06provoz

Servisní požadavky přijaté e-mailem

Proces

Speciální adresa může z e-mailu založit práci. Musíme ale vybrat, kde se nový požadavek nejdřív objeví.

Možnosti

  1. E-mail vytvoří rovnou servisní zásah u zákazníka — rychlé, ale před provedením by vznikala falešná historie.
  2. E-mail vytvoří úkol ve Freelu a po dokončení se výsledek propíše do servisní historie.
  3. E-mail vytvoří interní frontu požadavků v portálu — znamená stavět druhý task manager.

Doporučení

Nejdřív úkol ve Freelu, až dokončená práce do servisní historie.

Příchozí e-mail je požadavek, nikoli důkaz provedeného zásahu. Technik nebo administrátor musí potvrdit zákazníka a výsledek.

RozhodnoutJaká bude servisní adresa, kdo třídí nové zprávy a co se stane, když zákazníka nelze najít?
07provoz

Docházka a mzdová pravidla

Pravidla

Dnes se vyplněná cesta počítá do celku. Neplacená cesta po městě se nechává prázdná, takže se ztrácí provozní informace.

Možnosti

  1. Neplacenou cestu vůbec neevidovat — jednoduché, ale nelze měřit skutečný čas zakázky.
  2. U každé cesty evidovat „placená / neplacená“ a oba časy reportovat odděleně.
  3. Použít automatické pravidlo podle dopravy, místa nebo typu pracovníka — méně klikání, více výjimek.

Doporučení

Pokud docházka půjde do mezd, evidovat cestu vždy a označit, zda je placená.

Data se neztratí a mzdový součet zůstane správný. Zvlášť rozhodnout, zda dovolenou jen zapisujeme, nebo ji musí někdo schválit.

RozhodnoutKdy je cesta placená, kdo schvaluje výjimku a potřebuje dovolená schvalovací workflow?
08provoz

Pravidla provizí a historická data

Finance

Systém umí výchozí procenta i výjimky. Potřebuje ale jasný počáteční rok, stropy a pravidla pro staré Excel tabulky.

Možnosti

  1. Začít čistě rokem 2026 a starou historii ponechat v Excelu.
  2. Importovat jen nevyplacené staré nároky.
  3. Importovat celou historii — nejlepší přehled, ale nejvíce kontroly a čištění.

Doporučení

Výchozí pravidlo na obchodníka, výjimka na konkrétní smlouvu.

Jednorázová provize může mít strop, roční servisní provize upravený základ bez internetu a jiných průtokových nákladů. Historii importovat jen v rozsahu, který Tomáš dokáže odsouhlasit.

RozhodnoutZačíná kniha v roce 2026, nebo přeneseme starší roky? Jaké má každý obchodník procento a strop?
09později

Veřejný affiliate program

Odložit

Technicky lze otevřít registraci komukoli. Nejdřív ale musí být jasné daně, GDPR, duplicity a obrana proti spamu.

Možnosti

  1. Zůstat jen u pozvaných obchodních zástupců.
  2. Veřejný formulář bez účtu, každý tip ručně schválit.
  3. Plný veřejný affiliate účet s vyúčtováním a historií.

Doporučení

Odložit do schválení účetním a GDPR poradcem.

Nejtěžší část není formulář, ale právní základ pro předání kontaktu, výplata fyzickým osobám, vlastnictví duplicitního tipu a zneužití.

Rozhodnout pozdějiKdo může doporučovat, co přesně potvrzuje a jak se prokazuje první oprávněný tip?
10později

Zápis z portálu do Fakturoidu

Držet hranici

Fakturoid je dnes záměrně pouze ke čtení. Portál tedy nemůže omylem měnit faktury ani obchodní případy.

Možnosti

  1. Ponechat vše pouze ke čtení.
  2. Povolit jedinou úzce vymezenou operaci, například založení konceptu obchodního případu.
  3. Povolit obecný zápis faktur, kontaktů a stavů — největší riziko chyb a duplicit.

Doporučení

Ponechat read-only.

Pokud vznikne konkrétní případ s měřitelnou úsporou, navrhnout jej jako samostatný projekt s omezeným oprávněním, potvrzením a auditním logem.

Rozhodnout pozdějiKterý jediný ruční krok ve Fakturoidu dnes skutečně stojí tolik času, že se vyplatí ho automatizovat?
11později

Editace a verze smluv

Historie

Po vygenerování často zjistíme chybějící údaj. Oprava ale nesmí potichu změnit dokument, který už někdo kontroloval.

Možnosti

  1. Vygenerovat dokument jen jednou a chybu řešit úplně novou smlouvou.
  2. Otevřít vstupní data, opravit je a vytvořit novou číslovanou verzi.
  3. Přepisovat už vygenerované PDF — nejméně dohledatelné a nedoporučené.

Doporučení

Každá oprava vytvoří novou verzi a původní zůstane v auditu.

Šablona je znovupoužitelný výchozí obsah, ne již uzavřená smlouva. Publikovat lze pouze schválenou verzi.

Rozhodnout pozdějiMá být číslování „v1, v2“, nebo nové evidenční číslo? Kdo smí vytvořit a kdo schválit opravu?
12později

Co smí zadávat zákazník

Rozsah

Zákaznický portál může přijímat servisní požadavky, soubory nebo opravy kontaktu. Každý vstup ale potřebuje kontrolu.

Možnosti

  1. Ponechat zákazníka jen u čtení publikovaných dokumentů a GDPR deníku.
  2. Přidat přesně definovaný servisní požadavek s přílohami a stavem.
  3. Povolit obecné editace údajů a upload do zákaznické složky.

Doporučení

Přidávat úzké formuláře s administrátorskou kontrolou.

Zákazník nemá dostat obecný přístup k interním přílohám ani možnost přímo měnit hlavní zákaznický záznam.

Rozhodnout pozdějiJe první potřebou servisní požadavek, nahrání provozního deníku, nebo oprava kontaktu?
13později

Antivirová kontrola souborů

Před rozšířením uploadu

Současné typy se kontrolují podle skutečného obsahu, ale obecný antivirový engine v portálu není.

Možnosti

  1. Ponechat úzký seznam formátů a interní nahrávání.
  2. Přidat lokální skenování před uložením a soubory držet v karanténě do výsledku.
  3. Použít externí skenovací službu — snazší provoz, ale soubor opouští server a vzniká další zpracovatel.

Doporučení

Skenování přidat před Office, ZIP a širokým zákaznickým uploadem.

Dokud jsou typy omezené a upload pod kontrolou zaměstnanců, není to první priorita. Zálohy databází zůstávají admin-only.

Rozhodnout pozdějiOpravdu potřebujeme Office/ZIP od zákazníků, nebo stačí PDF a fotografie?
14později

Práce bez internetu / PWA

Podle reality

Offline režim by technikům pomohl ve sklepích a strojovnách, ale výrazně komplikuje šifrování, konflikty a mazání dat z telefonu.

Možnosti

  1. Zůstat online a používat serverové koncepty.
  2. Lehká instalovatelná PWA bez offline citlivých dat.
  3. Plný offline formulář se synchronizací a řešením konfliktů.

Doporučení

Stavět až po doložení skutečných výpadků v terénu.

Nejdřív několik týdnů sledovat, kolikrát technik nemohl zápis dokončit. Serverové šifrované koncepty jsou dnes bezpečnější a jednodušší.

Rozhodnout pozdějiKolikrát měsíčně technik reálně nemá data a kterou konkrétní činnost kvůli tomu nedokončí?
15později

Regenerace historických protokolů

Archiv

Staré PDF je dobový originál. Dnešní šablona může mít jiný vzhled, text i povinná pole.

Možnosti

  1. Archivované PDF považovat za jediný originál a už ho negenerovat.
  2. Z historických dat vytvořit novou revizi dnešní šablonou s jasným novým číslem.
  3. Udržovat všechny staré renderery a pokoušet se o pixelově stejný výstup.

Doporučení

Originál je archivované PDF; nový výstup je nová revize.

Rekonstrukce starých šablon je nákladná a křehká. Pokud je nutné starý dokument opravit, zachovat původní a vytvořit nový dohledatelný záznam.

Rozhodnout pozdějiExistuje konkrétní právní nebo provozní situace, kdy nestačí původní PDF a nová revize?

Navržený postup

Jedna krátká rozhodovací schůzka

Není nutné uzavřít všech patnáct bodů. Cílem je rozhodnout bezpečnostní základ a u ostatních vědomě říct „teď“, „později“, nebo „ne“.

00–15Zálohy a podpisVybrat směr, vlastníka a další ověřovací krok.
15–25Hesla a e-mailyUrčit první dvě automatické zprávy a komu chodí.
25–40Freelo, servis a docházkaPotvrdit zdroj pravdy a mzdová pravidla.
40–45Co odkládámeBody 9–15 označit podle reálné potřeby, bez vývoje „pro jistotu“.

Podklady

Pro ověření citlivých rozhodnutí