Egy céges weboldal ajánlatkérési útvonala akkor áll össze, ha a látogató megérti a szolgáltatást, el tudja dönteni, hogy neki való-e, és világos következő lépést kap. Ehhez egymásra épülő tartalom, hiteles bizonyíték és használható űrlap szükséges. Egy feltűnő ajánlatkérő gomb önmagában nem pótolja a döntéshez hiányzó információt.
A látogató nem feltétlenül a főoldalon érkezik, és nem biztos, hogy előre ismeri a cégedet. Jöhet szolgáltatási keresésből, egy szakmai cikkből vagy ajánlásból. A feladat az, hogy az érkezési pontjától eljuthasson egy értelmes megkeresésig, anélkül hogy neki kellene összeraknia, mit vállalsz és mit írjon az üzenetbe.
Határozd meg, milyen megkeresést szeretnél kapni
Az „érkezzen több ajánlatkérés” kevés a tartalom megtervezéséhez. Írd le, milyen problémával, milyen szolgáltatásra és milyen előkészítettséggel kereshet meg egy érdeklődő. Más információ szükséges egy ismert feladat kivitelezéséhez, mint egy még feltárandó üzleti probléma megoldásához.
Egy szakipari vállalkozásnak fontos lehet a helyszín és a munka típusa, egy fejlesztési projektnél pedig a jelenlegi rendszer és az elérni kívánt működés. Ez nem jelenti azt, hogy mindent kötelező mezőként kell bekérni. A cél annak tisztázása, milyen adatokkal tudsz érdemben elindítani egy beszélgetést.
A szolgáltatás határait is mondd ki. Ha valamit nem vállalsz, vagy a munkához előzetes felmérés szükséges, a látogató ezt még beküldés előtt értse meg. Ez segíthet csökkenteni a félreértést, de a valódi minőségi javulást a beérkező megkeresések alapján kell értékelni.
A szolgáltatásoldal válaszoljon a döntési kérdésekre
A szolgáltatás megnevezése után mutasd meg, milyen helyzetben tudsz segíteni, és mit kap az ügyfél a munka végén. A „teljes körű megoldás” helyett konkrét vállalásokat írj: mi tartozik a felméréshez, tervezéshez, megvalósításhoz és átadáshoz. A fontos függőségeket és ügyféloldali teendőket se hagyd rejtve.
Érdemes megválaszolni azokat a kérdéseket, amelyek nélkül nehéz ajánlatot kérni: meglévő rendszeren is dolgoztok-e, ki adja a tartalmat, mi történik az indulás után, és hogyan alakul ki a munkaterv. Konkrét határidőt vagy árat csak akkor állíts, ha az adott szolgáltatásra ténylegesen vállalható és pontosan körülhatárolt.
A látogató számára legyen felismerhető, hogy a következő lépés kötelezettség nélküli érdeklődés, időpontfoglalás vagy konkrét megrendelés. A gomb felirata igazodjon ehhez. Ha a beküldés után először egyeztetés történik, ne ígérj azonnali, végleges árajánlatot.
A céges weboldal elkészítésének költségtényezői külön témát érdemelnek. Az ajánlatkérési útvonalnál az a kérdés, hogy az érdeklődő megkapja-e a saját döntéséhez szükséges támpontokat, és érti-e, milyen adatokból készülhet becslés.
A bizonyíték a szolgáltatás konkrét részéhez kapcsolódjon
A referencia akkor hasznos, ha megmutatja a feladatot, az elkészült megoldást és a vállalt szerepedet. Egy szép képernyőkép önmagában keveset mond arról, milyen problémát oldottál meg. Ha saját terméket mutatsz be, nevezd saját terméknek; ha csak a projekt egy részén dolgoztál, azt írd le.
Az ügyfélvéleményeket hiteles névvel és a szükséges engedélyekkel érdemes használni. Ne egészítsd ki őket kitalált üzleti eredményekkel. Ha nincs mérési adat arról, hogy egy új weboldal több bevételt hozott, a bemutatóban maradj az igazolható működésnél és a ténylegesen elkészült feladatnál.
A bizonyíték helye is számít a tartalmi logikában. Egy összetett rendszerintegráció leírása mellett az ehhez kapcsolódó tapasztalat segít megítélni a felkészültséget. Az általános cégtörténetnek lehet külön oldala, de a szolgáltatásoldalról ne csak hosszas kereséssel derüljön ki, miért érdemes beszélgetést kezdeni.
Számítógépen és mobilon is legyen egyértelmű, hogyan kérhet ajánlatot a látogató
Az ajánlatkérő felhívás jelenjen meg ott, ahol a látogató már érdemben tud dönteni. Hosszabb oldalon indokolt lehet több, azonos célhoz vezető lehetőség, de ne versenyezzen egyszerre sok különböző felszólítás. A szolgáltatást olvasó érdeklődőnek legyen világos, hogyan jut a megfelelő űrlaphoz.
Ha a gomb külön kapcsolati oldalra vezet, a szolgáltatás kontextusa ott se vesszen el. A választás előre kitölthető vagy világosan kiválasztható, de a látogató tudja módosítani, ha mást szeretne. A böngésző vissza gombjával és a billentyűzettel végzett navigáció is maradjon használható.
Mobilon próbáld ki valódi kitöltéssel az utat. Ne takarja el az űrlapot egy sütisáv vagy lebegő elem, és ne kelljen vízszintesen görgetni a mezők eléréséhez. A telefonos vagy e-mailes alternatíva hasznos lehet annak, aki nem az űrlapot szeretné használni; a megadott kapcsolat viszont legyen ténylegesen felügyelt.
Az űrlap csak azt kérje, amire az első válaszhoz szükség van
Különítsd el a kötelező és az opcionális adatokat. Egy általános érdeklődésnél a név, elérhetőség és rövid problémaleírás elég lehet az induláshoz, míg egy helyszíni munkához más adat is nélkülözhetetlen. A szükséges mezőket a saját munkafolyamatodból vezesd le, ne egy kész űrlapsablonból.
A szabad szöveges mezőhöz adhatsz rövid útmutatást: mi a cél, mi működik most, és mi okoz problémát. Az útmutatás ne váljon kötelező szakmai specifikációvá. A legtöbb érdeklődő nem fejlesztőként vagy beszerzési szakértőként érkezik, ezért saját szavaival is el kell tudnia mondani az igényét.
A mezőknek legyen egyértelmű, hozzájuk rendelt címkéjük. A W3C űrlapcímkézési útmutatója ezt a segítő technológiákat használók számára is lényegesnek tartja. A mezőben eltűnő mintaszöveg önmagában ne legyen az egyetlen támpont arra, mit kell beírni.
Az adatkezelési tájékoztatás legyen elérhető a kitöltés helyén, és feleljen meg a tényleges adatfelhasználásnak. Az ajánlatkérést ne kezeld automatikusan hírlevél-feliratkozásként. A pontos adatkezelési és hozzájárulási megoldást a saját folyamathoz kell kialakítani; egy másolt jelölőnégyzet önmagában nem igazol megfelelőséget.
A hibától a sikeres feldolgozásig legyen visszajelzés
Hibás kitöltésnél az üzenet mondja meg, melyik mezővel van gond és hogyan javítható. A W3C visszajelzési útmutatója az érthető hibaüzenet mellett a siker megerősítését is hangsúlyozza. A puszta piros szegély vagy általános „hiba történt” szöveg kevés segítséget ad.
Sikeres beküldés után derüljön ki, mi történik ezután. Válaszidőt akkor írj, ha azt a vállalkozás ténylegesen vállalni tudja. A rendszer közben rögzítse a megkeresést a kijelölt helyen, és a felelős munkatárs kapjon használható értesítést. A böngészőben megjelenő sikerüzenet még nem bizonyítja az e-mail kézbesítését.
A spamvédelem fontos, de a teszt része legyen, hogy egy valódi érdeklődő is be tudja küldeni az adatokat. A reCAPTCHA használatáról szóló cikk ehhez ad részletesebb szempontokat. A védelmi megoldás és a kötelező mezők működését frissítés után is ellenőrizni kell.
Az érdemi megkereséseket mérd, és a teljes ajánlatkérési folyamatot próbáld ki
Különítsd el a gombkattintást, az űrlap elkezdését, a sikeres beküldést és az érdemi üzleti megkeresést. Ezek eltérő események. Sok kattintás kevés beküldéssel jelezhet akadályt, de az ok megállapításához a működés és a forgalom összetételének vizsgálata is szükséges.
A mérési rendszerbe ne küldj be személyes üzenettartalmat, nevet vagy e-mail-címet pusztán azért, hogy össze tudd számolni az érdeklődéseket. A teszt- és spambeküldéseket külön kezeld. A változtatás után ugyanazzal a definícióval értékeld a megkereséseket; attól, hogy a módosítás után több vagy kevesebb megkeresés érkezik, még nem biztos, hogy ezt a módosítás okozta.
Indulás előtt kérj meg valakit, aki kevésbé ismeri a cégedet, hogy egy konkrét igénnyel járja végig az oldalt és a kitöltést. A megakadásait figyeld, ne csak azt, hogy tetszik-e a design. Ha ezen az útvonalon szeretnél javítani, a KovaBuild weboldalkészítési szolgáltatásánál a jelenlegi oldal és a kívánt megkereséstípus alapján lehet kijelölni a tartalmi és műszaki feladatokat.