Ajánlatadó rendszer fejlesztése: az igénytől a jóváhagyásig

Lassú, nehezen követhető az ajánlatkészítés? Gyakorlati útmutató az ajánlatadó rendszer kalkulációjához, verziókezeléséhez, jóváhagyásához és CRM-kapcsolatához.

Buda Sándor · 2026-10-02

Az ajánlatkészítés gyakran akkor lassul le, amikor már minden szükséges adat megvan, csak különböző helyeken. Az értékesítő egy korábbi dokumentumból másol, a műszaki kolléga e-mailben pontosít, a vezető pedig üzenetben engedélyezi a kedvezményt. Mire elkészül a végleges PDF, nehéz megmondani, melyik számítás és melyik jóváhagyás tartozik hozzá.

Az ajánlatadó rendszer fejlesztése ezt a folyamatot teheti követhetővé. Nem pusztán szebb dokumentumot készít: összekapcsolja az igényfelmérést, a kalkulációt, az ellenőrzést és az utánkövetést. Az alábbi útmutató abban segít, hogy eldöntsd, mire van valóban szükséged, és milyen szabályokat kell tisztázni a fejlesztés előtt.

Mikor indokolt külön ajánlatadó rendszer?

Önmagában a sok ajánlat még nem indokol egyedi fejlesztést. Ha néhány állandó termékből, egységes árlistából és egyszerű sablonból dolgoztok, elegendő lehet a meglévő CRM ajánlatkészítő funkciója. Először azt vizsgáld meg, hol keletkezik az időveszteség: az adatok összegyűjtésénél, a számításnál, a belső egyeztetésnél vagy a dokumentum összeállításánál.

Erősebb indok a fejlesztésre, ha egymástól függő opciókat kell kiválasztani, ügyfelenként eltérő feltételek érvényesek, vagy a vállalható teljesítés több részleg döntésétől függ. Ugyanígy problémát jelez, ha egy módosítás után több dokumentumban kézzel kell ugyanazt átvezetni, és rendszeresen eltérő verziók kerülnek az ügyfél elé.

Az üzleti szabályokra épülő egyedi szoftverfejlesztés ilyenkor egy konkrét munkafolyamatot támogat. A cél legyen megfogható: kevesebb újragépelés, visszakereshető számítás, követhető jóváhagyás. A gyorsabb ajánlatadás lehet eredmény, de ezt a saját folyamatotok mérése alapján kell igazolni.

Rajzold fel az ajánlat útját az igénytől a lezárásig

Válasszatok ki néhány szokásos és néhány problémás korábbi ajánlatot. Kövessétek végig, honnan jött az igény, ki pontosította, ki számolta ki, és mikor várakozott más ember döntésére. A folyamatábrán a várakozás ugyanolyan fontos, mint az aktív munkavégzés. Egy automatizált PDF nem oldja meg, ha napokig senki nem vállalja a műszaki ellenőrzést.

Használható kiindulás lehet az igény rögzítése, pontosítás, kalkuláció, belső ellenőrzés, kiküldés, módosítás és lezárás állapotsora. Minden állapothoz tartozzon felelős és egyértelmű továbblépési feltétel. A „folyamatban” önmagában kevés információ: nem derül ki belőle, hogy ügyfélválaszra vagy vezetői döntésre vártok.

A lezárásnál különítsétek el az elfogadott, elutasított, lejárt és visszavont ajánlatot. Az elvesztett ügylethez rövid, választható ok és szükség esetén megjegyzés tartozhat. Így később nem kizárólag a kiküldött dokumentumok számát látjátok, hanem azt is, hol akad el az értékesítés.

Az adatmodell alapja: ügyfél, igény, tétel és verzió

