Előbb a munkafolyamatot próbáld ki

Akkor érdemes kész CRM-et választanod, ha megfelelő beállításokkal el tudjátok benne végezni a napi munka lényeges feladatait. Egyedi fejlesztés akkor kerülhet szóba, ha egy fontos, rendszeresen ismétlődő folyamat továbbra is nehézkes kerülőmegoldásokat igényel, és a fejlesztés mellett a későbbi fenntartásra is van keret. Ha csak két eszköz összekapcsolása hiányzik, lehet, hogy egy integráció is elég.

Ezt nem dönti el önmagában a csapat mérete, vagy az, hogy most táblázatokban dolgoztok. Indulj ki egy konkrét problémából: gazdátlanul marad egy megkeresés, ugyanazt az adatot kétszer kell beírni, vagy egy fontos üzleti kérdésre nem tudtok választ kapni a kimutatásokból. Aztán próbáld ki, melyik megoldás szünteti meg valóban a gondot.

Ez az útmutató az előfizetés vagy a fejlesztési megbízás előtti döntéshez ad szempontokat. Nem abból indul ki, hogy minden üzleti eszközt érdemes saját magadnak elkészíttetni.

Három lehetőséget hasonlíts össze

  • Kész CRM beállítása: a meglévő mezőket, státuszokat és jogosultságokat igazítod a munkátokhoz. Akkor jó jelölt, ha főként a kapcsolattartókat, az értékesítési lehetőségeket és az utánkövetést kell átláthatóvá tenni.
  • Meglévő eszközök összekapcsolása vagy kiegészítése: az ügyféladatok maradnak a CRM-ben, mellé pedig elkészül a hiányzó kapcsolat vagy egy kisebb célalkalmazás. Ezt érdemes kipróbálni, ha a weboldal, a naptár, az ajánlatkészítő és a CRM közötti adatátadás akad el.
  • Egyedi rendszer fejlesztése: a folyamatot és a felületet olyan igényekhez alakítjátok, amelyeket a kipróbált megoldások nem tudnak elfogadhatóan kezelni. A szoftver fenntartásáról akkor is gondoskodnod kell, ha külső fejlesztő készíti.

Néhány saját mező miatt még nem feltétlenül kell új rendszert fejleszteni. A HubSpotban például létrehozhatók egyéni adatmezők, de a darabszám és egyes lehetőségek az előfizetéstől függnek. Azt a csomagot ellenőrizd, amelyet ténylegesen megvennél: ne vedd biztosra, hogy a bemutatón látott összes funkció benne van.

Az integráció sem old meg mindent magától. Döntsétek el, melyik adatnál melyik rendszer az elsődleges, és mi történik, ha nem sikerül átadni egy módosítást. Enélkül ugyanarról az ügyfélről két eltérő adatlap maradhat a két eszközben.

Írj le egy valós feladatot az elejétől a végéig

Válassz egy gyakori, problémás folyamatot. Egy megkeresésekből dolgozó vállalkozásnál ez például így nézhet ki: beérkezik az érdeklődés, valaki átveszi, rögzíti az egyeztetést, módosul az időpont, majd egy kolléga folytatja az ügyet.

Minden lépésnél írd le, ki dolgozik vele, mit kell látnia, mit módosíthat, és mikor tekinthető késznek a feladat. A kivételeket is vedd sorra: ugyanaz az ember újra jelentkezik, szabadságon van az ügy felelőse, vagy az érdeklődő meggondolja magát.

Az általános igényeket fordítsd le ellenőrizhető eredményekre. A „jobb érdeklődőkezelés” helyett például: „Egy kolléga úgy tudja átvenni az ügyet, hogy látja az utolsó egyeztetést és a következő teendőt, és nem kell megkérdeznie az előző felelőst.” A „naptár-integráció” helyett pedig pontosítsd, melyik naptár melyik időpontot frissíti, és miből derül ki, ha ez nem sikerült.

Válaszd külön a valóban szükséges üzleti szabályt a megszokástól. Ha a csapat el tud fogadni egy világosabb közös folyamatot, lehet, hogy beállításokra és betanításra van szükség. Ha viszont egy megkerülhetetlen szabály csak fontos adatok megjegyzésmezőbe rejtésével kezelhető, az már konkrét érv a fejlesztés megvizsgálása mellett.

