Indulás · 5 perc olvasás

Az első ajánlatkéréstől a következő lépésig

Így tartsd számon, ki keresett meg, miben kér segítséget, és kinek kell válaszolnia.

A leírás a hivatkozott szolgáltatói dokumentációra épül. Saját éles rendszeren még nem próbáltuk ki.

Kezdd ott, ahol most elakad a megkeresés

Ha ajánlatkérések e-mailben, űrlapon és üzenetben is érkeznek, először egy csatornával kezdj. A cél az legyen, hogy minden beérkezett megkeresésnek legyen felelőse és következő lépése. Egy freelancer vagy kis digitális stúdió így látja, melyik kérés vár még válaszra.

Ez tervezési útmutató és saját javasolt ellenőrzőlista. Nem egy ügyfélrendszerben mért esettanulmány; a Make- és n8n Cloud-kapcsolatokat ehhez a cikkhez nem futtattuk végig.

  • Írj össze tíz fiktív megkeresést, köztük egy ismétlést és egy hiányos beküldést.
  • Rajzold fel: beérkezés → ellenőrzés → nyilvántartás → felelős → következő teendő.
  • Jelölj ki egy embert, aki naponta megnézi a feldolgozatlan tételeket.

Hat mezővel már el lehet indulni

Javasolt induló adatlap: beküldésazonosító, érkezés ideje, kapcsolattartási cím, szolgáltatás, rövid leírás és státusz. A felelős és a következő határidő a belső feldolgozás során kerülhet rá. A státusz legyen kötött lista, például új, pontosítás szükséges, feldolgozás alatt, lezárt.

A beküldésazonosító egy eseményt jelöljön. Ugyanaz az ember később másik munkára is kérhet ajánlatot; az e-mail-cím önmagában ezért nem megfelelő egyedi kulcs. Valódi személyes adatok előtt határozzátok meg, ki férhet hozzá a nyilvántartáshoz és meddig szükséges őrizni az adatokat.

Előbb a tárolás, utána az értesítés

Az értesítés nem helyettesíti a nyilvántartást. A folyamat először ellenőrizze a szükséges mezőket, majd őrizze meg az érvényes kérést. Ezután készítsen belső teendőt vagy értesítési vázlatot. Ha az értesítési szolgáltatás hibázik, a kérés akkor is visszakereshető maradjon.

Az n8n webhook külön teszt- és éles URL-t ad. A tesztcím működése nem igazolja az éles feldolgozást. A Make és az n8n is dokumentál hibakezelési lehetőségeket; a saját folyamatban ettől még külön meg kell tervezni a hibajelzést és az újrapróbálást.

Mikor maradjon kézi a megoldás?

Ha a csapat még abban sem ért egyet, mit jelent a feldolgozott ajánlatkérés, az automatizálás csak gyorsabban fogja szétszórni a bizonytalanságot. Kezdjetek egy közös táblával és két hét következetes használattal. Ez javasolt megfigyelési időszak, nem iparági küszöb.

Fizetős eszköz akkor indokolt, ha egy ismétlődő, stabil lépést vesz át, és a teljes működtetési költség belefér. A havi díj mellé számold oda a beállítást, a hibák javítását és azt is, ki veszi át a rendszert, ha te nem vagy elérhető.

Indulás előtti ellenőrzés

A sablontárban található mintákon próbáld ki a folyamatot. Csak akkor élesíts, ha az alábbi helyzetek eredménye egyértelmű, és van dokumentált kézi visszaállási út.

  • Ugyanaz a beküldés kétszer érkezik: nem keletkezik második teendő.
  • Hiányzik a kötelező mező: javítandó tétel keletkezik, nem kitalált adat.
  • Leáll az értesítés: az ajánlatkérés megmarad és a hiba látható.
  • Újraindul a folyamat: a korábbi feldolgozási állapot nem vész el.

Források

Melyik megoldás illik hozzád?

Válaszolj három kérdésre a mostani ajánlatkérés-kezelésedről.

Segíts az eszközválasztásban →

Kiszámolom a saját költségeimet ↗