Multi-brand lead-capture QA - regression and traceability
Five property brands, forty-eight pages and two CRMs. A form can look successful to a visitor and still lose the lead three steps later, so I built a record that could be re-run.
The brief
St Trinity Property Group and Liviti ran enquiry forms across property listings, investment pages and content campaigns - 48 distinct page URLs over nine domains and five brands. Every one of those forms was a promise that somebody would follow up.
The problem was invisibility. A visitor sees a thank-you page and assumes it worked. The business only finds out later that the email went to the wrong template, the field values arrived blank, or the lead never reached the CRM at all. What was needed was a way to see the whole chain, and to check it again whenever a page changed.
My role
I built and maintained the QA record as part of my work at St Trinity, from April 2024 to January 2025. I defined what “working” meant, ran the rounds, wrote the defects and handed them over with the evidence attached. Fixing them sat with the development team, and prioritising the fixes sat above me.
What I did
I kept a page-level record where each row connected the page name, a screenshot reference, the email result, the defect note and the CRM trace - Zoho for St Trinity, with per-lead record URLs written into the log, and GoHighLevel for Liviti. I treated each link as its own checkpoint, because a successful confirmation page does not prove that the right lead reached the right destination.
When the checks became hard to manage across brands, I moved the page inventory, results and follow-up into one tracker so they stayed together. The check dimensions grew over the fourteen months: early rounds asked only whether the email arrived, later ones added CRM record created, thank-you page reached, backend integration, and finally UTM attribution preserved.
The output
139 page and form checks across eleven rounds. The most useful finding is not in any single round but between two of them: re-running the same St Trinity pages over time showed regressions that a one-off check would have missed. The record made silent lead loss visible and repeatable for the team.
I wrote defects in the system’s own words rather than as pass or fail. One property page returned the mortgage-calculator email instead of the enquiry email, with blank field values - two bugs in one note. A finance form failed at four links at once: it submitted but still asked the user to sign up, produced no thank-you page, had no backend integration, and its phone field accepted only Australian numbers, silently rejecting overseas enquirers on an investment-property site.
What happened next
Everything went to the development team with the evidence sitting beside the finding, so a developer could open a row and see what happened without needing me to explain it. One loop closed inside the file - a developer project that was not auto-assigning in the CRM, later annotated as fixed. Four failures were still open after four months, which is a routing problem rather than a testing one. In the final round the CRM link column went empty; that gap is mine, and it is in the record.
One reflection
This was business analysis as much as testing. The value was not in finding bugs, it was in deciding what “working” had to mean - form submits, email arrives with the right content, thank-you page fires, lead lands against the right CRM record, attribution survives - and then making that definition repeatable by someone else.