LISCO Discovery Playbook

Súčasť lisco-discovery skill | Verzia 0.1-draft | 2026-05-05

Status: KOSTRA. Obsah budovať iteratívne s Martinom.

Toto je interný manuál ako dodať Discovery fázu konzistentne, kvalitne a v rozumnej pracnosti. Pre KAŽDÚ sekciu definuje:

• Vstup — čo musíš mať pred sekciou (rozhovory, audit dáta, dokumenty)
• Cieľ — čo má sekcia v reporte dosiahnuť
• Postup — krok po kroku
• Tooling — aké nástroje / templates použiť
• Pracnosť — odhad hodín
• Anti-patterns — čomu sa vyhnúť
• Definition of done — kedy je sekcia hotová

01 — Úvodná prezentácia (zdarma)

Vstup: Klient nás kontaktoval cez LinkedIn / referencie / web. Pred prezentáciou si pozri jeho web a Finstat (revenue, počet zamestnancov, sektor).

Cieľ: Dvojstranný — odprezentovať LISCO a Discovery službu + pochopiť klienta a posúdiť prienik (služieb, finančný, osobný/komunikačný). Nie je to predaj implementácie — predávaš Discovery ako samostatnú službu.

Forma: osobne ak je to logisticky možné. Online ak nie. Telefón nie — potrebuješ zdielať deck. Dĺžka 30–60 min podľa klienta.

Agenda: sleduj štruktúru pitch decku (lisco_ai_services_v12.pptx).

⚠️ Slide 6 (use cases) musí byť segment-specific. Pre každý nový segment (účtovné, právne, atď.) treba pripraviť alternatívnu verziu.

Čo z hovoru musíš vedieť: segment + veľkosť tímu + kľúčové procesy, čo klienta frustruje (NIE čo si predstavuje pod AI), používaný SW, kto rozhoduje a kto platí, timeline, orientačný rozpočet.

Disqualification: žiadne tech kritériá. Jediný dôvod nepokračovať — klient pôsobí komunikačne / osobnostne toxicky. Discovery je intenzívna spolupráca, dôvera je podmienka.

Po hovore — follow-up balík: email s 4 prílohami:

1. Pitch deck (PDF)
2. Scope Sheet (DOCX, generovaný)
3. Light tech qualification dotazník (DOCX, generovaný) — gate pre schválenie scope
4. Voliteľne: ukážka Discovery Reportu

V emaile krátko: 1-vetný sumár čo si pochopil + popis Discovery scope + cena. Že tech qualification potvrdí priechodnosť pred schválením scope. Žiadny tlak.

Pracnosť: ~1.5–2.5 hod / klient (research + hovor + follow-up balík).

Anti-patterns

• ❌ "Ako by ste využili AI?" — klient nevie, my máme zistiť bolesti a rozhodnúť čo je AI-riešiteľné
• ❌ Diskvalifikovať na základe tech stacku — light qualification je na to gate
• ❌ Follow-up bez Scope Sheet a tech qualification — klient potrebuje konkrétny ďalší krok
• ❌ Cena implementácie v emaile — predávaš len Discovery
• ❌ Generický deck — slide 6 (use cases) musí matchovať segment, inak vyzerá copy-paste
• ❌ Sľubovať konkrétne čísla úspor pred Discovery
• ❌ Akceptácia Scope Sheet bez vyplneného tech qualification — bez go-potvrdenia od tech partnera nemáme istotu o priechodnosti

Definition of done

• Klient pozná LISCO, Discovery službu, cenový rámec
• Mám base facts (segment, bolesti, SW, decision maker, timeline, rozpočet)
• Posúdil som komunikačný/osobný fit
• Follow-up balík poslaný do 24–48 hod
• Klient vie že schválenie scope ide až po tech qualification

02 — Príprava Scope Sheet

Vstup: base facts z úvodnej prezentácie (segment, veľkosť, bolesti, SW, decision maker, timeline, rozpočet). Cieľ: poslať klientovi konkrétny návrh čo dostane v platenej Discovery — moduly, rozsah, cena. Deliverable: brand-konzistentný DOCX (Forest Premium V1.2), 1–2 strany. Šablóna a obsah dokumentu sú samostatný artifact mimo playbook.

⚠️ Bez akceptovaného Scope Sheet nezačíname Discovery. Mailová akceptácia stačí, žiadny podpis.

Schvaľovací proces — 2-stupňový s tech qualification gate

1. Email: pitch deck + Scope Sheet + light tech qualification dotazník
2. Klient vyplní tech qualification, pošle plain text odpoveď (~30 min IT)
3. Tech partner vyhodnotí: GO / RISKY / NO-GO
4. Komunikácia výsledku klientovi
5. Schválenie Scope Sheet (mail) → objednávka → Discovery začne kickoffom

Prečo 2-stupňový: klient nemá zaplatiť za Discovery ktorú nemôžeme dodať technicky. My nezačneme platenú prácu na neprechodnom projekte. Tech qualification je rýchly (~30 min IT), minimálny overhead.

Ak klient akceptuje hneď bez čakania na tech qualification: "Skvelé, len pre istotu doplňte ten technický dotazník — od neho závisí či vieme dodať všetko zo scope. Trvá ~30 min." Bez qualification nezačíname.

⚠️ Tech qualification platnosť kopíruje Scope Sheet — 1 mesiac.

Ako vyberať scope

Pool modulov je v assets/scope-modules.md. Pre prvých klientov vyber per klient (nie zo šablóny) podľa dvoch kritérií:

1. Pracnosť za nás — koľko hodín to reálne zaberie
2. Hodnota pre klienta — či to je dobrý deal

Cieľ: nájsť scope kde obe strany vidia zmysel. Po 3–5 projektoch sa formujú vzory per segment — vtedy doplň do assets/segments/[segment].md.

Pricing princíp

Cena Discovery vychádza z dvoch faktorov:

1. Aké komponenty dodávame — toto má najväčší vplyv. Komplexnosť implementácie sa premieta do toho ako hlboko musíme pre dane komponenty robiť architektúru a tech rozhodnutia v Discovery fáze.

   • Knowledge Base / RAG = najnáročnejší — vector DB výber, document chunking stratégia, retrieval design, evaluation metriky
   • AI agenti / autonómne workflows = vysoká komplexnosť — orchestration, error handling, human-in-loop design
   • Workflow automatizácia (Make / Power Automate) = stredná — integration mapping, prompt design
   • Custom integrácie / API napojenia = stredná
   • AI chatbot na hotovej KB = nízka (po dokončení KB)

