Hol kezdd: nem ott, ahol mindenki
Erre van a legjobb adat, és pont az intuíció ellen szól.
Egy 2025 első félévében készült vizsgálat — 52 szervezet strukturált interjúval, 153 vezető négy iparági konferencián, és több mint 300 nyilvánosan bejelentett kezdeményezés átnézése — azt találta, hogy míg a figyelem és a pénz nagy része az értékesítéshez és a marketinghez megy, a háttérfolyamatok automatizálása drámaibb és fenntarthatóbb megtérülést hozhat.
Konkrét, mért megtakarítások ugyaninnen:
| Terület | Megtakarítás |
|---|---|
| Kiszervezett ügyfélszolgálat és dokumentumfeldolgozás kiváltása | évi 2–10 millió dollár |
| Külső kreatív- és tartalomköltés | 30%-os csökkenés |
| Kiszervezett kockázatkezelés egy pénzügyi szolgáltatónál | évi 1 millió dollár |
A front office oldalán is voltak eredmények — 40%-kal gyorsabb lead-minősítés, 10%-os javulás az ügyfélmegtartásban —, de a megtérülési idő ott hosszabb volt, a költségcsökkentés pedig kevésbé egyértelmű.
(Ugyanez a riport tartalmazza azt a sokat idézett állítást, hogy a szervezetek 95%-a nulla megtérülést ér el. Ez a szám a szakmában vitatott, és a fenti módszertannal együtt kell olvasni: interjúk és konferencián gyűjtött kérdőívek, nem hivatalos vállalati adatközlés.)
Az első ellenőrzött tanács tehát: ne az ügyfélkommunikációval kezdd, hanem egy belső, ismétlődő háttérfolyamattal. Ott mérhető a megtakarítás, és ott nem az ügyfél a tesztalany.
Vedd, ne építsd
A második tanács ugyanabból a riportból jön, és számmal alátámasztott.
A külső partnerrel vagy kész platformmal indított kísérletek kétszer akkora eséllyel jutottak el teljes bevezetésig, mint a saját fejlesztésűek: 66% szemben 33%-kal.
Kezdő automatizálásnál tehát kész platformot érdemes választani, nem saját kódot. Nem azért, mert a saját kód rossz — hanem mert a projekt kétszer akkora eséllyel fejeződik be.
Mennyibe kerül valójában?
Itt jön a szám, ami a legtöbb kezdő tervezést átrendezi.
Feltevés: napi egy futás (havi 30), futásonként egy modell hívás, 1 500 bemeneti és 400 kimeneti token.
| Modell | Havi modellköltség |
|---|---|
| Egy olcsó, kis modell | $0,02 |
| Egy gyors, közepes modell | $0,11 |
| Egy közepes árfekvésű erős modell | $0,21 |
| Egy felső kategóriás modell | $0,53 |
És a platformdíj ugyanerre a terhelésre: havi 12 és 20 dollár/euró között, a csomagtól függően.
A platformdíj tehát a modellköltség huszonháromszorosa és ezerszerese között van. Konkrétan: egy gyors, közepes modellnél a modell havi 11 cent, a belépő platformcsomag 12 dollár — a platform több mint százszor drágább, mint maga az AI.
(Saját számítás mai listaárakkal. Nem tartalmazza az újrapróbálkozásokat, a hibás futásokat és a tesztelést — utóbbi bevezetéskor jellemzően a legnagyobb tétel. És feltételezi, hogy egy futás egy modellhívás: egy agentnél ez 3–10 hívás is lehet, akkor szorozd fel.)
Négy következmény:
- A modellválasztás ezen a méreten pénzügyileg lényegtelen. Válaszd a jobbat, nem az olcsóbbat.
- A valódi döntés a platform. Ha egyetlen automatizálásod van, egy önhosztolt, ingyenes licencű megoldás olcsóbb — de a saját üzemeltetés munkaideje jellemzően többe kerül, mint a megspórolt húsz dollár.
- A számítás megfordul, ha sok a futás. Havi 30 helyett 3 000 futásnál a modellköltség százszorozódik, és onnantól már számít a modellválasztás.
- Az első automatizálásnál tehát ne a modellárral foglalkozz.
A négy dolog, ami elrontja
Az első: a rendszer nem tanul. Az idézett riport szerint a fő akadály nem az infrastruktúra és nem a szaktudás, hanem hogy a legtöbb rendszer nem őrzi meg a visszajelzést, nem alkalmazkodik a kontextushoz, és nem javul az idővel. Az okok a riport szavaival: törékeny munkafolyamatok, hiányzó kontextuális tanulás, és eltérés a napi működéstől.
A második: ami egyszer működött, nem működik mindig. Van egy mérés, ami nem azt nézi, sikerül-e a feladat, hanem hogy nyolcból nyolcszor sikerül-e. Az akkori legjobb rendszerek 25% alatt teljesítettek ezen. A bemutató, ahol egyszer szépen lefutott, semmit nem mond a nyolcadik futásról.
A harmadik: a „biztos, ami biztos" adatbetolás. Egy 18 modellt vizsgáló mérés szerint a teljesítmény egyre megbízhatatlanabb, ahogy nő a bemenet — és már egyetlen oda nem illő elem is rontja az eredményt. A kezdő tipikus hibája, hogy mindent beletesz a promptba. Ez nem semleges: ront.
A negyedik: a platformkorlátok, amikbe belefutsz. Ezek dokumentált számok, nem meglepetések:
- Az egyik nagy platform belépő csomagjában a munkafolyamat 320 MiB memóriát kap — és maga a szoftver ebből átlagosan 180-at elhasznál. A dokumentáció szerint nagy adatmennyiséget feldolgozó összetett munkafolyamatnál a példány összeomolhat és elérhetetlenné válhat.
- Ugyanott a naplómegőrzés a belépő csomagon 7 nap vagy 2 500 futás, amelyik előbb betelik. Egy hónap múlva a napló már nincs meg.
- És a dokumentáció őszintén hozzáteszi: magas lemeztelítettségnél kézzel is törölnek, és „az emberi lépések miatt a riasztási rendszer nem tökéletes".
Mit naplózz?
Erre van formális szabvány, nem kell kitalálni. A megfigyelési konvenciókból levezetve nyolc dolog, ami nélkül egy hónap múlva nem lehet rekonstruálni, mi történt:
1. MELYIK PROMPTVERZIÓ futott
A szabvány külön mezőt ad rá. Ezt szokták a
legjobban sajnálni, amikor hiányzik.
2. MELYIK MODELL VÁLASZOLT
Nem az, amit kértél — ami válaszolt.
3. HÁNY MODELLHÍVÁS ÉS HÁNY ESZKÖZHÍVÁS volt
Ebből látod, hogy elszaladt-e a futás.
4. HÁNY TOKEN ment el
Külön bemenet, kimenet, cache.
5. MIÉRT ÁLLT LE
Kész lett, korlátba ütközött, vagy hibázott?
6. HIBA ESETÉN A HIBA OSZTÁLYA
Nem a szövege. Az osztálya, hogy számolható legyen.
7. A BESZÉLGETÉS AZONOSÍTÓJA
Enélkül a lépések nem fűzhetők össze.
8. VOLT-E KONTEXTUSTÖMÖRÍTÉS
Ha a rendszer a háttérben levágta az előzményt,
az megmagyarázza a furcsa viselkedést.
És egy dolog, amit tudatosan kell eldönteni, nem véletlenül. A szabvány az eszközhívás argumentumait és eredményét külön kategóriába teszi: alapból nem naplózandó, csak ha kifejezetten bekapcsolod — és odaírja, hogy érzékeny adatot tartalmazhat.
Magyarul: ha személyes adatot dolgozol fel, a napló maga is adatkezelés. Ez nem technikai, hanem jogi döntés.
A recept
1. VÁLASSZ EGY BELSŐ, ISMÉTLŐDŐ FELADATOT
Ami hetente legalább ötször megvan, és nem ügyfél
látja. A mérések szerint itt a leggyorsabb a megtérülés.
2. ÍRD LE KÉZZEL, MIELŐTT AUTOMATIZÁLNÁD
Ha nem tudod leírni, a gép sem fogja tudni megcsinálni.
3. KÉSZ PLATFORM, NE SAJÁT KÓD
Kétszer akkora esély, hogy be is fejezed.
4. EGY HÉTIG CSAK JAVASOLJON, NE CSINÁLJA
Naponta nézd meg, mit tett volna. Ez az egyetlen
módja, hogy kiderüljön: a nyolcadik futás is jó-e.
5. NAPLÓZZ A NYOLC PONT SZERINT
És nézd meg, meddig őrzi meg a platformod.
Hét nap kevés.
6. LEGYEN MEGÁLLÍTÓGOMB
Egy kapcsoló, ami leállítja. Ne kelljen keresni,
amikor kell.
A negyedik pont a legfontosabb, és a legtöbben ezt hagyják ki. Egy hét „csak javaslat" üzemmód pontosan azt méri, amit a bemutató nem: a megbízhatóságot ismétlésben.
Tipikus félreértések
- „Kezdjük az ügyfélkommunikációval, ott látszik a leggyorsabban." A mérés szerint a háttérfolyamatoknál gyorsabb a megtérülés és tisztább a költségcsökkentés — a pénz mégis odamegy.
- „Építsük meg magunk, jobban fogjuk érteni." A saját fejlesztésű kísérletek fele akkora eséllyel jutottak el teljes bevezetésig, mint a kész platformra épülők.
- „Drága lesz a modell." Napi futásnál a modell havi néhány cent. A platformdíj a nagyságrendekkel nagyobb tétel.
- „A bemutatón működött." Az egyszeri siker és a nyolcból nyolcszori siker két külön mérőszám, és utóbbiban a rendszerek jóval gyengébbek.
- „Adjunk neki minél több adatot." Már egyetlen oda nem illő elem is mérhetően ront.
- „Majd visszanézzük a naplóban." Ha a csomagod hét napig őrzi, akkor egy hónap múlva nincs mit visszanézni.
Amit érdemes elvinni
Az első automatizálásnál három döntés számít, és a modellválasztás nincs köztük.
A feladat: belső, ismétlődő, nem ügyfélérintő — ott mérhető a haszon. A platform: kész megoldás, mert kétszer akkora eséllyel fejezed be. A bizonyítás: egy hét „csak javaslat" üzemmód, mert az egyszeri siker nem bizonyíték.
És egy negyedik, amit menet közben kell eldönteni, nem utólag: mit naplózol, és meddig őrzöd meg. Ez dönti el, hogy egy hónap múlva meg tudod-e mondani, mi történt — és GDPR-hatókörben azt is, hogy szabad-e egyáltalán.
Hogy melyik platformot érdemes választani és miért az elszámolási egység a döntés lényege, arról a no-code platformok poszt szól árakkal; a hosszabb, több lépéses futások megbízhatóságáról pedig az agent-megbízhatóság matematikája poszt. Ha pedig a rendszer, amit automatizálnál, egyáltalán nem kínál API-t, a browser és computer use agentek című írás mondja meg, mikor éri meg mégis nekiállni.