Cross-Template CTA Rollout — Q3 2025 Initiative

Client (end user): A US marketing agency specialising in local-business websites — internal product initiative
Engagement: Feature rollout for one of the agency’s internal sub-teams, across the agency’s dental WordPress template library
Delivered: October – November 2025 · ~26 hours · 4 Redmine issues (1 build + 3 QA passes)

The Craft of a Feature Rollout

Twenty-five days, two CTA components — a Slim Banner on every homepage and Hero Buttons across all page heroes — pushed across the agency’s live dental template library while the agency’s own developer worked the same list from the opposite end. The scope expanded mid-engagement: ten additional sites added and highlighted in the tracker. A Pop-up CTA was held back before work began, leaving two components from the start. Three staged QA passes closed each batch before it was reported complete.

Each site in that library is a variation on a theme. Some will accept the new feature cleanly. Others will have something already in that slot — an older version of the component, a local customisation, a site-specific constraint noted only in a spreadsheet comment. The discipline is not just implementation speed; it is the judgement to apply uniformly where the spec allows and escalate where it does not, without leaving either the spec unfinished or the individual site broken.

This case study describes one such rollout — a unified CTA system pushed across a US marketing agency’s dental template library as part of a Q3 2025 quarterly product initiative.

Snapshot

The Brief

One of the agency’s internal sub-teams — the team responsible for maintaining and iterating the agency’s dental site template library — ran a quarterly product initiative in Q3 2025. The initiative (“Q3 Rock,” in the agency’s planning vocabulary, denoting a quarterly priority shipped as a discrete block of work) called for a unified CTA system to be deployed across all Elementor-based sites in the library. The agency supplied the implementation spec in two artefacts: a Google Sheets tracker containing the CTA copy (button labels, slim banner text, destination URLs) for each site, and a Google Docs SOP accompanied by video walkthroughs recorded by the agency’s product team.

The scope covered two CTA components: a Slim Banner positioned above the homepage header (linking typically to insurance or comparable landing pages) and Hero Buttons placed across all page hero sections (linking to booking systems or contact pages, depending on the practice). A third component — a Pop-up CTA — was scoped in the initial brief but held back by the agency before implementation began, limiting the rollout to two-thirds of the originally planned CTA surface. The implementation target was every Elementor-based site in the library; sites not built on Elementor were to be noted and skipped, not modified.

The engagement sits outside the per-client delivery model that governs most of the portfolio. There is no single end-client, no production URL to verify post-handoff. The work is infrastructure maintenance on the agency’s own template library — the kind of initiative that keeps a large portfolio of managed sites consistent without requiring individual per-site project engagements.

Operational Integrity at handoff

Pre-handoff QA ran through Site Checker — a WordPress plugin we built and maintain — across the categories applicable to this engagement: core settings, content and SEO surface, URL structure, content-language sanitization across pages, posts, Elementor data, menus and widgets, and multi-resolution screenshot capture. Fail-zero gate before handoff; warnings reviewed and judged non-blocking. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off.

How We Did It

1. Initial brief ingestion and access setup. The agency supplied a Google Sheets CTA copy tracker and a Google Docs SOP with video walkthroughs. The tracker listed each site by domain with the required Slim Banner copy, Hero Button labels, and destination URLs. Access to each site’s WordPress admin was retrieved from the agency’s credential vault. Sites that could not be accessed immediately were queued for a credential request before work began on them — no modifications were made without verified access in hand.

2. Site-by-site CTA implementation with deviation tracking. The developer worked through the tracker row by row, applying the Slim Banner to each site’s homepage and the Hero Buttons to all page heroes. Where a site already carried a Slim Banner — placed by either the agency’s own developer or a prior campaign — the discrepancy was noted in the tracker’s comment column rather than silently overwritten. This approach — documenting deviations rather than normalising them — was a deliberate choice: the team could have force-applied the new CTA copy uniformly, but doing so would have overwritten site-specific customisations that the agency’s clients had already reviewed and approved. Keeping the existing CTA visible in the tracker preserved the agency’s editorial control over which sites received updated copy and which retained their prior messaging. The agency’s comment conventions in the tracker (column E check-marks for completed sites, notes on problem sites) were maintained throughout so the agency’s developer, working the same batch from the opposite end of the list, could see exactly which sites had been handled and which had standing questions.

3. Non-Elementor site handling. A subset of sites in the library were not built on Elementor. Per the brief, these were documented and skipped — not modified. The notes in the tracker made these exclusions visible to the agency without requiring a separate communication pass.

4. Three dedicated QA passes with iterative batch closure. The rollout did not use a single end-of-engagement QA pass. Instead, three separate QA issues were created in Redmine as the work progressed in batches — Pavel Sazhin completed two passes (Oct 25 and Nov 3) as implementation batches were marked done; Anton Hersun completed a third pass (Nov 7). This staged QA pattern matched the batch structure of the rollout: the agency was adding sites to the tracker mid-engagement as the initial batch was completed, so QA ran against completed sets rather than waiting for the full list to finish. Each pass operated as a fail-zero gate before those sites were reported complete.

The tension in a library-wide rollout is the overwrite — applying new copy on top of a site-specific customisation without visibility. The discipline was the tracker itself: every deviation logged in the comment column, column E check-marks only on sites confirmed done, no silent overwrites. The agency saw exactly which sites had standing questions when they reviewed each batch.

Results

The outcome, restated plainly: the agency’s Q3 product initiative was delivered — a unified CTA system deployed across the Elementor-based template library, per-site deviations surfaced rather than silenced, non-Elementor exceptions documented, and three staged QA passes confirming quality before each batch was signed off.

Process

The agency expanded the site list mid-engagement — adding batches as the initial set was cleared — which is the characteristic shape of a library-wide rollout: scope is bounded by the library, but the exact count surfaces incrementally as the library is audited.

Team

Delivery team

• Lyudmila Travkina — lead developer, CTA implementation across all Elementor sites
• Pavel Sazhin — QA, two dedicated passes (batch close-out reviews)
• Anton Hersun, xaverPRO — QA pass 3, project oversight, estimation, billing

Agency-side project management, CTA copy strategy, and client-facing communication remained with the partner agency and its internal sub-team throughout. The end-clients whose sites received the CTA update were not aware of the sub-contractor handoff.

For agencies running a template library at scale