2. Počet procesov v scope — sekundárny faktor. Každý ďalší proces pridáva mapovanie + scorecard + cost/benefit prácu (sekcie 05–06).

⚠️ Konkrétne čísla per komponent sa kalibrujú po prvých 2–3 projektoch a žijú v assets/scope-modules.md. Pri prvých klientoch radšej nadhodnoť o 30–40 % než podstrelíš.

⚠️ Pod €700 ide každý projekt do straty — administratíva + nahrávanie + Discovery prep stoja viac.

Anti-patterns

• ❌ Generic Scope Sheet bez referencie na ich biznis — vyzerá copy-paste
• ❌ Sľubovať konkrétne výsledky (úspora hodín, FTE, ROI) — patrí do reportu
• ❌ Zmluva s podpisom — overhead bez hodnoty
• ❌ Záväzky o konkrétnom tooling/architektúre — Discovery môže ukázať že iný stack je lepší
• ❌ Bez timeline platnosti — bez expirácie sa stratí akcia
• ❌ Cenovať podľa počtu procesov bez ohľadu na komponenty — KB workflow je rádovo zložitejší ako automatizačný workflow

Definition of done

• Komponenty + počet procesov definované, cena odvodená
• Scope Sheet obsahuje krátky kontext z úvodného hovoru (NIE generic)
• Light tech qualification dotazník priložený k emailu
• Klient vie že schválenie ide až po potvrdení priechodnosti
• Tech partner má heads-up že qualification ide klientovi

03 — Kickoff, zber dát a review

Vstup: Schválený Scope Sheet + identifikovaný SPOC na strane klienta (office manager / asistent vlastníka / niekto z prevádzky kto má autoritu posúvať veci interne). Bez SPOCa Discovery zlyhá.

Cieľ: zozbierať dosť kvantifikovaného materiálu na proces diagramy, scorecard, cost/benefit a architektúru — bez interview maratónu. Väčšinu zberu robí klient sám podľa idiot-proof playbooku.

Princíp: Discovery NIE je 5 oddelených interview s 5 rolami. Sú to 2 spoločné stretnutia + štruktúrovaný self-service zber medzi nimi + tech audit paralelne (bez meetingu) (sekcia 04).

Štruktúra: 4 fázy

Fáza 1 — Kickoff meeting (90–120 min)
   ↓
Fáza 2 — Klientsky self-service zber (bez meetingu, 1–2 týždne)
   ↑ paralelne ↓
Tech audit (sekcia 04)
   ↓
Fáza 3 — Follow-up review meeting (60–90 min)

Fáza 1 — Kickoff meeting

Účastníci: vlastník + SPOC + (voliteľne) 1 ďalší kľúčový procesný stakeholder. Z nás sólo. Tech partner nechodí — pre klienta zbytočné, jeho vstup je cenný neskôr mailom.

Forma: Online default (Teams / Meet). Osobne ak klient v dosahu — buduje vzťah. Hybridné nie.

Dĺžka: 90 min default, hard cap 120. Pod 90 min nestihneš odhaliť reálne pain pointy.

Hrubá štruktúra: otvorenie + agenda + GDPR consent na nahrávanie (5–10 min) → business kontext (20–25 min) → pain points + identifikácia 3–6 procesov (45–60 min, hlavná časť) → handover klientskeho playbooku live (10–15 min) → tech qualification follow-up info (5 min) → ďalšie kroky a deadline (5–10 min).

Pred meetingom: refresh base facts, pripravený draft klientsky playbook (finalizuje sa po identifikácii procesov), tech partner vie že po kickoffe spúšťa tech audit, Teams/Meet nahrávanie zapnuté.

Po meetingu: Whisper transkript do clients/[slug]/interviews/, sumár pain points + identifikovaných procesov do scope.json, finalizácia klientskeho playbooku a doručenie klientovi do 48 hod.

⚠️ Bez identifikovaných procesov z kickoffu nemá klientsky playbook obsah. Procesy sú output Fázy 1.

Fáza 2 — Klientsky self-service zber

Beh: 1–2 týždne. Klient si organizuje interne sám.

Klient dostane: finalizovaný klientsky playbook (DOCX) s formulármi pre každý identifikovaný proces. Musí byť idiot-proof — kde kliknúť, čo dodať, ako to má vyzerať, príklady. Cieľ: klient nestratí čas hádaním, my nestrácame čas spätnými otázkami.

Per proces klient dodá: krok-po-kroku popis (kto čo robí, v akom systéme), frekvencia + čas/iter + počet ľudí, vlastníctvo (vlastník / schvaľovateľ / vykonávateľ), pain vlastnými slovami, vzorky reálnych inputov a outputov (anonymizované ak treba), GDPR-citlivé dáta flag.

Plus globálne sekcie raz za firmu: org & roly, strategický kontext (rast, plánované zmeny), orientačný budget pre implementáciu (aby Discovery nevyústila do nereálnej roadmapy).

Náš support: email kanál pre otázky, krátky check-in po týždni. NIE robiť zber za nich — ak SPOC chce výhovorky, pripomeň deadline.

⚠️ Ak klient zlyháva s dodaním do 1.5× pôvodnej deadline → stop, eskalovať na vlastníka.

Fáza 3 — Follow-up review meeting

Účastníci: SPOC + (voliteľne) vlastník + procesní stakeholderi ktorých sa procesy najviac týkajú. Tech partner môže prísť ak sa rieši konkrétny tech blocker.

Forma: Online default. Dĺžka: 60–90 min.

Pred meetingom — naša príprava: prejsť celý klientsky playbook, AI batch generation per proces (sekcia 05) → diagramy + scorecard + pain pointy, identifikovať gapy a doplňujúce otázky, tech audit info od tech partnera (sekcia 04) zohľadnené.

Hrubá štruktúra meetingu: otvorenie + GDPR consent (5 min) → walkthrough proces diagramov (30–40 min, klient validuje per proces) → doplňujúce otázky a gapy (15–25 min) → otvorené otázky klienta (10 min) → ďalšie kroky a termín dodania reportu (5 min).

Po meetingu: transkript uložený, aktualizovať diagramy a scorecard podľa feedbacku, začať ostatné Discovery sekcie (cost/benefit, architektúra, roadmap).

Forma a nahrávanie (spoločné Fázy 1 a 3)

• Online default (Teams / Meet)
• Nahrávanie áno s explicit GDPR consent na začiatku
• Whisper transkript → markdown do clients/[slug]/interviews/
• Bez transkriptu uniká väčšina detailov

Pracnosť

⚠️ Orientačné — kalibrácia po prvých 2–3 projektoch. Pre default scope (3–4 procesy):

