Balionline · LLL célleírás

Verification and Constraints

READY FOR REVIEW

Minden weboldali ajánlatkérésből egy jól használható CRM-kérés készüljön, amelyen látszik a beküldés oldala és űrlaphelye, az érdeklődés típusa és az összes megadott utazási adat.

2026.09.28. · új CRM javítási körVégrehajtó még nincs elindítva

Cél és kész állapot

Cél: Minden weboldali ajánlatkérésből egy jól használható CRM-kérés készüljön, amelyen látszik a beküldés oldala és űrlaphelye, az érdeklődés típusa és az összes megadott utazási adat.

A kész állapot: Az ügyintéző az Ajánlatkérések listából megnyit egy beérkezett kérést, és külön feliratozott mezőkben látja a Forrásoldal URL-je, Űrlap helye, Érdeklődés típusa, Kiválasztott út, Tervezett időszak, Balin töltött éjszakák, Utasok, Költségkeret és Szállásigény adatokat ott, ahol az adott űrlap gyűjti őket. A kérés a megfelelő partnerhez kapcsolódik. Egy beküldés egy munkában használt kéréshez és egy teljes belső értesítéshez vezet. Az éles, robotellenőrzéssel védett beküldések tesztje ezt bizonyítja.

0 / 18bizonyított kritérium

5ellenőrizhető kimenet

4kivizsgálandó kérdés

Rögzített elvárások

A CRM-adatlapon látszik a Forrásoldal URL-je és az Űrlap helye: hero-form, oldalsó-form vagy alsó-form.

A gyűjtőoldal hero űrlapja konkrét út nélkül Általános érdeklődés. Az év, szöveges időszak és éjszakaszám külön érték.

Bizonyítás: tényleges webes beküldés után CRM-kép + mentett adat + kézbesített értesítés. A képet egy független Luna High agent csak a kép alapján írja le.

Mi biztos és mi nyitott?

MEGERŐSÍTETT: Matt pontosítása: a csoportos utak gyűjtőoldalának hero űrlapja konkrét út kiválasztása nélkül is általános érdeklődést fogad. A vizsgált ügyfél csak a 2027-es évet adta meg.

MEGERŐSÍTETT: Matt kéri: a CRM-ben mentett landing URL és a hero-form / oldalsó-form / alsó-form azonosító legyen látható.

MEGERŐSÍTETT: A szeptember 28-i olvasás weboldali és E-mail forrású, ugyanazon partnerhez kapcsolt rekordot talált. Az e-mailes rekord létrehozásának kézi vagy automatikus eredete nincs igazolva.

MEGERŐSÍTETT: A híd csak pontos YYYY-MM-DD dátumot tesz a dátummezőbe. Szöveges időszak a leírásba kerül. Az általános CF7 6 űrlap nem kér időpontot. Két azonos leírású webes rekord is létezik, létrejöttük oka még nyitott.

NYITOTT: A ténylegesen működő oldalak és elhelyezések teljes listáját a végrehajtó az élő oldalakon készíti el. A CF7 azonosító önmagában nem különbözteti meg ugyanazon űrlap több elhelyezését.

FELTEVÉS: Egyetlen jól olvasható Ajánlatkérés-adatlap elegendő a napi ügyintézéshez. Az e-mail eredeti tartalma megmaradhat kapcsolódó kommunikációként, ha nem keletkezik belőle még egy új munkában lévő kérés.

MEGERŐSÍTETT: Új nyilvános GET-olvasás: a gyűjtőoldalon CF7 1253 form_csoportos és CF7 511 form_global_contact is megjelenik. Utóbbi chat-widgetben van. A korábbi öt CF7-típus listája nem teljes elhelyezési inventory.

A kész rendszer és az odavezető út

Zöld: megerősített · Rózsaszín: feltevés · Szaggatott: nyitott, még nem bizonyított

End goal system · Így működjön

