Így beszéljen egymással a webshop, a CRM és a számlázó
A baj nem az, hogy kevés a szoftver, hanem hogy egyik sem tud a másikról. Rendszertérkép, adatgazdák és a négy tipikus kapcsolat.

A legtöbb kkv-ban nem az a baj, hogy nincs elég szoftver. Hanem az, hogy túl sok van, és egyik sem tud a másikról. A webshopban ott a rendelés, a számlázóban a számla, a CRM-ben az ügyfél, a raktárprogramban a készlet — és a négyet egy ember tartja össze, másolással. Ez a cikk arról szól, hogyan lehet ezt rendesen összekötni, és mire kell figyelni, hogy ne legyen belőle még nagyobb káosz.
Az adatmásolás rejtett költsége
Amikor ugyanazt az adatot két helyre kell bevinni, három dolog történik. Idő megy el — naponta akár órák. Hibák keletkeznek — elgépelt cím, rossz adószám, lemaradt tétel. És ami a legrosszabb: megszűnik az igazság. Ha a CRM-ben és a számlázóban más az ügyfél címe, akkor melyik az érvényes? Ilyenkor már nem tudsz megbízni a saját adataidban, és minden döntés előtt ellenőrizni kell.
Az integráció valódi haszna nem az időmegtakarítás, hanem az, hogy lesz egyetlen hiteles forrás minden adattípusra.
Első lépés: rajzold fel, mi hova folyik
Mielőtt bármilyen technológiáról beszélnénk, egy A4-es lapon rajzold fel a rendszereidet, és húzz nyilat közéjük: milyen adat, melyik irányba, milyen gyakran. Ez a rajz általában két dolgot azonnal megmutat: van egy-két nyíl, ami körbe-körbe jár, és van egy ember, akin minden nyíl átmegy.
Ezután minden adattípushoz jelöld meg a gazdáját: hol keletkezik hitelesen? A termékadat általában a raktár- vagy ügyviteli rendszerben, az ügyféladat a CRM-ben, a rendelés a webshopban, a számla a számlázóban. Ahol nem tudsz egyértelmű gazdát mondani, ott lesz a legtöbb konfliktus később.
A négy tipikus kapcsolat
Webshop → számlázó
Rendelés véglegesítésekor automatikus számla, a helyes adószámmal, ÁFA-kulccsal és tételekkel, e-mailben az ügyfélnek. A buktató itt a sztornó és a módosító számla: ha ezt nem tervezed meg előre, minden reklamáció kézi munka marad.
Webshop → CRM
Az új vásárlóból kontakt lesz, a rendelésből előzmény. Ettől lesz értelme a visszatérő vásárlók megszólításának, mert látod, ki mit vett és mikor. A buktató a duplikáció: ha az egyezőséget csak névre nézed, három Nagy Péterből egy lesz.
Ügyviteli rendszer → webshop
Készlet és ár szinkron. Ez a leggyakoribb valódi fájdalompont: a túlértékesítés (kifogyott terméket adsz el) közvetlen ügyfélvesztés. Itt a frissítés gyakorisága a kulcskérdés — az óránkénti szinkron sok mindenre elég, de kampányidőszakban kevés lehet.
Minden → riport
Egy közös hely, ahol a számok összeérnek. Nem kell drága BI-eszköz hozzá; sokszor elég egy jól felépített adattábla és néhány automatikus lekérés.
Hogyan kössük össze őket?
Webhook, ha lehet
A legjobb megoldás, ha a forrásrendszer maga szól, amikor történik valami: „új rendelés érkezett". Ez azonnali, és nem terheli feleslegesen a rendszereket. Ha az adott szoftver támogatja a webhookot, mindig ezt válaszd.
Ütemezett lekérdezés, ha kell
Ha nincs webhook, marad az időzített kérdezés: „mi változott a legutóbbi futás óta?". Fontos, hogy tényleg csak a változásokat kérd le, ne mindent — különben pár ezer rekord után lassú és drága lesz.
Köztes réteg mindig
Ne kösd össze közvetlenül a rendszereket egymással. Ha minden mindennel beszél, akkor öt rendszernél már tíz kapcsolatot kell karbantartanod, és egyik cseréje az összeset felborítja. Egy köztes integrációs réteg — legyen az n8n, egy saját szolgáltatás vagy egy integrációs platform — azt jelenti, hogy minden rendszer csak eggyel beszél, és cserénél egy helyen kell módosítani.
Amit szinte mindenki elront elsőre
- Nincs egyedi azonosító. Ha nem tárolod el, hogy a webshop 1234-es rendelése a számlázóban melyik számla lett, akkor nem tudod összepárosítani őket, és nem tudsz javítani sem.
- Nincs újrapróbálkozás. Az API-k néha nem válaszolnak. Ha ilyenkor a folyamat egyszerűen elveszti az adatot, akkor csendben hiányozni fog egy rendelés.
- Nincs idempotencia. Ha egy webhook kétszer fut le, ne készüljön két számla. Ezt előre kell megoldani, nem utólag.
- Nincs napló. Amikor az ügyfél azt mondja, nem kapott számlát, tudnod kell megnézni, mi történt pontosan és mikor.
- Nincs riasztás. A hibáról értesülni kell, méghozzá emberi csatornán — e-mailben vagy chatben, nem egy szerverlogban.
Fokozatosan, ne egyszerre
Az integrációs projekteket az öli meg, ha egyszerre akarod az egészet. A működő minta: válaszd ki azt az egy nyilat a rajzodon, amelyik a legtöbb kézi munkát viszi el, kösd össze rendesen, hibakezeléssel és naplózással együtt, majd mérd meg két hétig. Utána jöhet a következő. Így minden lépés után van kézzelfogható eredmény, és a rendszer sosem lesz olyan állapotban, hogy „félig kész".
Ha nálad is van egy kolléga, akinek a napja jelentős részét adatmásolás teszi ki, azt érdemes megnézni. Keress minket — felrajzoljuk együtt a rendszertérképet, és megmondjuk, melyik nyíl éri meg elsőként.