Pri zrelom klientskom playbooku (po 5+ projektoch) spadne 2–3 hod.

Anti-patterns

• ❌ 5 oddelených interview s 5 rolami — overhead bez hodnoty. Kickoff + SPOC + self-service playbook pokrýva 90 % potreby.
• ❌ Voľný formulár "popíšte vaše procesy" → vráti sa nepoužiteľný text alebo nič. Idiot-proof playbook s formulármi je nemenná požiadavka.
• ❌ Zbierať dáta za klienta. Ak začneš vyplňovať formuláre v ich mene, naberáš ich pracnosť na seba.
• ❌ Bez follow-up meetingu, len email s diagramami. Spoločný review je nevyhnutný — klient nepríde na chyby v emaile.
• ❌ Bez nahrávania. Strácaš detaily.
• ❌ Robiť proces diagramy live na meetingu. Nepôsobí profesionálne, klient sa frustruje. Diagramy ideme s draftom, klient validuje.
• ❌ Tech partner na kickoffe. Pre vlastníka nezaujímavý, kickoff je business meeting.
• ❌ Discovery bez SPOCa. Vlastník nemá čas na koordináciu.

Definition of done

• Kickoff odjazdený, transkript uložený
• Identifikovaných 3–6 procesov
• Klientsky playbook doručený klientovi do 48 hod
• Klient dodal vyplnený playbook + vzorky
• Tech audit ukončený (sekcia 04)
• Diagramy nakreslené a klientom validované na follow-upe
• Scorecard naplnený s validovanými údajmi
• Follow-up transkript uložený

04 — Tech audit

Vstup: odpovede z light tech qualification dotazníka (zo sekcie 02 schvaľovací proces). Plus prístup do clients/[slug]/scope.json a Scope Sheet pre kontext.

Cieľ: preložiť light qualification odpovede do technickej časti Discovery Reportu a doplniť konkrétne tech detaily ktoré light verzia nezachytila. Light je "dá sa to vôbec?" — sekcia 04 je "ako to konkrétne urobíme."

Princíp: light qualification nie je full audit — je to gate. Konkrétne tech detaily (edície, auth, API mechanics, infra) sa dopĺňajú cielene počas Discovery, nie cez druhý dotazník.

Owner: tech partner. Koordináciu klient/tech robí ten kto vedie projekt.

Fáza 1 — Gate vyhodnotenie (pred Discovery)

Kedy: po doručení odpovedí na light qualification, pred schválením Scope Sheet.

Tech partner prečíta odpovede, posúdi go / risky / no-go podľa matice v assets/tech-qualification-light.md. Ak risky, pomenuje konkrétne riziká (1–3 vety per riziko). Ak no-go, pomenuje blocker(s) a možné cesty redefinovania scope.

Time: 30–60 min. Nerobí sa nič ďalšie — žiadna tech-stack tabuľka, žiadne otázky klientovi. Len go/no-go check.

Fáza 2 — Interná kompozícia (počas Discovery)

Kedy: paralelne s Fázou 2 sekcie 03 (klient self-service zber). Tech partner pripravuje materiál pre Discovery Report bez interakcie s klientom.

Produkty:

(a) Tech-stack tabuľka per kľúčový systém — vendor + verzia/edícia + hosting + účel + integration path + auth + obmedzenia.

(b) Integration matrix — ktorý workflow potrebuje ktorú integráciu + zložitosť (Nízka / Stredná / Vysoká).

(c) Blockers / risks explicitne pomenované pre report (systémy bez API, plánované migrácie, compliance constraints).

(d) Default architektúra recommendation pre tento konkrétny stack — výber workflow orchestrátora (Make / n8n / Power Automate), LLM (Claude / GPT), vector DB (Qdrant / pgvector), embeddings, document storage. Detail justifikácie ide do sekcie 07.

Time: 1.5–2.5 hod.

Fáza 3 — Doplnenie gapov (počas Discovery)

Kedy: paralelne s Fázou 2 alebo medzi Fázou 2 a Fázou 3 sekcie 03. Forma: batch email s 5–10 cielenými otázkami pre IT klienta. Pri netriviálnom stacku 15–30 min call.

6 tém ktoré light nepokrýva:

1. Konkrétne edície a verzie — Pohoda E1 / M / Komplet, M365 Business / E3 / E5, Money S3 / S4 / S5. Light gate len zistil že systém existuje.

2. API mechanics — protokol (REST/SOAP/GraphQL), auth schéma (OAuth2 / API key / Basic), service account, scopes, rate limits, sandbox. Light pýta len áno/nie/neviem.

3. Network a infra constraints — VPN, IP whitelist, firewall pravidlá, on-prem servery (OS/RAM/disk), outbound internet z on-prem. Kritické pre deployment.

4. Volume a metrics — reálny objem dokumentov / mesiac, veľkosť databázy, peak vs priemer. Rozhoduje pricing infraštruktúry.

5. Existujúce automatizácie detail — pri "Power Automate áno": aký flow, kto vlastní, sú tam credentials, vie ich obnoviť?

6. Plánované zmeny detail — pri "migrácia do Money v Q4": kedy presne, paralelný beh alebo cut-over, kto vedie?

Time: 30–90 min.

Fáza 4 — Prístupy a vzorky (počas Discovery)

Akcia od klienta. Pýtame: read-only prístup do M365/SharePoint, vzorový export faktúry (PDF + štruktúrovaný), 3–5 vzorových dokumentov pre KB, príklady reálnych workflow outputov, priamy kontakt na IT.

⚠️ Read-only prístupy s GDPR opatrnosťou — dokumentovať aký prístup, na ako dlho, kto ho má. clients/[slug]/access-log.md.

Time: 30–60 min naša + 1–3 dni klient zbiera.

Eskalačná logika nálezov

⚠️ Major findings nikdy do reportu bez predchádzajúceho oznámenia klientovi.

Pracnosť (tech partner)

Anti-patterns

• ❌ Druhý "full audit" dotazník nad light qualification. Klient už vyplnil. Detaily doplňme cielene.
• ❌ Odhadovať detaily ktoré tech partner nevie namiesto opýtania.
• ❌ Doplňujúce otázky po jednej, deň po dni. Batch ich do 5–10 otázok v jednom emaile.
• ❌ Major findings do reportu bez priebežnej komunikácie s klientom.
• ❌ Exotický stack ("self-hosted Llama 70B") pre 5-osobnú firmu. Default stack je default. Odchýlka len ak je dôvod.
• ❌ Findings nepísať priebežne — pri architektúre v sekcii 07 sa potom hľadá v hlave.
• ❌ Read-only prístupy bez GDPR opatrnosti.