flowchart TD
 H["Gyűjtőoldal hero
Konkrét út nélkül
általános érdeklődés"]:::confirmed
 T["Konkrét út oldala
A kiválasztott út neve
és jóváhagyott dátuma"]:::confirmed
 F["Oldal és űrlaphely
Landing URL és pontos
űrlapelhelyezési érték"]:::confirmed
 Q["Egy olvasható CRM-kérés
Típus, időszak és igények
külön mezőkben"]:::open
 P["Kapcsolódó partner
Az új igény külön
kérésként megmarad"]:::open
 E["Egy teljes értesítés
A munkában kezelt
kéréshez kapcsolódik"]:::open
 H --> F
 T --> F
 F --> Q
 Q --> P
 Q --> E
 classDef confirmed fill:#E8F5E9,stroke:#2E7D32,color:#173B25
 classDef assumption fill:#FCE4EC,stroke:#C2185B,color:#5B1430
 classDef open fill:#FFFFFF,stroke:#94A3B8,color:#475569,stroke-dasharray:5 5

Route to the end state · Ezen az úton

flowchart LR
 A["Ügyintéző
Időszak és típus
nehezen áttekinthető"]:::confirmed
 B["Weboldal
Egy technikai form
több helyen lehet"]:::assumption
 C["CRM és e-mail
A második rekord
létrehozásának oka nyitott"]:::open
 R["Célleírás áttekintése
Kimenetek és tesztek
ellenőrzése"]:::open
 L["Launch után végrehajtás
Inventory, javítás
és védett webes tesztek"]:::open
 V["Tényleges felületi bizonyíték
Kép és képleírás
plusz mentett adat"]:::open
 Z["Használható beérkező kérés
Forrás, igény és
értesítés bizonyítva"]:::open
 A --> R
 B --> R
 C --> R
 R --> L --> V --> Z
 classDef confirmed fill:#E8F5E9,stroke:#2E7D32,color:#173B25
 classDef assumption fill:#FCE4EC,stroke:#C2185B,color:#5B1430
 classDef open fill:#FFFFFF,stroke:#94A3B8,color:#475569,stroke-dasharray:5 5

Ezt kell látni egy CRM-kérésen

Felület: QlickCRM → Ajánlatkérések → megnyitott adatlap. Az alábbi táblázat egy tesztbeküldés elvárt eredménye, nem jelenlegi CRM-képernyőkép.

Forrásoldal URL-je	https://balionline.hu/csoportos-utak-gyujtooldal/
Űrlap helye	hero-form
Érdeklődés típusa	Általános érdeklődés
Kiválasztott út	Nincs kiválasztva
Tervezett időszak	2027. július közepe
Balin töltött éjszakák	10
Utasok	2
Költségkeret	1 100 000 Ft / fő
Szállásigény	4–5 csillagos
Élmények	Tengerpart és pihenés, Természet és kaland, Kultúra és városok
Üzenet	A teljes beküldött egyéb kérés

Mit fogunk látni és tesztelni?

A pipákhoz tényleges bizonyíték kell

D1 · Mutasd meg a beküldés forrását

Az ügyintéző lássa, pontosan melyik oldal és melyik űrlaphely hozta az érdeklődőt.

0 / 4

Kritériumok, megőrzendő feltételek és bizonyítékok

C01 Amikor az összes aktív ajánlatkérő oldal asztali és telefonos felületét bejárod, akkor az inventory.md minden tényleges oldal + űrlapelhelyezés sorához rögzíti az URL-t, CF7 azonosítót, látható elhelyezést, gyűjtött mezőket és ténylegesen beadható értékeket, valamint a CRM-be vezető útját. A megfelelő helyeken pontosan hero-form, oldalsó-form vagy alsó-form szerepel. A CF7 511 chat-widget külön sor és saját, pontos elhelyezés, nem valamelyik kért értéknek álcázva. Az ajánlatkérést vagy CRM-érdeklődőt létrehozó összes aktív sor szerepel a későbbi tesztlistában. A többi kapcsolatfelvételi felület kizárásának oka is látszik.

Itt ellenőrizhető: inventory.md és az élő weboldal

Bizonyíték és képernyőkép

Teljes elhelyezési tábla, minden elhelyezés képernyőképe, teszteset-hivatkozás.

C01 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C02 Amikor a csoportos-utak-gyujtooldal hero űrlapját kitöltöd külön tesztjelöléssel, konkrét út kiválasztása nélkül, akkor a hozzá tartozó Ajánlatkérés-adatlapon a Forrásoldal URL-je mező a https://balionline.hu/csoportos-utak-gyujtooldal/ URL-t, az Űrlap helye mező pedig pontosan a hero-form értéket mutatja.

Itt ellenőrizhető: QlickCRM → Ajánlatkérések → beküldés adatlapja

Bizonyíték és képernyőkép

Tényleges webes beküldés, CRM-adatlap képe, mentett rekord API-visszaolvasása.

C02 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C03 Amikor egy létező oldalsó és egy létező alsó űrlapból külön kérést küldesz az inventory szerinti oldalon, az egyiken ?utm_source=lllqa&utm_campaign=crm-forras paraméterrel, akkor mindkét CRM-adatlap a saját oldalának URL-jét mutatja, az Űrlap helye értékek rendre oldalsó-form és alsó-form. A kampányparaméteres teszt mentett és újranyitott CRM-adatlapján a Forrásoldal URL-je mező a teljes tesztelt oldal-URL-t tartalmazza a ?utm_source=lllqa&utm_campaign=crm-forras paraméterekkel, amit az API-visszaolvasás is megerősít.

Itt ellenőrizhető: QlickCRM → az adott két Ajánlatkérés-adatlap

Bizonyíték és képernyőkép

Két tényleges beküldés, két CRM-kép, API-visszaolvasás. Ha valamelyik elhelyezés valóban nem létezik, ezt a teljes inventory igazolja, és a többi létező elhelyezés mind tesztelt. Új elhelyezés létrehozása ezért nem szükséges.

C03 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C04 Amikor ugyanazt a technikai űrlapot két külön oldalról vagy elhelyezésről küldöd be, majd újranyitod a CRM-adatlapokat, akkor mindkettőn tartósan a saját URL és saját elhelyezés látszik, és az eredmények nem írják felül egymást. Az összes inventory-sorhoz létezik sikeres forrásazonosítási eredmény.

Itt ellenőrizhető: QlickCRM → Ajánlatkérések és inventory.md

Bizonyíték és képernyőkép

Összes sorhoz beküldési és rekordazonosító, friss újranyitási kép, provider visszaolvasás.

C04 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

Megőrzendő feltételek

✕ A hero-form, oldalsó-form és alsó-form értékeket a tényleges elhelyezésből állapítsd meg. Ne következtesd csak a CF7 azonosítóból, és ne rendelj minden kéréshez hero-form értéket.
✕ Őrizd meg annak a weboldalnak a böngészőben látható URL-jét és normál kampányparamétereit, amelyen a beküldés történt, nem a munkamenet legelső belépőoldalát. Ne cseréld canonical URL-re, ha az elveszíti a lekérdezési paramétereket. A cél URL ne CRM-belépőoldal, CF7 REST végpont vagy köszönőoldal legyen. Más oldalon történt beküldéshez ne ments hibás alapértékként kezdőlapi URL-t. A kezdőlapon történt beküldéshez viszont a tényleges kezdőlapi URL-t mentsd. Hiányzó történeti forrást ne találj ki.

D2 · Különítsd el az érdeklődés típusát

Egy általános érdeklődő és egy konkrét csoportos út jelentkezője a megfelelő megnevezéssel és időszakkal érkezzen.

0 / 4

Kritériumok, megőrzendő feltételek és bizonyítékok

C05 Amikor a gyűjtőoldal hero űrlapján általános érdeklődést küldesz 2027. július közepe időszakkal, 10 Balin töltött éjszakával és 2 utassal, konkrét út nélkül, akkor a CRM-adatlapon az Érdeklődés típusa Általános érdeklődés, a Kiválasztott út Nincs kiválasztva, a Tervezett időszak 2027. július közepe, a Balin töltött éjszakák 10 és az Utasok 2. Az értesítés és adatlap címe Általános érdeklődés vagy Csoportos utak – általános érdeklődés szöveggel jelzi a típust, és nem állít kiválasztott konkrét utat.

Itt ellenőrizhető: Weboldal hero űrlap → QlickCRM-adatlap és kézbesített belső e-mail

Bizonyíték és képernyőkép

Kitöltött élő űrlap és CRM képei, API-visszaolvasás, tényleges kézbesített e-mail privát bizonyítéka.

C05 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C06 Amikor egy konkrét csoportos út részletoldalának ajánlatkérőjét beküldöd külön jelöléssel, akkor a CRM-adatlap Konkrét csoportos út érdeklődést, az oldal tényleges útnevét és az út jóváhagyott indulási dátumát vagy dátumtartományát mutatja külön mezőkben. Az értesítés ugyanazt az utat és időpontot tartalmazza. A konkrét út hozzárendelése csak a beküldő által ténylegesen kiválasztott vagy a formon egyértelműen jelzett úthoz történik. Egy általános chat vagy kapcsolatfelvétel nem válik konkrét úttá pusztán az oldal címe miatt. Ha nincs jóváhagyott pontos dátum, az ellenőrzött szöveges időszak vagy a Nincs megadva érték látszik, kitalált dátum nélkül.

Itt ellenőrizhető: Konkrét út weboldala → QlickCRM-adatlap és belső e-mail

Bizonyíték és képernyőkép

Az út aktuális, jóváhagyott dátumforrása, élő oldal és CRM képe, mentett adatok, kézbesített e-mail.

C06 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C07 Amikor egy általános vagy egyéni űrlapon csak 2027-et írsz az időszakhoz, vagy azt jelzed, hogy még rugalmas az időpont, akkor az élő űrlap érthetően lehetővé teszi a hónap/időszak megadását vagy a rugalmasság jelzését. A CRM az eredetileg megadott évet vagy a rugalmas státuszt őrzi meg, nem mutat kitalált napot. A szöveges időszak akkor is látható, ha a technikai dátummező üres.

Itt ellenőrizhető: Élő űrlap és QlickCRM-adatlap

Bizonyíték és képernyőkép

Éves és rugalmas esetek formaképe, CRM-kép és mentett mezők visszaolvasása. Év-only esetet ne tekints adatvesztésnek.

C07 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C08 Amikor az egyéni, esküvő/nászút és céges ajánlatkérőt külön tesztadatokkal beküldöd, akkor a CRM-adatlap és kézbesített értesítés mindhárom esetben az adott érdeklődés típusát és az eredetileg megadott pontos dátumot vagy szöveges időszakot mutatja. Egyéni igény nem Csoportos Ajánlatkérés címként jelenik meg.

Itt ellenőrizhető: A három élő űrlap → QlickCRM és belső e-mail

Bizonyíték és képernyőkép

Mindhárom típushoz webes és CRM-kép, visszaolvasás, kézbesített e-mail.

C08 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

Megőrzendő feltételek

✕ A gyűjtőoldal hero űrlapján megadott időszakból és élményválasztásból ne találj ki konkrét utat. A Zsuzsinak adott pontosítás az irányadó.
✕ A szöveges időszakot és az éjszakaszámot külön kezeld. Évből vagy hónapból ne gyárts pontos indulási dátumot, és ne jeleníts meg 1970-01-01 alapértéket valós utazási dátumként.

D3 · Tedd olvashatóvá a CRM-adatlapot

Az ügyintéző egyetlen ajánlatkérésen lássa a munkához szükséges adatokat, hosszú e-mailből való keresgélés nélkül.

0 / 3

Kritériumok, megőrzendő feltételek és bizonyítékok

C09 Amikor a C05 kérésnél a tényleges élő mezőkön megadsz költségkeretet, szállásigényt, elérhető élményválasztásokat és külön egyéb kérést, majd az Ajánlatkérések listából megnyitod, akkor az adatlap olvasható címet és külön feliratozott URL, űrlaphely, típus, időszak, éjszakaszám, utasok, keret és annak Ft/fő egysége, szállásigény, élmények és teljes üzenet mezőket mutat. Az adatokhoz nem kell HTML e-mailből keresni.

Itt ellenőrizhető: QlickCRM → Ajánlatkérések lista és megnyitott adatlap

Bizonyíték és képernyőkép

Lista- és adatlapképek, mezőnkénti összevetés a tényleges beküldött adatokkal, API-visszaolvasás. A konkrét beadható értékeket az inventory rögzíti, például 1 100 000 Ft/fő csak akkor tesztérték, ha a mező ezt valóban elfogadja. Az élményválasztások száma az élő mező lehetőségeit követi. A tesztpélda miatt önmagában ne bővítsd az űrlap üzleti választékát.

C09 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C10 Amikor olyan űrlapról küldesz kérést, amely nem kér költségkeretet vagy éjszakaszámot, majd megnyitod az adatlapot, akkor a hiányzó adatok Nem megadott vagy Nem kért állapottal látszanak, a rendelkezésre álló adatok pedig megmaradnak. Nincs 0, idegen tesztérték vagy kitalált időpont valós ügyféligényként feltüntetve.

Itt ellenőrizhető: QlickCRM → az adott Ajánlatkérés-adatlap

Bizonyíték és képernyőkép

Élő űrlap és CRM-kép, negatív adatellenőrzés és provider visszaolvasás.

C10 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C11 Amikor egy új tesztpartner, majd ugyanaz a partner két eltérő utazási igénnyel küld be valódi új kéréseket, akkor az új érdeklődő partnerként megjelenik, későbbi kérései ugyanahhoz a megfelelő partnerhez kapcsolódnak. Mindkét kérés saját időszaka és utazási adatai külön megmaradnak a CRM-ben. A partner adatlapján a beküldött név, e-mail és telefonszám a gyűjtött mezők szerint helyesen olvasható, az új partnernél nincs elveszett kapcsolati adat. Meglévő partner értékes adatait üres beküldött mező nem törli.

Itt ellenőrizhető: QlickCRM → Partnerek és a kapcsolódó Ajánlatkérések

Bizonyíték és képernyőkép

Partnerképek, kapcsolódó kérések képei és partner/rekord visszaolvasás. A beküldött név/e-mail/telefon mezőnkénti összevetése a látható partneradatlappal és API-visszaolvasással, valamint az ajánlatkérés partnerhivatkozásával.

C11 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

Megőrzendő feltételek

✕ A partner kapcsolati adatai és az ajánlatkérésenként változó igények maradjanak külön. Egy új kérés ne írja felül a partner korábbi kérésének utazási adatait.
✕ Az adott űrlapon meg nem kérdezett vagy meg nem adott értéket ne találj ki. A teljes eredeti üzenetet őrizd meg. A technikai azonosító maradjon visszakereshető, de ne uralja az adatlap címét.

D4 · Számold helyesen a beérkező kéréseket

Egy beküldésből egy munkában kezelt kérés és egy teljes belső értesítés legyen. Egy későbbi új érdeklődés maradjon új kérés.

0 / 3

Kritériumok, megőrzendő feltételek és bizonyítékok

C12 Amikor egy egyedi jelölésű kérést az élő honlapról egyszer küldesz be, és követed a webes és e-mailes beérkezési útját, akkor a QlickCRM Ajánlatkérések alatt egy új munkában kezelt adatlap jelenik meg, a belső postaládában egy teljes ajánlatkérési értesítés érkezik. Az esetleges kapcsolódó e-mail kommunikáció ugyanahhoz a kéréshez tartozik, nem második új feladatként szerepel.

Itt ellenőrizhető: Élő weboldal → QlickCRM Ajánlatkérések lista és tényleges belső postaláda

Bizonyíték és képernyőkép

Beküldési azonosító, létrejött rekordok és értesítések számlálása, CRM-listakép, postaládakép/fejlécek privát bizonyítéka, e-mail feldolgozási szabály feltárt eredete.

C12 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C13 Amikor ugyanazt a logikai beküldést gyors dupla kattintással, hálózati újrapróbálással és háttérfeldolgozás újrapróbálásával külön-külön teszteled, akkor esetenként egy munkában kezelt CRM-kérés és egy teljes belső értesítés marad. Sikertelen kézbesítést a rendszer biztonságosan újra tud próbálni anélkül, hogy az igény elveszne vagy megduplázódna.

Itt ellenőrizhető: Élő űrlap, QlickCRM, postaláda és gépi tesztkimenet

Bizonyíték és képernyőkép

Három konkrét ismétlési teszt eredménye, kérés/értesítés számlálás, CRM-képek. A teszt definiálja ugyanazon esemény és későbbi új beküldés határát. Ugyanazon logikai esemény stabil beküldési azonosítóval követhető a webes, CRM- és e-mail-útvonalon. A gyors dupla kattintást két kliensoldali kérésként is próbáld, mert a jelenlegi két rekord külön UUID-t kapott. A számlálás a feltárt tényleges feldolgozási/újrapróbálási időablak lezárása után történjen, az időablakot és a feldolgozási végállapotot jegyezd fel.

C13 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C14 Amikor ugyanaz a tesztpartner két szándékos új kérést küld be, majd külön esetben két azonos tartalmú, de újonnan indított és külön beküldött igényt küld, akkor mindkét tesztesetben két külön új Ajánlatkérés és két megfelelő értesítés jelenik meg, egy meglévő partnerhez kapcsolva. Az ismétlési védelem nem nyeli el az új beküldési eseményt azonos e-mailcím vagy azonos tartalom miatt.

Itt ellenőrizhető: QlickCRM → partner és Ajánlatkérések, belső postaláda

Bizonyíték és képernyőkép

Két külön beküldési azonosító, két adatlap képe, mentett kapcsolatok és két értesítés.

C14 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

Megőrzendő feltételek

✕ Az e-mailes rekord eredetét előbb bizonyítsd. Ne tételezd fel automatikus e-mail importnak, és ne állíts le általános kommunikációt vagy működő CRM-szabályt a pontos hatókör ellenőrzése nélkül.
✕ Ne szűrj minden azonos e-mailcímet duplikátumnak. Valódi új igény, eltérő időszak vagy későbbi külön beküldés maradjon meg. Valós történeti rekordokat ne törölj bizonyíték és visszaállítási út nélkül.

D5 · Bizonyítsd a teljes éles működést

A honlapból induló, védett beküldések és a CRM-ben való olvashatóság együtt igazolják a kész állapotot.

0 / 4

Kritériumok, megőrzendő feltételek és bizonyítékok

C15 Amikor az inventory minden aktív ajánlatkérő elhelyezését bekapcsolt CAPTCHA-val, eltérő ellenőrzött tesztadatokkal beküldöd asztali és telefonos nézetben, akkor minden sorhoz sikeres webes visszajelzés, megfelelő CRM-adatlap, partnerkapcsolat és teljes kézbesített értesítés bizonyított. A forrás, típus, időszak és összes megadott mező összevetése sikeres.

Itt ellenőrizhető: Élő weboldalak desktop/telefon, QlickCRM, postaláda és test-matrix.md

Bizonyíték és képernyőkép

Minden sorhoz védett sikeres beküldés, képernyőképek és független képleírás, API és kézbesítési eredmény. API-val közvetlenül létrehozott rekord nem helyettesíti a honlapi tesztet.

C15 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C16 Amikor a honlapi hírlevél-űrlapot bekapcsolt CAPTCHA-val új és már feliratkozott tesztcímmel beküldöd, akkor a honlap sikeres visszajelzést ad, az új cím a QlickCRM Marketing → Balionline weboldal feliratkozók listában egyszer megjelenik, az ismétlés nem hoz létre második feliratkozót. Az ajánlatkérő hírlevéljelölése is csak a megadott hozzájárulást követi.

Itt ellenőrizhető: Élő hírlevél-űrlap, ajánlatkérő és QlickCRM Marketing feliratkozólista

Bizonyíték és képernyőkép

Védett sikeres és ismételt webes teszt, lista képe és provider visszaolvasás, hozzájárulási esetek. Az ajánlatkérő checkbox külön friss tesztcímmel bejelölt és üres állapotban is tesztelt. Üres checkbox nem hoz létre új feliratkozást, és nem szünteti meg a már korábban meglévőt.

C16 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C17 Amikor befejezed a pozitív látogatói teszteket, majd hiányzó vagy érvénytelen CAPTCHA-tokennel próbálsz beküldeni, akkor a szerver elutasítja a védtelen ajánlatkérést és hírlevél-feliratkozást, új rekord és értesítés nem keletkezik. Minden ideiglenes tesztkivétel megszűnt, az eredeti védelem működik.

Itt ellenőrizhető: Beküldési válasz és QlickCRM/postaláda számlálás

Bizonyíték és képernyőkép

Szerveroldali negatív teszt mindkét végponton, visszaállítási fájl/konfiguráció összehasonlítás, pozitív védett teszt C15/C16 szerint.

C17 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

C18 Amikor a végrehajtó lezárja az ellenőrzést, akkor a jelen board csak bizonyított kritériumokat jelöl zölden, minden sorhoz bizonyíték van. Az executor-handoff.md megnevezi az elkészült, hibás és nem tesztelt részeket, az ismert történeti adathiányok kezelését és a javítás utáni WhatsApp-válasz elküldetlen tervezetét. Korábbi kész UI-elemek alapellenőrzése nem talál regressziót.

Itt ellenőrizhető: Ez a Verification and Constraints board, executor-handoff.md és az élő oldal

Bizonyíték és képernyőkép

Teljes tesztmátrix, privát bizonyítéktár, nyilvános anonimizált bizonyítékok. Repülőkártyák, út-sorrend, keret/éjszaka mezők és április 5–19 út képelhelyezésének rövid regressziós ellenőrzése.

C18 · A tényleges felület képe még nincs csatolva. Képleírás: nincs. Kritériummal való összevetés: nincs.

Állapot: NEM ELLENŐRZÖTT. Végrehajtás utáni bizonyíték szükséges.

Megőrzendő feltételek

✕ A CAPTCHA megkerülésével végzett teszt nem teljes látogatói útvonal bizonyítéka. Matt előbb számítógépes megoldást, majd szükség esetén ideiglenes kikapcsolást és pontos visszaállítást engedélyezett. Éles kész állapot csak visszaállított szerveroldali ellenőrzéssel igazolható.
✕ Ne küldj ügyfél WhatsApp-üzenetet vagy hírlevélkampányt. A teszteket egyértelműen jelöld, ne nyiss újra már archivált tesztkéréseket, és a nyilvános boardra ne tegyél személyes adatot vagy hozzáférést.
✕ Minden GUI-kritériumhoz tényleges teszt utáni képernyőkép, független gpt-6-luna high agent vak képleírása és a végrehajtó kritériummal való összevetése kell. A képleíró csak a képet kapja, elvárt kimenetet nem. Az executor szülője ellenőrzi az eltéréseket. E bizonyítékok nélkül GUI-sor nem igazolt. A nyilvános képből maszkolj személyes adatot, privát eredeti megmarad.

Kivizsgálandó kérdések

O1 · Melyik aktív oldalakon melyik űrlapelhelyezés létezik?

Élő asztali/telefonos inventory, DOM és tényleges beküldések. Nincs szükség új ügyfélkérdésre, ha az oldalból megállapítható.

O2 · Mi hozza létre az E-mail forrású második adatlapot és a két azonos webes rekordot?

Egy jelölt új beküldés, CRM szabályok, kézbesített e-mail fejlécek és feldolgozási napló. A kézi és automatikus létrehozást különítsd el.

O3 · Mely CRM mezőtípus és elrendezés tartja láthatóan a szöveges időszakot és a forrást?

Jelen tenant mezőmetaadatai és valódi felületi próba. A végrehajtó választ, feltéve hogy a kritériumok változatlanul teljesülnek.

O4 · A chat-widget és más, a három kért helyen kívüli kapcsolatfelvételi űrlap hogyan azonosítható?

Az inventory ezeket is külön feltünteti. A hero-form / oldalsó-form / alsó-form értékeket ne rendeld tévesen popuphoz vagy chathez. Ha CRM-be hoz létre érdeklődőt, a saját tényleges form-azonosítóját és landing URL-jét őrizd meg, külön olvasható felirattal. A három kért elhelyezés kritériumait ettől ne gyengítsd.

Jogkör és határok

A végrehajtó a weboldali űrlapok, WordPress–CRM kapcsolat, ide tartozó CRM mezők/elrendezés és az igazolt e-mailes beérkezési szabály javítását, élesítését és tesztjét végzi. A technikai megoldást maga választja, szűk visszaállítási út mellett.

Megőrzi a valós érdeklődőket és a korábbi kész javításokat. Történeti adatokhoz csak az eredeti beküldésből vagy jóváhagyott útadatból pótol értéket.
Nem küld ügyfélüzenetet vagy kampányt, nem változtat kereskedelmi feltételeket. A Facebook javítása nem része a körnek.
A board nyilvános, belépés nélküli URL. Ügyféladatok, jelszavak és teljes e-mail bizonyítékok a privát bizonyítéktárban maradnak.
A teljes feladat költségkerete legfeljebb 15 USD. Új biztonsági réteget nem ad hozzá. A meglévő CAPTCHA pontos helyreállítása és ellenőrzése kötelező.

Parent ↔ child messages

PARENT · cél pontosítva2026.09.28.

Matt a landing URL és a három űrlapelhelyezés mentését kérte. A Zsuzsinak írt hero-űrlap magyarázata beépült. Az előkészítés kész, éles javítás ebben a körben még nem történt.

Executor: még nincs. Következő munkapont: a célleírás emberi áttekintése.

Parent read set

A végrehajtó külön menti a deliverables.md, main-prompts.md és session.json fájlokat. Lezáráskor a board, a tiszta gist és az executor-handoff.md az első olvasandó anyag. Ezek majd a végrehajtáskor jönnek létre.

Recovery state

Nincs futó executor, nincs végrehajtási hiba. A képek helye üres, a kritériumok ellenőrizetlenek. A megvalósítás következő állapota: Launch után egy önálló végrehajtó.