A probléma: operációs káosz 10+ projekt felett
Egy webfejlesztő ügynökség látszólag egyszerű üzleti modell: ajánlat, szerződés, fejlesztés, átadás, fizetés. Valójában minden aktív projekt egy önálló workflow, minden ügyfél egy önálló kommunikációs fonál, minden határidő egy jogi kötelezettség.
10–15 aktív projekt felett a hagyományos eszközök összeomlanak. Nem azért, mert rosszak. Hanem azért, mert nem erre tervezték őket.
A Compassnál pontosan ezt tapasztaltuk. Az összkép jó volt — de a részletek egyre nehezebben kezelhetők:
⏱
Anyagbekérési határidők
Ki küldött be anyagot, ki nem, hány napja késik? Ezt minden reggel kézzel kellett átnézni.
💳
Fizetési státuszok
Ki fizette ki az előleget, kinél van nyitott záró számla, kinél van késedelem? Emailből, táblázatból.
⚖️
Jogi eszkalációk
A befagyasztási határidő a szerződésben rögzített. De ki figyeli, hogy 60. nap mikor jön el?
📬
Ügyfélkommunikáció
Egy jogilag bizonyítható kommunikációs trail emailekből nem rekonstruálható.
🔄
Módosítási körök
Ingyenes vagy fizetős? Hány körön vagyunk? Ki jelezte vissza az igénylistát?
Mindez manuálisan kezelhető 5 projektig. 15 projekt felett ez egy napi 2-3 órás adminisztrációs teher — és ez csak a követés. A kommunikáció, a fizetések és a jogi védelem még hozzáadódik.
Miért nem elegendő egy Kanban board?
Trello, Notion, ClickUp, Asana — mindegyik kiváló task management eszköz. De a task management és a workflow orchestration különböző problémákat old meg.
TASK MANAGEMENT
- Ki mit csinál?
- Mikor kész?
- Mi van hátra?
WORKFLOW ORCHESTRATION
- Mi a jogi állapot?
- Mi a következő automatikus lépés?
- Mi a szerződéses kötelezettség?
- Mi bizonyítható auditálhatóan?
- Mikor kell automatikusan emailt küldeni?
Egy ügynökségi kontextusban, ahol minden projekt mögött szerződés, határidő és jogi kötelezettség van, task management eszköz nem elég. Workflow orchestration rendszer kell.
Architektúra döntések
A rendszer tervezésekor három alapelvet tartottunk szem előtt: auditálhatóság, automatizálhatóság, és skálázhatóság.
⚡
Event-Driven Architecture
Minden business action event-et ír a project_events táblába. Státuszváltás, email küldés, fájl feltöltés, fizetés rögzítése — mind audit eventként kerül rögzítésre actor, source, visibility és metadata mezőkkel.
Miért? Az event log az egyetlen forrása az igazságnak. Bármilyen jogi kérdés esetén visszajátszható, mi történt, mikor, ki kezdeményezte.
🎛
4 Független Státusz Dimenzió
project_phase (technikai állapot), payment_status (fizetési státusz), legal_status (jogi státusz), operational_status (operációs állapot) — mind egymástól FÜGGETLEN dimenzió.
Miért? Egy projekt lehet technikai szempontból kész, de jogi szempontból befagyasztva és fizetési szempontból késedelmes. Egyetlen státuszmező nem képes ezt ábrázolni.
🧩
Service Separation
Minden domain külön service-be kerül: projectEventService, projectPaymentService, projectRevisionService, projectMaterialService, projectHandoverService, projectFileService.
Miért? A page component nem tartalmaz üzleti logikát. Minden service egyetlen felelősséggel rendelkezik — ez tesztelhető, cserélhető és bővíthető marad.
🔄
Status Machine
A jogi és operációs státuszok nem szabad stringek. Validált state transitions, terminal states kezelése, és konzisztencia ellenőrzés a rendszer részeként fut.
Miért? Invalid state kombináció (pl. lezárt projekt + nyitott fizetés) detektálható és javítható — mielőtt jogi problémát okoz.
A 4 státusz dimenzió és az automation engine
Az automation engine naponta egyszer fut (reggel 6:00, Vercel Cron), és 5 szabály szerint dönt el minden aktív projektről.
4 FÜGGETLEN STÁTUSZ DIMENZIÓ
Projekt Fázis
project_phaseanyagbekérés_kiküldveügyfél_anyagaira_várfejlesztés_alattbelső_ellenőrzéselső_átadásügyfél_tesztelmódosítási_körkészre_jelentveátadvalezárva
Jogi Státusz
legal_statusrendbenügyfél_késikfizetési_késedelemmunka_felfüggesztvebefagyasztvajogi_behajtási_státusz
Fizetési Státusz
payment_statuselőleg_várvaelőleg_fizetveköztes_részlet_esedékeszáró_fizetés_várvateljesítve
Operációs Státusz
operational_statusaktívszünetellezárvaarchivált
5 AUTOMATION SZABÁLY
1
ruleMaterialDeadlineTrigger:Anyagbekérés 3+ napja lejárt
Akció:legal_status → ügyfél_késik + emlékeztető email
Frekvencia:3 naponta, max 30. napig
2
rulePaymentOverdueTrigger:Záró számla határideje lejárt
Akció:legal_status → fizetési_késedelem + felszólítás email
Frekvencia:1., 3., 7., 14. napon
3
rulePriceIncreaseWarningTrigger:ügyfél_késik + 30/45/55 nap stagnálás
Akció:Befagyasztási figyelmeztetés email
Frekvencia:30., 45., 55. napon
4
ruleAutoFreezeTrigger:ügyfél_késik + 60+ nap stagnálás
Akció:legal_status → befagyasztva + operational_status → szünetel
Frekvencia:Egyszer, 60. napon
5
ruleAutoApprovalTrigger:ügyfél_tesztel fázis + 3+ nap válasz nélkül
Akció:project_phase → készre_jelentve (szerződéses auto-elfogadás)
Frekvencia:Egyszer, 3. napon
Engineering deep-dive
📋
Event Sourcing
- Minden project_events rekord tartalmaz: event_type, title, actor, source, visibility, old_value, new_value, metadata
- A Kommunikáció tab csak az ügyfél felé releváns eventeket szűri (COMM_EVENT_TYPES whitelist)
- Az Audit log tab az összes eventet mutatja — jogi szempontból teljes trace
- Visszajátszható állapot: az event logból bármikor rekonstruálható, mi mikor történt
⏰
Deadline Engine
- buildDefaultDeadlines() — a kanonikus forrás: 3/30/60 napos szabályok
- calcOverdue() — minden deadline esetén kiszámolja a késedelmet napokban
- syncDeadlineOverdueStatus() — napi szinkronizáció: is_overdue, overdue_days frissítés
- Minden deadline típushoz auto_action_type mező — mi a következő automatikus lépés
🔒
Cron & Automation Deduplication
- wasActionDoneToday() — naponta max 1x ugyanaz az akció (dedup)
- cron_executions tábla — minden futás rögzítve: lock mechanizmus, duration, error count
- Duplicate run protection: 409 Conflict ha már van aktív futás
- Stale lock cleanup: 10 perces timeout után a stale lock timed_out státuszba kerül
📧
Email Orchestration
- Az email nem notification. Hanem jogi kommunikációs réteg.
- Minden email project_id-val rögzítve — az audit trailbe bekerül
- email_events tábla: template, recipient, status, retry_count, resend_id
- sendAutomationEmail() hibakezelés: email_send_failed project_event a failed küldésnél
Technical hardening: production-grade stabilizáció
Egy workflow orchestration rendszer production-grade szintje nem az alapfunkciókban mérhető — hanem abban, hogyan viselkedik edge case-ekben, hibák esetén és hosszú távon.
Error Handling Layer
- Minden automation szabály try/catch-ben fut — hiba esetén automation_failed project_event
- Email küldési hiba: email_send_failed project_event + retry_count növelése
- logAutomationFailedEvent() és logEmailSendFailedEvent() — typed wrappers
Reconciliation Engine
- 6 impossible-state szabály — detektálja a konzisztencia hibákat
- Auto-fix: befagyasztva + aktív → automatikusan szünetel
- Napi cron futtatja, minden issue state_reconciliation_executed eventet ír
Monitoring & Observability
- Ops Monitoring Dashboard: heartbeat, health scores, failed automations, stuck projects
- cron_reliability_7d %, email_delivery_rate % — rendszer egészség mérőszámok
- Dead-letter queue: emailek amelyek 3x retry után sem mentek ki
Data Lifecycle
- cron_executions: 90 napos retention — régebbi rekordok törlése
- Dismissed notifications: 30 napos retention
- system_errors: 60 napos retention
- A project_events és email_events SOHA nem törlődnek — audit szempontból
Key learnings
„A weboldal nem a termék. A működési rendszer a termék."Az ügynökség értéke nem a deliverable-ban van. Hanem abban a rendszerben, amellyel azt előállítja.
„Az email nem notification layer. Hanem jogi kommunikációs réteg."Minden kiküldött emlékeztető egy bizonyítható jogi lépés. Ha nincs rögzítve, nem történt meg.
„Ha nincs audit trail, nincs szerződéses bizonyíték."Egy ügyfél-vita esetén az az ügynökség nyer, amelyik bizonyítani tudja: mit küldött, mikor, ki fogadta.
„A deadline kezelés nem task management. Hanem jogi kötelezettség."A szerződéses határidők jogi kötelezettségek — nem teendőlista elemek. Ezt a rendszernek is tudnia kell.
„A hagyományos eszközök taskot trackelnek. Nekünk workflow-t kellett orchestrálni."Az üzleti komplexitáshoz igazított rendszer épül — nem az üzleti folyamatok alkalmazkodnak a tool limitációihoz.
ARCHITEKTÚRA ÖSSZEFOGLALÓ
Event-Driven ArchitectureWorkflow OrchestrationContract AutomationStatus MachineAudit TrailDeadline Engine