Definition of done

• Gate vyhodnotené (go/risky/no-go), sumár doručený
• Tech-stack tabuľka finalizovaná s konkrétnymi edíciami, auth, network
• Integration matrix per workflow vyplnená
• Blockers / risks pomenované
• Default architektúra recommendation pripravená (vstup pre sekciu 07)
• Klient informovaný o major findings ešte pred reportom
• GDPR access log aktualizovaný

05 — Mapovanie procesu + scorecard

Vstup: vyplnený klientsky playbook z Fázy 2 sekcie 03 + tech-stack info zo sekcie 04 + Scope Sheet.

Cieľ: pre každý proces vytvoriť 3 deliverables ktoré tvoria základ Discovery Reportu a vstup pre Cost/Benefit (sekcia 06):

1. Proces diagram — vizuálny swimlane podľa rolí, brand-konzistentný (Forest Premium V1.2)
2. Workflow scorecard — frekvencia, čas/iter, AI Potential, Business Impact, priorita
3. Pain points — explicitne pomenované, vlastnými slovami klienta + naše pozorovania

Princíp: AI vyrobí všetko v jednom batchi. Človek je reviewer, nie producer. Validácia naživo s klientom ostáva na follow-up meetingu.

Postup

1. Review klientskych odpovedí (~15–30 min za klienta) — prečítať playbook responses zo všetkých procesov, identifikovať gapy a nejasnosti.

2. Follow-up otázky (15–30 min, ak treba) — email alebo súčasť follow-up meetingu. Cieľ idiot-proof playbooku zo sekcie 03 je tomuto kroku predísť.

3. AI batch generation per proces (10–20 min per proces) — jeden LLM run produkuje JSON popis + SVG diagram + scorecard + pain pointy. Promptový template v assets/process-mapping-prompt.md (TODO build). Validácia: brand compliance diagramu (max 1–2 pain pointy, brand farby), tech consistency (systémy v JSON sedia s tech-stack info), scorecard hodnoty obhájiteľné. Ak zlé → re-prompt s konkrétnymi výhradami. Diagram exportovať cez cairosvg na PNG.

4. Review post-AI (10–15 min per proces) — kontrola: JSON sedí s tým čo klient povedal (žiadne LLM-vymyslené kroky), diagram má správnu granularitu (5–10 krokov), scorecard hodnoty obhájiteľné (AI Potential nie všade Vysoký), pain pointy konkrétne (citácia + impact, nie generic). Drobné opraviť ručne, štrukturálne re-promptnúť.

5. Klient validácia na follow-up meetingu (5–10 min per proces) — ukázať diagram, prejsť scorecard, prečítať pain pointy. Klient potvrdí alebo opraví. Re-generate ak významné zmeny.

Pracnosť

⚠️ Orientačné, kalibrácia po prvých 1–2 projektoch. Pre default scope 3–4 procesy:

Pre 3–4 procesy spolu: ~1.5–2.5 hod sólo + 30–80 min tech partner.

⚠️ Prvé 1–2 projekty budú dlhšie, kým sa promptový template skalibruje.

Kritériá scoring

AI Automation Potential

⚠️ AI Potential je technologicky-agnostický odhad. Tech feasibility s konkrétnym stackom klienta je separátna otázka (sekcia 04).

Business Impact

Priorita — odvodená

Tech feasibility filter: ak tech partner označil workflow ako major blocker (sekcia 04), priorita ide na ★ alebo mimo scope.

Anti-patterns

• ❌ Písať JSON popis ručne. AI to vie. Človek je reviewer.
• ❌ Generic AI buzzwords v scorecard ("ticket triage") nesúvisiace s biznisom klienta. Terminológia musí matchovať to ako klient hovorí. Pre property management nie "ticket flow" ale "evidencia servisných požiadaviek".
• ❌ Spustiť AI generation bez follow-up otázok keď klient odpovedal nedostatočne — AI vyplní gapy halucináciami.
• ❌ Príliš komplikované diagramy s 20+ krokmi. Granularita: 5–10 hlavných krokov per swimlane.
• ❌ Pain pointy len "manuálne robia" bez konkrétnej bolesti. Vždy: summary + evidence (citácia) + impact (merateľný).
• ❌ Skackať klient validáciu — chyby ostanú v reporte.
• ❌ Posunúť AI výstup do reportu bez review.
• ❌ Priorita ★★★ pre viac ako polovicu workflowov. Force ranking.
• ❌ Re-promptnúť donekonečna. Po 2–3 pokusoch refactor prompt template.

Definition of done

Per proces:

• AI batch generation prebehla, výstupy v clients/[slug]/processes/[proces-id]/
• Review po AI urobený, drobnosti opravené alebo re-promptované
• Diagram klientom validovaný na follow-up meetingu
• Scorecard kompletný (6 polí + odôvodnenia)
• Pain pointy curatedné (summary + evidence + impact)

Celkovo:

• Klientsky playbook reviewovaný, follow-up doriešený
• Všetky procesy zo scope spracované cez AI batch
• Priorita rozdeľuje workflows do tier (žiadne "všetko ★★★")
• Tech feasibility filter aplikovaný
• Vstup pre Cost/Benefit pripravený

06 — Cost / Benefit analýza

Vstup: scorecard zo sekcie 05 (frekvencia, čas/iter, AI Potential per workflow) + default architektúra zo sekcie 04 (operating costs).

Cieľ: kvantifikovať úsporu per workflow + celkovú úsporu + payback voči implementačnej cene. Plus kvalitatívne prínosy.

Princíp: AI to dopočíta z inputov (rovnako ako sekcia 05). Človek validuje hodinové náklady a kontextové predpoklady.

Postup

1. Hodinový náklad per rola — pýtaj klienta priamo na úvodnom hovore alebo kickoffe ("aký je orientačne plne zaťažený náklad účtovníčky / právnika / asistenta?"). Ak nepovie, použi segment average (nižšie).

2. Per workflow výpočet úspory:

   úspora_hod/mes = frekvencia_iterácie/mes × čas_iter × % automatizácie
   úspora_€/mes = úspora_hod × hodinový_náklad
   

   Default % automatizácie podľa AI Potential zo sekcie 05:

   • Vysoký → 75 %
   • Stredný → 50 %
   • Nízky → 20 %

3. Ongoing operating costs — mesačná réžia AI riešenia. Odpočítať od hrubej úspory.

   • LLM API (Claude / GPT) — odhad podľa volume per workflow
   • Vector DB (Qdrant cloud / pgvector self-host)
   • Workflow orchestration (Make subscription / n8n self-host)
   • Embeddings, transkripcia, OCR — per usage
   • Maintenance (náš čas) — typicky 5–15 % implementačnej ceny / rok

