Balionline · finish the website and CRM

U01 · On the live collection hero, show “CSOPORTOS UTAK ÉS SZEMÉLYES TERVEZÉS”, H1 “Válassz csoportos utat, vagy kérj saját útitervet.” with “saját útitervet.” in orange, and card title “Add meg az igényeidet, és keresünk az opciókkal!”. Make the card title smaller and legible without shrinking the H1.

Verification: Check exact DOM text and loaded style at 1440×1000, 1085×1174, 1019×1164 and 390×844. Compare the card title with the rejected version and retain usable postdeployment images.

U02 · “ELŐRE MEGTERVEZETT UTAK” reaches the trip list. “EGYEDI ÚTITERVET KÉREK” reaches and focuses the hero form. Under them show “Átbeszéljük az elképzeléseidet, és személyre szabott tervet adunk a kívánt időpontra, tempóra és programokra.”

Verification: Activate both controls by mouse and keyboard on the live page and inspect the destinations and exact supporting copy.

U03 · Restore the original hero background, layers, position and responsive spacing. At two-column widths the text and form start together, within 2 CSS pixels. At 1019×1164 the H1 and supporting paragraph align left with the CTA column. Remove the newly introduced empty space below the content. Mobile has a logical stacked layout and no horizontal overflow.

Verification: Compare with the actual pre-change source, not the rejected screenshot. Record restored values, computed padding/background/alignment and postdeployment views at the four U01 sizes.

U04 · Use the existing Protest Riot heading style for the H1, card title and “Milyen élményeket keresel?”. Body and fields use existing Open Sans. Keep Poppins only in its existing roles. TOVÁBB and submit buttons match the main hero CTA in font, color, height, padding, corners and interaction style.

Verification: Check loaded fonts, computed button styles, hover/focus and working controls across all three steps. Check two untouched sections for regression. Different button widths due to wording are acceptable.

U14 · On the collection and 10-night trip pages, the chat panel grows from its button with the original morph/grow opening and closing motion, including the actual header and bottom-right variants. Chat remains usable.

Verification: Compare original CSS/JS and capture a short live recording or timestamped sequence of opening and closing. Check message delivery through the controlled QA route. Keep existing reduced-motion behavior.

U05 · Step 1 has the three experience choices, Kikkel utaznál?, and native dropdowns for Utasok száma and Balin töltött éjszakák. Passengers are exact integers 1–99 with a required empty “Válassz” start. Night options are 7-8, 9-10, 10-14 and 14+. Values survive Back/Next. Two passengers stay 2 and ranges remain ranges in CRM and notification.

Verification: Inspect selects and options. Test empty passenger validation and step retention. Submit 9-10 and 14+ cases from the website, then compare CRM and delivered QA email. Never infer a passenger count or turn a range into an invented exact number.

U06 · Step 2 contains current seasons, an optional more precise period or flexibility, accommodation, and a flight-inclusive budget in Ft/fő with “*a repülőjeggyel együtt”. Preserve the meeting budget range 800 000–1 600 000, step 50 000 and initial 1 200 000.

Verification: Choose a valid current season, “2027. július közepe”, 4–5-star accommodation and 1 200 000 Ft/fő. Check Back/Next, displayed amount and exact CRM/email values. Generate future seasons appropriately, do not freeze all options to 2027.

U07 · The paragraph beginning “Általában legalább 7 éj / 8 nap Balin” and its leftover blank space are absent. The Bali-night label remains clear.

Verification: Inspect steps 1 and 2 and check the removed text is absent from the form DOM.

U08 · Step 3 has no “Elérhetőségek” heading. Name occupies a full row, E-mail and Telefonszám are side by side on desktop and stacked on mobile, and “Kérdés, kérés:” is a fourth, optional full-row field.

Verification: Check at 1440, 1085, 808 and 390 CSS pixels. Type in the question, move Back/Next and verify retention. An empty question must not block submission.

U09 · The existing CAPTCHA and required form privacy controls fit fully inside the white card and remain usable without clipping or page overflow.

Verification: Read the actual existing CAPTCHA provider and mode. Inspect step 3 at the U08 widths. If that actual integration is invisible, document this fact rather than adding a new widget. Positive and negative functioning is verified under M15–M17.

U10 · Site-wide cookie banners, settings buttons and preference dialogs remain temporarily absent. All measurement-consent gates remain temporarily disabled until Matt chooses to restore them. Existing page-view and successful-submit events run without a cookie click and without duplicates. “Igények összegzése” is absent. Form privacy, newsletter opt-in and CAPTCHA retain their own behavior.