Ugyanazokat a feladatokat próbáld ki minden jelöltnél

Az összehasonlításhoz használj kitalált vagy megfelelően anonimizált adatokat. Minden bemutatón ugyanazokat a feladatokat kérd, majd próbálja ki őket az is, aki később a rendszerben dolgozik:

  • Érkezzen be egy megkeresés a weboldalról, és kapjon felelőst.
  • Jelentkezzen újra ugyanaz az érdeklődő úgy, hogy az előzmények megmaradjanak.
  • Vegye át egy kolléga az ügyet, és lássa a következő teendőt.
  • Módosuljon egy időpont; ellenőrizzétek a naptárral való kapcsolatot és egy sikertelen frissítés kezelését is.
  • Lépjetek be korlátozott jogosultságú felhasználóként, és nézzétek meg, mit láthat és módosíthat.
  • Exportáljatok egy próbaügyfelet azokkal a kapcsolódó adatokkal együtt, amelyeket rendszerköltözéskor is vinnétek magatokkal.

Minden feladathoz írjátok oda: beállítással működik, integráció kell hozzá, egyedi fejlesztést igényel, vagy nem teljesíti az elvárást. Jegyezzétek fel a kézi másolásokat és azt is, melyik előfizetés vagy kiegészítő szolgáltatás szükséges hozzá. Egy funkciónév az árlistán még nem bizonyítja, hogy a feladat a gyakorlatban is megoldható.

Tervezett egyedi fejlesztésnél először a legnehezebb folyamat kis prototípusát kérd, és csak utána bővítsétek a feladatot. A prototípus megmutathatja, hogy működőképes-e az elképzelés. Azt még nem igazolja, hogy a jogosultságkezelés, a helyreállítás és a napi üzemeltetés készen áll az éles használatra.

Azonos időszak teljes költségét hasonlítsd össze

Ugyanarra a feladatra és tervezési időszakra kérj becslést. Választhatsz például két évet az összehasonlításhoz; ez tervezési döntés, nem általános megtérülési határidő.

Minden lehetőségnél számolj ezekkel:

  • Indulás: a folyamat megtervezése, beállítás vagy fejlesztés, adattisztítás, adatköltöztetés és tesztelés.
  • Napi működés: előfizetések, tárhely, integrációk, e-mail-szolgáltatások, működésfigyelés és a rendszer kezelésére fordított munkaidő.
  • Folyamatos használhatóság: betanítás, támogatás, hibajavítás, biztonsági frissítések és a kapcsolódó szolgáltatások változásainak követése.
  • Későbbi változtatás és váltás: új igények, adatexport, dokumentáció és átadás egy másik szolgáltatónak.

Egy egyszeri fejlesztési díj és egy havi licencdíj önmagában nem összehasonlítható végösszeg. Kérdezz rá, mi maradt ki az ajánlatokból. Kész CRM-nél a tényleges munkafolyamathoz szükséges csomaggal számolj. Egyedi rendszernél tisztázzátok, ki fizeti a karbantartást, és hogyan becsülik meg a változtatások díját.

Ha kevesebb kézi munkát vársz, mérd meg a jelenlegi feladatot, majd ismételd meg a próba során. Ezekből a megfigyelésekből becsüld az időmegtakarítást. Ezt kezeld külön a remélt többletértékesítéstől: egy új felület vagy néhány kattintás megspórolása még nem bizonyít bevételnövekedést.

Próbáld ki, hogyan vinnéd el az adataidat

Attól, hogy van exportgomb, még nincs kész a költözési terv. Döntsd el, mely adatlapok, kapcsolatok, jegyzetek és fájlok fontosak, majd nézd meg a kimentett adatokat, és próbáld betölteni őket egy másik rendszerbe.

A HubSpot exportálási útmutatója például külön kezeli az adatmezők aktuális értékeit és az adatlapok közötti kapcsolatokat, illetve az olyan tevékenységeket, mint a hívások és a jegyzetek. Utóbbiakhoz más exportálási lehetőségeket sorol fel. Ezért az export tényleges tartalmát vizsgáld meg, ne csak azt, hogy sikerült-e letölteni egy fájlt.