4. Net mesačná úspora = hrubá úspora − ongoing operating costs.

5. Payback výpočet — implementačnú cenu máme zo sekcie 08 (roadmap), takže ROI rátame v sekcii 06:

   payback_mesiace = (implementačná_cena + 12_mes_operating_costs) ÷ net_mesačná_úspora
   

   Per fáza (nie len celkovo) — Fáza 1 sa môže navrátiť za 4 mes, Fáza 2 za 8 mes. Klient potrebuje vedieť priority order.

6. Kvalitatívne prínosy — vždy zapísať, samostatne od eur. Typové:

   • Zníženie chybovosti (auditovateľnosť AI rozhodnutí)
   • Rýchlosť odozvy klientom
   • Škálovateľnosť bez nárastu tímu
   • Wellbeing — menej repetitívnej práce
   • Knowledge retention (KB znižuje riziko z odchodov)

   ⚠️ Nikdy nemiešať kvalitatívne prínosy s eurovou ROI kalkuláciou. Sú samostatná hodnota.

Segment averages — hodinový náklad (orientačné, ak klient nepovie)

⚠️ Slovenské náklady, plne zaťažený (mzda + odvody + overhead). Kalibrácia po projektoch.

⚠️ Hodinový náklad nie je čistá mzda — typicky 1.4× brutto mzda (odvody + overhead + benefits).

Pracnosť

Anti-patterns

• ❌ Sľubovať 100 % úsporu. Aj pri "Vysoký" AI Potential ostáva ~25 % (edge cases, ľudský review, exception handling).
• ❌ Miešať kvalitatívne prínosy s ROI číslami. "Ušetríte €18 000/rok + lepšiu morálku" je dvojaký jazyk.
• ❌ Skryť ongoing operating costs. Klient bude prekvapený keď príde prvá faktúra za Claude API.
• ❌ Payback bez kontextu adopcie. "Za 6 mes sa to vráti" platí len ak ľudia AI naozaj použijú. Spomenúť v reporte ako predpoklad.
• ❌ "Až 80 % úspora" — copywriting bullshit. Použi konkrétne číslo s odôvodnením.
• ❌ Hodinový náklad = mzda. Klient povie "účtovníčka stojí €1500" → musíš to zaťažiť odvodami a overhead-om (1.4×).
• ❌ Ignorovať maintenance náklady. Po nasadení sa veci kazí, ladia, rozširujú. Default 5–15 % implementačnej ceny / rok.
• ❌ Optimistic scenario only. Pre väčšie projekty dať aj konzervatívny variant (50 % úspora namiesto 75 %).

Definition of done

Per workflow:

• Úspora hod/mes vypočítaná
• Úspora €/mes vypočítaná
• % automatizácie použitý (default alebo upravený) zaznamenaný

Celkovo:

• Hodinové náklady per rola zaznamenané (klient alebo segment)
• Hrubá mesačná úspora spočítaná naprieč workflows
• Ongoing operating costs odhadnuté (LLM, vector DB, orchestration, maintenance)
• Net mesačná úspora vyrátaná
• Payback v mesiacoch per fáza (vstup zo sekcie 08)
• Kvalitatívne prínosy zapísané (samostatne od eur)
• Vstup pre sekcie 07 (architektúra) a 08 (roadmap) pripravený

07 — AI Solution architektúra

Vstup: tech-stack tabuľka + integration matrix + default architektúra recommendation zo sekcie 04 + workflows s prioritami zo sekcie 05 + operating costs zo sekcie 06.

Cieľ: finalizovať AI Solution architektúru pre Discovery Report — komponenty, dátové flow, integrácie, vendor selections + business justifikácia voči procesným cieľom.

Princíp: Architektúra má 2 úrovne:

1. Vysoký pohľad (1 diagram) — komponenty + dátový flow pre vlastníka / exec stakeholderov. Cieľ: vlastník vie ukázať konateľovi alebo predstavenstvu čo sa bude diať.
2. Per-component detail — pre každý komponent: čo robí, aké dáta, ako sa integruje, koľko stojí, alternatívy. Pre IT klienta a vendora pri implementácii.

⚠️ NIE pseudokód ani setup steps — to je predmet implementácie, nie Discovery.

Owner split

• Tech partner vlastní WHAT — komponenty, integrations, data flows, vendor selections. Vytvorí, navrhne, vysvetlí dôvody.
• Martin vlastní WHY — prečo tieto rozhodnutia odpovedajú klientskym cieľom z sekcie 05. Posúva na klienta s justifikáciou.

Postup

1. Tech partner pripraví architektúru draft (z default stacku):

   • Vysoký pohľad diagram (komponenty, šípky, integrácie)
   • Per workflow: ktoré komponenty potrebuje a ako sa zapájajú do data flow
   • Per komponent: čo robí, dáta in/out, integrácie, náklady, alternatívy zvážené
   • Vysvetlenie dôvodov vendor selections — prečo Claude vs GPT, prečo Make vs n8n, atď.

2. Martin reviewuje pre business consistency:

   • Architektúra rieši konkrétne pain pointy identifikované v sekcii 05?
   • Náklady sú v rozumnom pomere k benefitom (sekcia 06)?
   • Zložitosť je primeraná veľkosti firmy (5-osobná firma nepotrebuje enterprise stack)?
   • Sú tam komponenty ktoré klient nepochopí bez vysvetlenia?

3. Doladenie naživo — ak Martin má výhrady, tech partner upraví WHAT, Martin doplní WHY texty pre klienta.

4. Finalizácia pre Discovery Report:

   • Diagram (Forest Premium V1.2 brand, generovaný cez AI rovnako ako proces diagramy v sekcii 05)
   • Per-component texty (tech detail + business justifikácia)
   • Operating costs súhlasné so sekciou 06

5. Validácia s klientom v rámci follow-up meetingu (sekcia 03) alebo pri prezentácii reportu. Klient nemusí rozumieť každému tech detailu, ale musí vedieť: aké systémy budeme používať, kde budú dáta, čo to mesačne stojí.

Komponenty — typové vrstvy

⚠️ Konkrétny default stack vlastní tech partner a žije v assets/default-architecture.md (TODO build). Tu sú len typové vrstvy.

Default principles