Verification: Check fresh, previously accepting and previously rejecting states across distinct page templates. Inspect relevant frontend and existing server measurement paths, network/provider events, and one real successful form event. Preserve exact backups and re-enable instructions. Do not invent visitor consent or automatically turn cookie gating back on.

U11 · Missing or invalid required name/email/phone produces clear validation. A valid website submission shows actual success and transfers every form value, including Kérdés, kérés:, to the CRM card and one received notification. There is no demo alert.

Verification: Run invalid and valid website cases, correlate submission ID with CRM readback and accessible QA inbox, and check for JavaScript errors. Record whether CAPTCHA was enabled or temporarily disabled.

U12 · The live collection page remains available at its public URL and displays the working three-step form. Every production change has a narrow backup, provider readback and practical restore path.

Verification: Fresh anonymous HTTP 200, postdeployment behavior, exact changed-source readback and hashes. Use the proven WordPress code/provider route. A reversible fixture can verify rollback logic without needlessly rolling back healthy production.

U13 · All earlier and latest UI annotations have an explicit result on this board. Material visual defects are fixed and checked again after deployment.

Verification: Run the required Luna section screenshot/fix/fresh-QA loop for changed website areas. Include desktop, mobile and 1019×1164. Reuse valid evidence for untouched areas. U14 needs motion proof and U10 needs measurement proof, not only still images.

M01 · The inventory lists each live page/form placement with URL, CF7 ID, collected fields, real available values and destination. Labels are hero-form, oldalsó-form or alsó-form only where those placements actually exist. Chat has its own truthful label.

Verification: Refresh the existing 23-placement inventory only where changed. Include all routes creating enquiries and explain exclusions. Do not build a nonexistent side form merely to satisfy a test fixture.

M02 · A general enquiry from the collection hero appears in QlickCRM → Ajánlatkérések with its actual submission-page URL in “Forrásoldal URL-je” and exactly “hero-form” in “Űrlap helye”.

Verification: Submit from the live hero, reopen the CRM card and compare the visible fields with website state and provider readback.

M03 · Every tested real side/bottom form shows its own page and exact placement. A campaign-tagged submission preserves the complete URL, including normal query separators, as readable, copyable and usable data on the reopened CRM card. Implement an automatic workaround if the current writer corrupts it.

Verification: Test an existing placement with ?utm_source=lllqa&utm_campaign=crm-forras plus an encoded query-value fixture. Compare captured URL, saved source, reopened field, copied value and link target. Verify all query keys/values survive. Distinguish harmless API/HTML serialization from literal corruption in the visible or copied URL. A shortened URL, lost query, manual per-lead edit or broken %26 separator is not a pass.

M04 · Submissions from different pages or placements keep their own URL and form label, even when they share a technical form. A later submission never overwrites an earlier request’s source.

Verification: Use two actual locations of a shared form, or two different forms if none is shared. Reopen both records. The coverage matrix contains a successful website-origin source-mapping result for every active placement.

M05 · A hero enquiry with “2027. július közepe”, 9-10 nights and 2 passengers shows “Általános érdeklődés”, “Kiválasztott út: Nincs kiválasztva”, and those separate period/night/passenger values. Its title and received notification identify a general enquiry, not an invented specific trip. The separate 14+ case retains 14+.

Verification: Compare filled website, reopened CRM card, provider values and delivered QA notification. Keep period and nights separate.

M06 · A trip-specific enquiry shows the actual selected or clearly indicated trip name and approved departure date/range. It is labelled “Konkrét csoportos út”. General chat does not become trip-specific just because it appears on a trip page.

Verification: Submit from a real trip page. Compare the approved trip source, visible form, CRM and notification. If there is no exact approved date, show the verified text or “Nincs megadva”, never invent a date.

M07 · A year-only or flexible-period enquiry keeps exactly that meaning in the form and CRM. Staff can see the entered text even when a technical date field is empty. No invented day or 1970 date is presented as the requested travel date.

Verification: Submit year-only and flexible cases. Check the opened card and raw values separately from any formatted API defaults.

M08 · Individual, wedding/honeymoon and company requests each show their correct enquiry type and supplied period in the CRM card and delivered notification. An individual request is not headed “Csoportos Ajánlatkérés”.

Verification: Submit distinct website examples for all three form types and compare type, period and collected fields across website, CRM and QA inbox.