Az ajánlat nem egyetlen hosszú szövegmező. Célszerű külön kezelni az ügyfelet, a kapcsolattartót, az értékesítési lehetőséget, a tételeket és az ajánlat verzióit. Egy ügyfélnek több párhuzamos projektje lehet, egy projekthez pedig több alternatíva készülhet. Ha ezt nem választjátok szét, a kimutatások és az utánkövetési feladatok hamar összekeverednek.

Mi legyen kötelező, és mikor?

Az első telefonhívás után még nem feltétlenül ismert minden műszaki adat. A rendszer ezért engedjen hiányos igényt menteni, de jelölje, mi szükséges a kalkulációhoz és mi a kiküldéshez. Egy ismeretlen értéket ne helyettesítsetek automatikusan nullával: a nulla mennyiség és a még nem tisztázott mennyiség két külön állapot.

A megnevezés mellett rögzítsétek a mértékegységet, a mennyiséget, a kiválasztott opciókat és az adat forrását. Az értékesítő által becsült méretet például külön lehessen kezelni a helyszínen ellenőrzött mérettől. A rendszer így azt is megmutatja, mely ajánlatok várnak még olyan pontosításra, amely az árat megváltoztathatja.

A kalkuláció szabályait példákon keresztül tisztázzátok

A „számolja ki automatikusan az árat” követelmény nem elég pontos. Le kell írni az alapár forrását, az opciók felárát, a mennyiségi sávokat, a kedvezmények sorrendjét és a kerekítést. Más eredményt adhat, ha a kedvezmény minden tételre vonatkozik, mint ha csak a termékre, a kiszállításra viszont nem.

Készítsetek ellenőrzött mintaszámításokat a fejlesztővel közösen. Legyen köztük alaphelyzet, sávhatár, minimumdíj, nem kombinálható opció és egyedi felülbírálás. A mintában szerepeljen a kiinduló adat, az alkalmazott szabály és az elvárt eredmény. Ezek később a módosított kalkuláció ellenőrzését is segítik, nem kell minden alkalommal emlékezetből újraszámolni a folyamatot.

Az árlista változása ne írja át a múltat

A kiküldött ajánlat őrizze meg a felhasznált árakat és feltételeket. Egy új árlista ne módosítsa visszamenőleg a korábbi dokumentumot. Újraszámításkor jelenjen meg, mi változott, és az eredmény új verzióként készüljön el. Több pénznem esetén az alkalmazott átváltási adat forrását és időpontját is rögzíteni kell.

Jóváhagyás: csak a valódi kivételek álljanak sorba

Ha minden ajánlat vezetői jóváhagyást igényel, könnyen a vezető lesz a folyamat szűk keresztmetszete. Inkább határozzátok meg, milyen eltérés indokol külön döntést: szokatlan kedvezmény, nem standard tétel, egyedileg vállalt határidő vagy a megszokottól eltérő teljesítési feltétel. A konkrét határokat az üzleti felelősök határozzák meg.

A jóváhagyó lássa az eltérés okát, a kalkuláció lényegét és az ajánlat pontos verzióját. Az engedély egy meghatározott tartalomra vonatkozzon. Ha az értékesítő utána megváltoztatja a kedvezményt vagy a teljesítést, a rendszer a szabályok szerint kérjen új ellenőrzést. Egy régi jóváhagyás ne legyen korlátlan felhatalmazás a későbbi módosításokra.

A helyettesítést és a visszaküldést is tervezzétek meg. A vezető szabadsága ne eredményezzen láthatatlan várakozást. A visszaküldött ajánlatnál pedig legyen konkrét javítási feladat, ne csupán elutasítás. Az eseménynapló rögzítse, ki mikor döntött, és milyen indokkal.

Dokumentum és kiküldés: a verzió legyen azonosítható

A dokumentumsablon csak akkor megbízható, ha a mögötte lévő adatok is azok. Az ajánlat azonosítója, verziója, dátuma, érvényessége és a vállalt tartalom egyértelműen jelenjen meg. Az opcionális tételeket különítsétek el a vállalt csomagtól, a kizárásokat pedig ne rejtsétek el nehezen észrevehető megjegyzések közé.