• Buy over build — managed services kde je to ekonomické (Make over n8n self-host pre 5-osobnú firmu)
• Consolidate vendors — radšej jeden vendor pre LLM + embeddings než 3 rôzne API ak sa dá
• Match klientovo prostredie — M365 → Power Automate v hre; Google Workspace → Apps Script v hre
• EU data residency ak klient žiada (väčšina SK SMB áno)
• Cost-aware — nepoužívať Opus tam kde Sonnet stačí
• No vendor lock-in pre dáta — KB embedding sa dá regenerovať, automation flows sú dokumentované

Per-component output (čo ide do reportu)

Pre každý komponent:

• Názov + verzia + vendor
• Čo robí (1–2 vety, business jazyk)
• Vstupy / výstupy (aké dáta)
• Integrácie (s ktorými systémami klienta)
• Náklady — jednorazové implementačné + mesačné operating (zo sekcie 06)
• Alternatívy zvážené + prečo neboli vybrané
• Vendor dependency rating (low / med / high) — čo sa stane ak vendor zmení podmienky

Pracnosť

⚠️ Pri prvých klientoch budú odchýlky od defaultu časté → vyššia pracnosť. Po stabilizácii defaultu klesne na ~3–5 hod.

Anti-patterns

• ❌ Exotický stack pre malú firmu — self-host Llama 70B pre 5 ľudí. Default stack je default.
• ❌ Premature optimization — rieš škálovanie pre milión documents pri 1 000.
• ❌ Vendor lock-in bez varovania — klient nevie že OpenAI ich drží. Vždy explicit dependency rating.
• ❌ Skryté operating costs — všetky API costs do reportu, nielen LLM. Vector DB, orchestration, embeddings, transkripcia.
• ❌ Ignorovať klientovo existujúce IT — ak majú M365, neradia Google Workspace ako default.
• ❌ Bez business justifikácie komponentov — klient pozerá tech slang, neuverí. Každý komponent musí mať WHY.
• ❌ Príliš veľa komponentov pre jednoduchý use case — minimum viable architecture.
• ❌ Architektúra bez consideration pre maintenance — kto bude robiť updates, monitoring, debugging? V reporte spomenúť.
• ❌ WHAT bez WHY — tech partner odovzdá komponenty, Martin to neprerozprava klientovi a klient nerozumie čo platí.

Definition of done

• Default stack vybraný (alebo customizácia odôvodnená)
• Vysoký pohľad diagram pripravený (Forest Premium V1.2)
• Per komponent: WHAT (tech detail) + WHY (business justifikácia)
• Integration matrix per workflow vyplnená a súhlasná so sekciou 04
• Operating costs súhlasné so sekciou 06
• Vendor dependencies označené (low/med/high)
• Klient bude rozumieť architektúre na úrovni "aké systémy, čo stojí, kde sú dáta"
• Vstup pre sekciu 08 (roadmap) pripravený — vie sa čo sa stavia v ktorej fáze

08 — Implementačná roadmapa

Vstup: workflows so prioritami zo sekcie 05 (★★★/★★/★) + cost/benefit per workflow zo sekcie 06 + architektúra zo sekcie 07 (komponenty + dependencies) + klientov orientačný budget z kickoffu.

Cieľ: rozdeliť implementáciu do fáz, každú naceniť, dať orientačný timeline. Roadmapa je vstupom pre payback (sekcia 06) a implementačnú ponuku (sekcia 09).

Princíp: Foundation first. Niektoré komponenty sú enabling (KB / vector DB / orchestrator base setup), iné dependent (chatbot vyžaduje KB, automatizácia vyžaduje API access). Roadmapa rešpektuje technické závislosti + business priority.

Postup

1. Identifikácia foundation komponentov zo sekcie 07:

   • KB / Vector DB (ak sú v scope)
   • Workflow orchestrator base setup (Make / n8n / Power Automate)
   • Authentication / API access setup
   • Document storage konsolidácia (ak treba)

2. Fázovanie workflows podľa priority + dependencies:

   • Fáza 1 = foundation + ★★★ workflows ktoré z foundation priamo profitujú
   • Fáza 2 = ★★ workflows + rozšírenie funkcionality
   • Fáza 3 = ★ workflows alebo advanced features (AI agenti, expansion)

   ⚠️ Workflow s major tech blockerom (zo sekcie 04) ide do mimo scope alebo je odložený do "Fáza 0 — modernizácia" (klient si rieši pred implementáciou).

3. Per fáza nacenenie:

   • Implementačná cena (jednorazová) — komponent build + integration + testing + deployment + workshop
   • Operating costs (mesačné, zo sekcie 06)
   • Timeline (orientačný v týždňoch)
   • Payback per fáza (cross-reference do sekcie 06)

4. Validácia voči klientovmu budgetu:

   • Ak klient v kickoff povedal €5k a Fáza 1 vychádza na €8k → reagovať pred reportom
   • Možnosti: zúžiť scope Fázy 1, posunúť časť do Fázy 2, alebo flagovať klientovi že budget je nereálny pre to čo chce
   • Nikdy nedonáša report kde Fáza 1 prevyšuje deklarovaný budget bez vysvetlenia

5. Vendor plánovanie per fáza:

   • Kto implementuje? (LISCO, klient IT, externý dodávateľ)
   • Pri väčších fázach môže byť mix — LISCO drives, klient IT poskytuje access
   • Default: LISCO implementuje cez tech partnera

Default fázovanie patterns

Orientačné rozsahy cien per fáza (SMB, 5–15 ľudí)

⚠️ Toto sú orientačné rozsahy, kalibrácia po prvých 2–3 projektoch.

Timeline:

• Fáza 1 (foundation + 1–2 workflows): 4–8 týždňov
• Fáza 2 (3–5 workflows): 4–6 týždňov
• Fáza 3 (rozšírenie): 4–6 týždňov

Pracnosť

Anti-patterns

• ❌ Roadmapa pre celý ekosystém naraz ako jednu fázu — klient sa zľakne celkovej ceny, neimplementuje nič.
• ❌ Ignorovať technické závislosti — chatbot pred KB, automatizácia bez API access. Foundation first vždy.
• ❌ Veľké fázy (10+ týždňov) — riziko, klient stratí trpezlivosť, my horíme. Ideálne 4–8 týždňov per fáza s viditeľným outputom na konci.
• ❌ Cena bez payback kontextu — klient pozerá €8k bez vedomia že sa to vráti za 6 mesiacov. Vždy spárovať s payback.
• ❌ Fixné termíny bez bufferu — klient nedodá X včas → meškame a vyzerá to ako náš problém. Vždy +20 % buffer.
• ❌ Roadmapa bez vendor rozhodnutí — kto implementuje? Treba mať jasno pred reportom.
• ❌ Ignorovať klientov budget z kickoffu — ak povedal €5k, neprezentujte mu €15k roadmapu bez varovania.
• ❌ Maintenance schovaná vo fáze "Workshop" — vždy explicit ako optional retainer (sekcia 09).
• ❌ "Big bang" launch — všetko spustiť naraz. Pilot prvé, postupne rozšírenie. Klient sa potrebuje učiť používať AI postupne.
• ❌ Roadmapa bez "checkpoint" momentov — kde po Fáze 1 zhodnotíme či pokračovať. Klient musí mať možnosť stop bez sankcie.