Az egyedi fejlesztés sem szünteti meg automatikusan a szolgáltatótól való függést. Előre állapodjatok meg abban, ki kezeli a forráskódot és a tárhelyfiókokat, milyen hozzáféréseket és dokumentációt adnak át, és mi kellene ahhoz, hogy egy másik fejlesztő működtetni tudja a rendszert. Ezeket a projekt elején tisztázd.

Legyen felelőse a fenntartásnak

Indulás előtt derüljön ki, ki kapja a hibajelzéseket, ki tudja helyreállítani a rendszert, és ki követi a kapcsolódó eszközök változásait. Írjátok le, mekkora leállást és adatvesztést visel el a vállalkozás, majd kérjétek a hozzá illő helyreállítási folyamat bemutatását.

A jogosultságokat működés közben is ellenőrizni kell. Egy szerkesztésgomb elrejtése nem elég védelem. Az OWASP jogosultságkezelési útmutatója alapértelmezett tiltást és minden kérésnél jogosultság-ellenőrzést javasol. A próba során a fejlesztő azt is ellenőrizze, hogy egy korlátozott fiók közvetlen kéréssel sem fér hozzá egy másik csapat védett adataihoz.

A mentés tartalmára is kérdezz rá. A Supabase dokumentációja szerint az adatbázis-mentés nem tartalmazza a Storage API-n keresztül tárolt fájlokat, csak a hozzájuk tartozó leíró adatokat. Ha egy rendszer így tárolja a mellékleteket, a fájlokról külön is gondoskodni kell a helyreállítási tervben. Olyan visszaállítási próbát kérj, amelyben a csapat számára fontos dokumentumok is szerepelnek, nem csak az ügyféltábla.

Ezekhez üzemeltetési feladatot, felelőst és költségkeretet kell rendelni. Egy szolgáltatott rendszer bizonyos részeket átvehet, de mindkét megoldásnál legyen egyértelmű, pontosan mi tartozik bele.

Mit szemléltet a MarciCRM?

A saját munkáim között szereplő MarciCRM az ingatlanos megkereséseket, az egyeztetések állapotát és az utánkövetést fogja össze. Külön kezeli a spanyolországi, thaiföldi és dubaji munkát, és naptárakhoz, illetve weboldalakhoz kapcsolódik. Ezek konkrét munkafolyamatok, nem egy általános igény arra, hogy „több CRM-funkció legyen”.

Ez a példa nem bizonyítja, hogy a te cégednek is olcsóbb vagy jobb lesz az egyedi rendszer. A tanulsága az, hogy a munkát elég pontosan kell leírni ahhoz, hogy össze lehessen hasonlítani a megoldásokat. A weboldal, a hirdetés és az utánkövetés kapcsolata bármelyik szoftver mellett fontos marad.

Olyan döntést hozz, amelyet meg tudsz indokolni

Én a beállított kész CRM mellett maradnék, ha teljesíti a próba lényeges feladatait, és elfogadható a működtetés költsége. Integrációt vizsgálnék, ha a CRM jól használható, de egy konkrét adatátadás nem működik. Egyedi fejlesztés akkor kerülne szóba, ha a fennmaradó hiányosságok fontos munkát akadályoznak, ezt a próba is megmutatta, és a megoldásuk indokolja a fejlesztést és a megtervezett fenntartást.

Ajánlatkérés előtt készítsd össze a munkafolyamatot, a fontos kivételeket, a kapcsolódó rendszereket, a hozzáférési szabályokat és a megőrzendő adatokat. Ha már próbáltatok valamit, az eredményét is add hozzá. Ez többet segít a fejlesztőnek, mint egy hosszú funkciólista.

Ha ezek között a lehetőségek között döntesz, írd le röviden a helyzetet a kapcsolati oldalon. Az üzeneted a hello@davidbuka.com címre érkezik meg. Mondd el, hogyan dolgoztok most, hol akadtok el, és mit próbáltatok már ki. Ebből kiindulva meg tudjuk határozni a következő lépést.

A forrásokat 2026. október 14-én ellenőriztem. A borítókép eredeti szerkesztőségi illusztráció, nem egy ügyfél rendszeréről készült fénykép.