M09 · The Ajánlatkérések list has a readable title. On the opened card staff can read separately labelled source URL, placement, type, period, nights, traveller type, passenger count, budget with its Ft/fő unit, accommodation, experiences and full message. They do not need to search inside an HTML email.

Verification: Submit distinct valid values the form actually supports, then compare each on the opened card and provider readback. Use a native supported field/description arrangement if needed. Technical IDs remain searchable without dominating the title.

M10 · Unasked or unanswered fields are empty or clearly “Nem megadott” / “Nem kért”. Other submitted values remain intact. No fabricated zero, unrelated test value or false date appears as a client preference.

Verification: Use a form that does not ask budget or nights. Compare the opened card and raw data. Empty versus null on unused fields is not itself a business defect.

M11 · A new requester becomes a partner with the supplied name, email and phone. A later request links to the same appropriate partner while both requests retain their own trip data. Empty values do not erase useful existing partner details.

Verification: Submit first and subsequent requests with changed travel details. Compare partner fields, request links and the independently retained request values in CRM and provider readback.

M12 · One logical website submission creates one actionable CRM request and one complete notification in an accessible test inbox. Related email processing does not create a second actionable enquiry. Production notification routing is restored after testing.

Verification: Use a labelled QA address/submission ID, inspect the received email including headers and count CRM records after processing settles. Temporarily reroute only synthetic QA notifications to a confirmed readable inbox. Trace any CRM email-import branch so a changed recipient does not silently bypass the suspected duplicate path. Record the restored production recipient/configuration. Direct access to the production inbox is not a prerequisite under Matt’s new instruction.

M13 · Double-clicks, network retry and background retry of the same logical submission each leave one CRM request and one complete received notification. A recoverable delivery failure is retried without losing the request.

Verification: Test the three cases separately with actual website events and controlled fault/retry where needed. Include double-clicks that would otherwise create different UUIDs. Count at the documented completed processing/retry state, not an arbitrary early moment.

M14 · Two deliberately new submissions from the same person create two requests and two notifications linked to one partner. This also holds when the two new submissions contain identical answers.

Verification: Start fresh submission events twice, first with different travel details and then with identical content. Compare separate submission IDs, CRM cards, partner links and received QA messages. Do not deduplicate by email or content alone.

M15 · The live website-to-CRM-to-notification path works for every actual form placement, with correct source, type, period, supplied values and partner link. Both desktop and mobile form behavior are verified. After any CAPTCHA exception is removed, successful protected visitor submissions prove each distinct processing path still works.

Verification: Use the existing placement matrix and minimum distinct fixtures that cover its branches. Each placement gets a website-origin submission result. Exercise each form family on desktop and mobile. Controlled CAPTCHA-off runs may prove mapping and delivery, clearly labelled. Then prove normal protected success for each distinct submission pipeline, including quote and newsletter, plus chat if separately handled. Direct CRM inserts do not replace website-origin tests. Do not repeat identical full tests solely to increase a count.

M16 · A website newsletter sign-up appears once in QlickCRM Marketing → “Balionline weboldal feliratkozók”. Repeat sign-up does not duplicate it. A quote-form newsletter checkbox follows the person’s choice. Leaving it empty does not create a subscription or remove a pre-existing one.

Verification: Test new and existing subscriber addresses, quote opt-in checked and unchecked, and an existing subscriber submitting an unchecked quote. Compare website response, list membership and provider readback. Include restored protected newsletter success. Send no newsletter campaign.

M17 · After tests, every temporary CAPTCHA exception is removed and the original protection is active. Missing and invalid tokens are rejected for quote and newsletter routes with no CRM record, subscription or notification created.

Verification: Compare restored files/configuration with exact backups, run both negative cases against the server, and correlate CRM/inbox counts. Pair with protected positive tests in M15/M16. Never label an exception-window success as normal protected success.

M18 · The final board and concise handoff distinguish completed, failed and untested outcomes, with usable evidence. Recover proven missing data on the identified historic enquiries. Keep unavailable values “Nincs megadva” with a precise loss list. Preserve flight cards, trip order, budget/night controls and the April 5–19 itinerary image fix. Provide an unsent client reply and exact restoration instructions.

Verification: Reconcile all criteria, fixture IDs and evidence. Check only the identified historic records against recoverable originals with rollback. Recheck the named regressions and existing success-measurement event. Include production notification routing restored, CAPTCHA restored, and cookie/measurement gating intentionally still off until Matt requests re-enable. No client message is sent.