Definition of done

• Foundation komponenty identifikované
• Workflows priradené do fáz podľa priority + dependencies
• Workflows s major blockermi explicitne mimo scope alebo do Fázy 0
• Per fáza: implementačná cena + mesačné operating costs + timeline + payback
• Validácia voči klientovmu budgetu, prípadné odchýlky flagované
• Vendor pre každú fázu definovaný
• Checkpoint momenty po každej fáze označené (klient môže pauznúť/zastaviť)
• Optional retainer / maintenance plán naskicovaný (vstup pre sekciu 09)
• Cross-reference do sekcie 06 (payback per fáza) hotová

09 — Handover a follow-up

Vstup: finalizovaný Discovery Report (DOCX + PDF) zo sekcií 04–08.

Cieľ: odovzdať report klientovi tak aby (a) rozumel čomu platil, (b) vedel sa rozhodnúť čo ďalej. Otvoriť cestu k implementácii bez tlaku.

Princíp: Discovery má samostatnú hodnotu. Ak klient neimplementuje s nami, report sa dá použiť aj pre iného dodávateľa — to je jeho právo. Naša úloha je report dobre odovzdať a ponúknuť ďalší krok ak klient pokračuje.

Postup

1. Doručenie reportu — hybrid forma:

   • PDF emailom 2–3 dni pred stretnutím (klient potrebuje čas na prečítanie a prípravu otázok)
   • Sprievodný email: krátky sumár čo report obsahuje + termín stretnutia + "v prílohe nájdete kompletný report, prejdeme spolu na našom stretnutí"

2. Prezentácia / diskusia naživo (60–90 min, online default):

   • Prejsť hlavné nálezy: identifikované procesy, scorecard, cost/benefit, architektúra, roadmap
   • Klient pýta otázky, my vysvetľujeme
   • Cieľ: klient rozumie každému rozhodnutiu, vie čo navrhujeme a prečo
   • NIE pitch implementácie — report sa odovzdáva, nepredáva sa ďalší krok

3. Klientov výber z roadmapy (na meetingu alebo po):

   • Klient povie ktoré fázy chce implementovať a v akom poradí
   • Možnosti: všetko, len Fáza 1 ako pilot, čas na rozhodnutie
   • Bez tlaku — klient môže potrebovať týždne na interné rozhodovanie

4. Implementačná ponuka — pre vybrané fázy (ak klient pokračuje):

   • Samostatný dokument, generovaný ad-hoc po výbere klienta (nie automaticky pre celú roadmapu)
   • Scope vybraných fáz, timeline, cena (fixed alebo T&M), platobné podmienky
   • Optional retainer ako voľba (bod nižšie)

5. Optional retainer / maintenance:

   • V implementačnej ponuke ako voľba (klient áno/nie)
   • Default rozsah: X €/mes za Y hodín mesačne na monitoring, drobné úpravy, prompt tuning, AI ekosystém updates relevantné pre klienta
   • Vysvetliť hodnotu, nie predať lock-in: AI sa rýchlo mení, prompts treba ladiť, modely sa updatujú, integrácie sa kazia. Bez maintenance hrozí degradácia kvality v priebehu mesiacov.

6. Discovery uzavretie:

   • Report finálny, fakturujeme
   • Klientske dáta zostávajú v clients/[slug]/ (zápisy, transkripty, scope, processes)
   • GDPR access log uzavretý — read-only prístupy do klientskych systémov ukončené

Forma stretnutia

• Online default (Teams / Meet) — efektivita, automatické nahrávanie, klient nemusí cestovať
• Osobne ak je dôvod — väčší klient, blízka destinácia, formálne uzavretie projektu
• Nahrávanie áno s explicit consent — klient si neraz pamätá zlé veci, transkript pomáha pri implementačnej ponuke
• Účastníci klienta: vlastník + SPOC + (voliteľne) decision makeri ktorí budú schvaľovať implementáciu

Pracnosť

Anti-patterns

• ❌ Posielať report bez stretnutia — klient si neoznámkuje detaily, prepadne to. Stretnutie je súčasť hodnoty Discovery.
• ❌ Tlak na implementáciu na session — "kedy začneme?" zničí dôveru. Klient potrebuje čas na rozhodnutie.
• ❌ Implementačná ponuka pre celú roadmapu naraz — klient sa zľakne celkovej ceny. Per-fáza ponuka je psychologicky priateľnejšia.
• ❌ Default retainer bez vysvetlenia hodnoty — vyzerá to ako vendor lock-in. Vždy vysvetliť prečo (AI sa mení, modely updatujú, prompts treba ladiť).
• ❌ Ignorovať že klient nemusí pokračovať s nami — report je jeho a má hodnotu aj samostatne. Žiadne defenzívne vety typu "bez nás vám to neimplementuje nik."
• ❌ Bez follow-up komunikácie po stretnutí — klient potrebuje čas, my by sme si mali rezervovať priestor pre nadviazanie (krátky email po týždni "ak máte otázky").
• ❌ Discovery uzavrieť pred fakturáciou — fakturuj hneď po doručení reportu, nie po implementačnom rozhodnutí. Discovery je samostatná služba.

Definition of done

• Discovery Report PDF + sprievodný email odoslaný klientovi 2–3 dni pred session
• Stretnutie uskutočnené, transkript uložený v clients/[slug]/interviews/
• Klient si vybral fázy (alebo si dal čas — zaznamenať deadline pre check-in)
• Implementačná ponuka odoslaná pre vybrané fázy (ak klient pokračuje)
• Optional retainer ponúknutý ako voľba
• Discovery vyfakturovaná
• Klientske dáta uložené, GDPR access log uzavretý

Globálne pravidlá pre Discovery (TODO doplniť)

• Komunikácia s klientom — frekvencia, kanály, response time
• Zápisy z rozhovorov — kde žijú, kto má prístup
• Verzionovanie reportu — ako spravujeme draft → final
• Tracking času — ako vieš koľko si na projekte strávil

Pre AI agentov v budúcnosti — placeholder