A rendszer tárolja a kiküldött dokumentum változatát és a küldés eredményét. Külön állapot legyen, hogy egy ajánlat elkészült, elküldésre vár, vagy technikai hiba miatt nem ment ki. Az elküldött e-mail még nem bizonyítja, hogy az ügyfél elolvasta vagy elfogadta az ajánlatot. A státuszok ezeket az eseményeket ne mossák össze.

Az ügyfél visszajelzését mindig a megfelelő verzióhoz kapcsoljátok. Ha két alternatívát kapott, ne legyen kérdéses, melyiket választotta. A dokumentumok üzleti és szerződéses szövegét kijelölt felelős tartsa karban; a fejlesztés feladata ezek következetes alkalmazása és a változatok megőrzése.

CRM és integráció: egy adatnak legyen gazdája

Az ajánlatadó rendszernek nem szükséges új ügyfélnyilvántartást létrehoznia, ha már van használható CRM. A CRM és az értékesítési utánkövetés kialakításakor tisztázzátok, hol változik a kapcsolattartó, hol keletkezik az ügylet, és melyik rendszer kezeli a következő feladatot. Két párhuzamos ügyféladatbázis hosszú távon nehezen tartható összhangban.

Az integrációs terv nevezze meg az átadandó adatokat és az átadás eseményét. Az ajánlat kiküldése létrehozhat utánkövetési feladatot, az elfogadás pedig előkészíthet megrendelést. Ez utóbbi előtt ellenőrizni kell, hogy a kiválasztott tételek és feltételek továbbra is teljesíthetők-e. Ne keletkezzen automatikusan vállalás hiányos vagy elavult adatból.

Kapcsolati hiba esetén az érintett rekord maradjon visszakereshető, és lehessen újrapróbálni az átadást. Ugyanazon művelet ismétlése ne hozzon létre újabb megrendelést. Az operátor lássa, mi vár feldolgozásra, mi sikerült, és mely esethez szükséges emberi beavatkozás.

Szemléltető példa: telepítéssel együtt adott ajánlat

Vegyünk egy kitalált vállalkozást, amely berendezést és hozzá telepítést értékesít. Az ajánlathoz szükséges a berendezés típusa, a mennyiség, a helyszín műszaki adottsága és a kért kiegészítő szolgáltatás. A példa nem BudaWeb-ügyféltörténet, hanem a döntések összefüggését mutatja be.

Az értékesítő először rögzíti az igényt. Ha a helyszín adatai hiányosak, a rendszer felmérési feladatot ad, és még nem engedi véglegesíteni a telepítési díjat. A műszaki ellenőrzés után kiválaszthatóvá válnak a megfelelő opciók. A szokásostól eltérő vállalás külön jóváhagyásra kerül.

Az ügyfél később másik típust kér. A rendszer megőrzi az első ajánlatot, újraszámolja az érintett tételeket, és megjelöli, hogy a korábbi jóváhagyás új ellenőrzést igényel. Elfogadáskor a választott verzióból készül a megrendelési adatcsomag. Így a folyamat nem a PDF kézi átírásából, hanem követhető állapotváltásokból áll.

Mi kerüljön az első működő változatba?

Az első kiadás fogjon át egy teljes, gyakori ajánlattípust. Legyen benne igényrögzítés, ellenőrzött kalkuláció, szükséges jóváhagyás, dokumentumkészítés és státuszkövetés. Egyetlen végig használható folyamat többet tanít, mint sok különálló képernyő, amelyek között továbbra is kézzel kell adatot mozgatni.

A fejlesztési egyeztetéshez minden ajánlattípushoz készítsetek rövid működési lapot:

1. Milyen ügyféligény indítja a folyamatot, és ki rögzíti?
2. Mely adatok kellenek a számításhoz, és honnan származnak?
3. Milyen képlet és kivételszabály határozza meg az eredményt?
4. Mikor szükséges ellenőrzés, és ki dönthet?
5. Melyik dokumentum és adatcsomag készül a végén?
6. Milyen bizonyíték alapján tekinthető a folyamat sikeresnek?

A ritka kivételekhez kezdetben elfogadható lehet dokumentált kézi eljárás. Legyen látható, hogy az eset kilépett az automatizált folyamatból, és ki vállalja érte a felelősséget. Később a tényleges előfordulások alapján dönthettek a további automatizálásról.

Technikai ellenőrzés és bevezetési próba

A felület segítse a helyes adatbevitelt, de a szerver is ellenőrizze a kötelező mezőket, a megengedett értékeket és az üzleti szabályokat. A Laravel hivatalos validációs dokumentációja beépített és egyedi adatellenőrzési lehetőségeket ismertet. Ezek technikai eszközök: a vállalható opciók és kedvezmények szabályait továbbra is a vállalkozásnak kell meghatároznia.

Laravel-alapú ajánlatadó alkalmazás fejlesztésénél a kalkuláció, a dokumentumkészítés és az integráció külön ellenőrizhető részként tervezhető. Nem a keretrendszer neve dönti el a minőséget, hanem az, hogy a szabályok következetesen működnek-e, és a hibák észrevehetők, javíthatók-e.

Átvételi ellenőrzőlista

• Hiányos igény menthető, de nem küldhető ki végleges ajánlatként.
• A tiltott opciókombináció egyértelmű hibaüzenetet ad.
• A sávhatárok és a kerekítések a mintaszámítással egyeznek.
• Az új árlista nem változtatja meg a kiküldött ajánlatot.
• A lényeges módosítás új verziót és szükség esetén új jóváhagyást kér.
• A helyettesítő csak a számára engedélyezett döntést hozhatja meg.
• A sikertelen küldés látható, és ellenőrizhetően újrapróbálható.
• Az integráció ismétlése nem hoz létre második megrendelést.
• Az elfogadott verzióból a megfelelő tételek kerülnek tovább.
• A napló alapján visszakövethető a döntés és a kiküldés.

Mit mérj a bevezetés után?

A bevezetés előtt rögzítsétek a kiinduló állapotot, majd azonos típusú ajánlatokat hasonlítsatok össze. Mérhető az aktív szerkesztési idő, a jóváhagyásra várakozás, a javításra visszaküldött ajánlatok aránya és a kézi adatátadások száma. Az ajánlatadás teljes átfutása önmagában félrevezető lehet, ha az ügyfél válaszára várakozás is benne van.

Nézzétek meg azt is, használják-e a kollégák a rendszert, vagy továbbra is saját táblázatokban dolgoznak. A kerülőutak gyakran hiányzó funkciót vagy túl merev szabályt jeleznek. Rövid bevezetési megbeszéléseken gyűjtsétek a konkrét eseteket, és különítsétek el az oktatási problémát a valódi fejlesztési igénytől.

Összegzés: előbb tiszta szabályok, utána automatizálás

Egy jól megtervezett ajánlatadó rendszer összeköti az ügyféligényt, a számítást, a belső döntést és a kiküldött dokumentumot. A legfontosabb előfeltétel az adatgazdák, a verziók és a továbblépési feltételek tisztázása. Ettől válik az ajánlatkészítés ellenőrizhető folyamattá, amelyet később célzottan lehet gyorsítani.

Ha saját ajánlatadási folyamatod fejlesztését tervezed, a BudaWeb egyedi szoftverfejlesztési konzultációjára hozz egy jellemző ajánlatot, egy problémás kivételt és a jelenlegi lépések rövid leírását. Ezekből már felmérhető, hogy a meglévő eszköz bővítése, egy integráció vagy külön ajánlatadó alkalmazás oldja meg legjobban a feladatot.