Tento playbook je dizajnovaný tak, aby slúžil dvojako:

1. Teraz: human-readable manuál pre Martin + Boris pri reálnom dodávaní Discovery klientom
2. Neskôr: zdrojový dokument pre Borisa pri stavbe LISCO AI firmy — tímu role-based agentov, kde každý agent simuluje jednu pozíciu (PM, Solution Architect, Workflow Analyst, Tech Auditor, Document Composer, Account Manager, ...)

Plán: keď bude playbook celý hotový (sekcie 01–09 + globálne pravidlá), urobíme retrospektívnu analýzu:

• Aké roly by tvorili LISCO AI tím
• Koľko ich treba (minimum viable team vs. plný tím)
• Aké úlohy každá rola vlastní (z playbook sekcií)
• Aké interakcie medzi rolami — kto koho deleguje, kto eskaluje
• Aké rozhodnutia ostávajú človeku (Martin / Boris ako orchestrator / klient)
• Plus — kde je hranica medzi pomocným nástrojom (LLM asistujúci človeku) a autonómnym agentom (rola ktorá vlastní úlohu end-to-end)

Princípy ktoré platia naprieč playbookom pre dual-use design:

• Každý krok má označeného owner-a (Martin / Boris / Klient) — toto je ekvivalent "ktorá rola vlastní úlohu" pri budúcich agentoch
• Štruktúrované inputs / outputs — kde to dáva zmysel, sú definované JSON schemy alebo markdown templates (vstupy / výstupy medzi rolami)
• Decision criteria explicit — namiesto "Martinov úsudok" sú kritériá v tabuľkách s diskrétnymi hodnotami
• Validation merateľná — DoD per krok je zoznam konkrétnych zaškrtnutiek, nie pocitov
• Spoločné stretnutia zachované — klientske interakcie (kickoff, follow-up, handover) ostávajú human aj v plne automatizovanej verzii. Žiadny agent nehovorí s klientom za LISCO.

⚠️ Toto je forward-looking sekcia — implementácia agentov nie je v scope Discovery skillu v0.x. Je to design intent ktorý drží konzistentnosť pri písaní jednotlivých sekcií. Konkrétnu role-level analýzu urobíme po dokončení playbooku.

Changelog

• v0.13 (2026-05-05): Sekcia 08 (Implementačná roadmapa) napísaná naplno. Foundation first princíp — KB / orchestrator / API access ako enabling komponenty pred dependent workflows. Fázovanie podľa priority zo sekcie 05 (★★★ → Fáza 1, ★★ → Fáza 2, ★ → Fáza 3) plus tech dependencies. Workflows s major blockermi mimo scope alebo do "Fáza 0 — modernizácia". Per fáza: implementačná cena + operating costs + timeline + payback (cross-reference do sekcie 06). Validácia voči klientovmu budgetu z kickoffu. Default fázovanie patterns (KB-heavy / Automation-heavy / Mixed). Orientačné rozsahy cien per komponent (€3–8k foundation, €1–3k simple workflow, €3–8k complex RAG, €5–12k AI agent). Playbook sekcie 01–09 hotové.
• v0.12 (2026-05-05): Sekcia 09 (Handover a follow-up) napísaná naplno. Hybrid forma odovzdania reportu (PDF dopredu + stretnutie 60–90 min). Implementačná ponuka ad-hoc po klientovom výbere fáz, nie automaticky pre celú roadmapu. Optional retainer ako voľba v implementačnej ponuke. Discovery uzavretie po doručení reportu (fakturuje sa hneď, nie po implementačnom rozhodnutí). Sekcia 08 (Roadmap) ostáva otvorená — na rade ďalšia.
• v0.11 (2026-05-05): Sekcia 07 (AI Solution architektúra) napísaná naplno. 2-úrovňová štruktúra (vysoký pohľad diagram + per-component detail). Owner split — tech partner vlastní WHAT, ja vlastním WHY (justifikácia voči klientovi). Default principles (buy over build, consolidate vendors, match klientovo prostredie, EU data residency, cost-aware, no vendor lock-in pre dáta). Per-component output template pre report (8 polí vrátane vendor dependency rating). Konkrétny default stack ostáva v assets/default-architecture.md (TODO build, vlastní tech partner).
• v0.10 (2026-05-05): Sekcia 06 (Cost/Benefit analýza) napísaná naplno. Kalkulácia úspory per workflow s default % automatizácie (Vysoký 75 % / Stredný 50 % / Nízky 20 %), hodinové náklady (klient alebo segment fallback s orientačnými rozsahmi pre 8 rolí v SK), ongoing operating costs (LLM API, vector DB, maintenance), payback per fáza voči implementačnej cene zo sekcie 08, kvalitatívne prínosy samostatne od eur. AI batch generation rovnako ako sekcia 05.
• v0.9 (2026-05-05): Radikálne skrátenie sekcií 01–05.
• v0.8 (2026-05-05): Sekcia 05 prepísaná na realistickejšiu pracnosť. Pôvodný 5-krokový postup mal Martina písať JSON ručne (45 min) a robiť scorecard manuálne — overengineered. Nový postup: AI vyrobí všetko v jednom batchi (JSON + diagram + scorecard + pain pointy per proces), Martin je reviewer, nie producer. Pracnosť klesla z ~5–7 hod Martin na ~1.5–2.5 hod Martin + ~30–80 min Boris pre 3–4 procesy. Hlavná investícia presunutá do prompt engineeringu (assets/process-mapping-prompt.md).
• v0.7 (2026-05-05): "Pre AI agentov" sekcia refactor — z task-level na role-level placeholder pre LISCO AI firmu.
• v0.6 (2026-05-05): Sekcia 05 napísaná naplno (Mapovanie procesu + scorecard) s 5-krokovým postupom. (Nahradené v v0.8.)
• v0.5 (2026-05-05): Sekcia 04 prepísaná s jasnou 4-fázovou štruktúrou.
• v0.4 (2026-05-05): Sekcie 01 a 02 updatnuté o light tech qualification flow.
• v0.3 (2026-05-05): Sekcia 03 napísaná naplno — 4-fázový model (kickoff → klient self-service → follow-up review → tech audit paralelne). Nahrádza pôvodný plán 5 oddelených interview per rolu.
• v0.2 (2026-05-05): Sekcia 03 napísaná naplno — 4-fázový model (kickoff → klient self-service → follow-up review → tech audit paralelne). Nahrádza pôvodný plán 5 oddelených interview per rolu.
• v0.1 (2026-05-05): Kostra so 9 sekciami a otázkami pre Martina