Client onboarding

Client Onboarding Guide

Who this is for: WooCommerce brands starting the 90 day Performance Gateway, or considering a CRO partnership with StrategyFive.

How to use this guide: keep it open during onboarding. It explains what we need from you, what we do, and what happens next.

Important: if anything conflicts with your signed Order Form, Statement of Work, SLA, or our Terms and Conditions, those signed documents take precedence.

Goal

Get you onboarded quickly, safely, and with clear measurement so we can start improving performance.


If you are still considering StrategyFive (before you sign)

This page is public because many clients want to understand the process before committing.

  • You submit the Get Started form.
  • We request GA4 access so we can review your data properly.
  • We run an initial CRO and performance audit and share our findings.
  • We discuss fit, constraints, and the proposed 90 day plan on a call.
  • If we both want to proceed, we confirm scope in writing and schedule kickoff.

If you have signed and want to start the Gateway

In most cases, onboarding follows this order:

  • We confirm the scope and schedule your kickoff call.
  • You share key access (GA4, WordPress, hosting or DNS, consent management).
  • We agree KPIs, baselines, and measurement rules in GA4.
  • We stabilise the site (speed, errors, tracking gaps) and set up reporting.
  • We move into UX improvements and controlled experimentation.

Your first week checklist

If you complete these in the first 5 working days, everything moves faster:

  • Book the kickoff call and confirm your main decision maker (the person who can approve changes).
  • Share GA4 access (mandatory). If GA4 access cannot be provided, we cannot run the programme.
  • Provide WordPress and WooCommerce admin access on production (and staging if you already have it).
  • Share hosting access and DNS access, or introduce us to the person who controls them.
  • Share access to your consent tool (CookieScript or equivalent).
  • Send your commercial calendar for the next 90 days (promotions, email sends, peak dates).
  • Tell us about recent or planned major changes (theme rebuilds, checkout changes, tracking changes).
  • Complete the integrations and risk questionnaire (see the relevant section below).
  • Agree a preferred deployment window (day and time) and any blackout periods where we should not deploy.
  • Save support and escalation details for urgent issues.

Most WooCommerce CRO engagements start with the Performance Gateway. It is our prove then pay model.

During the Gateway, we do the work. You do not pay CRO fees until success is proven in GA4.


Success threshold

The standard success threshold is at least a 12% uplift in either:

  • Revenue per visitor (RPV) in GA4, or
  • Purchase conversion rate in GA4

How uplift is measured

  • We use GA4 as the source of truth.
  • We measure uplift in rolling 30 day windows.
  • We normally compare the rolling 30 day window against the same dates in the prior year to account for seasonality.
  • If historical data is missing or unreliable, we agree a pegged baseline in writing and measure against that instead.

When the Gateway clock starts

  • In straightforward cases, the Gateway starts once onboarding is complete and measurement is agreed.
  • If a hosting migration is part of onboarding, we treat the go live date as the practical start point for performance measurement.

When fees start

  • The Gateway is not a guaranteed 90 day free period.
  • If the success threshold is met earlier, invoicing starts for the preceding successful 30 day window, billed in arrears.
  • If the success threshold is not met within the Gateway period, you can walk away owing £0 in CRO fees for that period.

If your store is very small

If traffic volume is too low for reliable measurement, we will tell you early. In those cases, Platform Only may be a better fit until the store has enough volume for structured testing.

For more detail on how the model works, see our Our Model page.

Timeline and milestones (typical)

The exact pace depends on access, complexity, and how quickly approvals happen. This is the typical flow:

Onboarding (week 1)

  • What we do: kickoff, access collection, risk discovery, baseline setup, shared log and reporting setup.
  • What you do: share access, confirm decision maker, send commercial calendar, complete the questionnaire, agree deployment windows.

Stabilise and measure (weeks 1 to 4)

  • What we do: speed and reliability fixes, tracking and consent review, error reduction, initial UX friction fixes.
  • What you do: approve priorities, confirm constraints, keep us informed about launches and changes.

UX improvements (weeks 3 to 6)

  • What we do: high impact UX and funnel improvements based on data and behaviour insights.
  • What you do: provide fast feedback and sign off changes.

Experimentation (weeks 4 to 12)

  • What we do: build and run A B tests, document outcomes, roll out winners.
  • What you do: respect change control, avoid unplanned major changes, approve rollouts.

Gateway decision (around day 90)

  • What we do: verify uplift, share a summary, recommend the next tier and a roadmap.
  • What you do: choose next steps: paid tier, Platform Only, or exit.

Kickoff call: how we align fast

We use the kickoff call to align goals, scope, measurement, and workflow so the programme does not drift.

Who should attend

  • Your decision maker (required).
  • A technical contact (internal developer or agency).
  • A marketing or eCommerce lead who owns promotions and trading priorities.

What to prepare

  • Your top goals for the next 90 days and any constraints.
  • Your commercial calendar (promotions, peak dates, planned launches).
  • Any known tracking issues, consent changes, or data anomalies.
  • Any recent or planned changes that could affect measurement (theme rebuilds, checkout changes, major plugin changes).
  • Your preferred approval process and who signs off releases.
  • Your preferred deployment window and any blackout periods.

What we decide on the call

  • Primary KPI for the Gateway: RPV or purchase conversion rate (or both, with one primary).
  • Baseline method: year on year or pegged baseline.
  • Whether a hosting migration is planned.
  • Change control rules for the Gateway (what needs approval and what can happen freely).

We keep access requests focused and prefer read only access where possible. Some work requires admin access, especially in WordPress.


Access checklist

Must have to start

  • GA4 access (mandatory).
  • WordPress and WooCommerce admin access on production.
  • Hosting access or a clear point of contact (if performance work or migration is required).
  • DNS access or a clear point of contact (if a DNS change is required).
  • Consent management access (CookieScript or equivalent).

Nice to have (helps us move faster)

  • Google Tag Manager access (if you use it).
  • Google Search Console access (if available).
  • Behaviour analytics: Microsoft Clarity or Hotjar (if you already use it, or want us to install it).
  • Payment gateway or checkout provider access (to validate payment flows and logs).
  • Key integrations access (email marketing, fulfilment, subscriptions, search, reviews).

How to share GA4 access

The GA4 interface changes from time to time, but the steps are usually:

  • Open GA4 and select the correct account and property.
  • Go to Admin.
  • Open Access management (Account access management or Property access management).
  • Add the StrategyFive email address we provide.
  • Assign a role. Viewer is the minimum to start. We may request a higher role if we need to configure events or conversions.

How to create a WordPress admin user

  • In WordPress, go to Users, then Add New.
  • Add the StrategyFive email address we provide.
  • Role: Administrator.
  • If you use two factor authentication or IP restrictions, tell us so we can set it up correctly.
  • Please avoid shared logins. A dedicated user makes access safer and easier to remove later.

Named accounts and credential handling

We ask for a dedicated, named admin user rather than shared logins. This keeps access auditable and removable.

We store credentials in Proton Pass (business password manager) and only share access with staff who need it for delivery.

If you use a security plugin that restricts logins, tell us before applying restrictions so we can avoid lockouts.

Integrations and risk questionnaire

Please answer these in writing. Short answers are fine. The goal is to avoid surprises during testing, migration, and go live.

  • Payments: which payment gateways are live (for example Stripe, PayPal, Klarna, Clearpay), and are there any custom checkout fields or scripts?
  • Shipping and fulfilment: which shipping plugins or fulfilment tools are used (for example ShipStation, Linnworks, custom 3PL)? Any webhooks?
  • Tax and invoicing: do you use a tax service (for example Avalara) or custom VAT rules?
  • Subscriptions or memberships: do you sell subscriptions, memberships, or renewals? Which plugin powers it?
  • Search and merchandising: do you use a non standard search tool, filters, personalisation, or a product recommendation engine?
  • Email: how are transactional emails sent (default WooCommerce, SMTP plugin, external provider)? Any restrictions on staging?
  • Reviews, referrals, loyalty: which platforms are installed (reviews, loyalty points, referrals, affiliates)?
  • ERP or stock: is inventory managed in an ERP or external system? Any stock sync rules we must not break?
  • Security and access: do you use a firewall, IP allow list, bot protection, or login restrictions that could block our work?
  • Peak dates and release rules: any blackout periods where we should not deploy? What is your preferred deployment day and time?
  • Anything else: anything else that could break checkout, payments, order emails, or fulfilment if we clone or change the site?

Critical flows checklist for QA

Critical flows are the customer actions that must work for you to trade. We use this list for regression testing before releases and before go live.

Tick what applies to your store, and add anything missing:

  • Browse categories, use filters, open a product page
  • View a simple product and a variable product
  • Add to cart
  • Apply a coupon or discount code
  • Estimate shipping and taxes
  • Checkout as guest
  • Checkout as logged in user
  • Payment method 1 (your main gateway)
  • Payment method 2 (secondary gateway, if used)
  • Order confirmation page loads correctly
  • Key emails send correctly (order received, processing, completed, refund)
  • Account creation and password reset
  • Returns, cancellations, or exchanges (if applicable)
  • Anything else specific to your store

Some clients move onto StrategyFive managed hosting. Others stay on their existing infrastructure. We can work either way as long as the environment is fast and stable enough for WooCommerce.

If you move to StrategyFive managed hosting

  • We provide a performance tuned WooCommerce stack, monitoring, caching, security hardening, and backups.
  • We can control more of the stack, which makes performance work and releases more predictable.
  • SSL and HTTPS management are included on our platform.

If you stay on your current host

  • We will review the setup and highlight risks or bottlenecks.
  • We coordinate with your hosting team where needed.
  • We cannot offer the same server level guarantees because we do not control the infrastructure.
  • If the environment is not stable enough to support the programme, we will explain the options and agree a fix before work continues.

Staging first

We build and test changes in staging first, then deploy to live during an agreed window. Staging is configured to reduce risk, for example:

  • Search engines blocked from indexing
  • Customer emails disabled where possible
  • Payments disabled or switched to a safe test mode
  • Analytics disabled to avoid contaminating reporting

Typical go live process (hosting migration)

If we are migrating your store onto StrategyFive hosting, this is the usual sequence:

  1. Clone: we take a copy of your live store onto our platform, typically using Migrate Guru or equivalent migration tooling.
  2. Harden: we apply security, caching, performance configuration, and create a staging environment for changes.
  3. Test: we run QA against the critical flows checklist, validate analytics, and validate checkout (including a test order where appropriate).
  4. Client sign off: you test staging and confirm you are happy to proceed.
  5. Freeze: we agree a quiet go live window and ask for a short content and code freeze to reduce risk.
  6. Sync: just before cutover, we sync key live changes where appropriate (for example recent orders or customer data).
  7. Cutover: DNS is updated to point the domain to the new environment. We aim for minimal downtime, but DNS propagation can vary by provider.
  8. Monitor: we monitor uptime, error logs, and checkout closely after go live.

DNS options

There are two common approaches:

  • StrategyFive manages DNS (recommended when possible): we coordinate the cutover and control timing.
  • You manage DNS: we provide the exact record changes (for example updating A records) and you or your IT team applies them.

You remain the domain owner. We can help with DNS tasks, but we do not provide mailbox hosting for email.

Clear measurement keeps the Gateway fair and keeps decisions grounded.

Baselines

  • We agree baseline RPV and purchase conversion rate in GA4.
  • We document the baseline method, time window, and any known tracking gaps or anomalies.
  • We either use year on year baselines (typical) or a pegged baseline where data quality requires it.

Consent changes and tracking changes

  • If consent settings change, measurement can shift. To keep comparisons fair we follow a consent reset protocol.
  • Where possible we exclude the first 7 days after a consent change from uplift verification and compare like for like segments such as consenting users only.
  • If segments are not available, we may adopt the first full consent compliant 30 day window as the new baseline. Any change is documented.

The shared log

We maintain a shared log to record context that affects performance, for example:

  • Site launches and major changes
  • Tracking gaps and fixes
  • Consent changes
  • Incidents and outages
  • Blackout periods and agreed deployment windows

Delivery cadence and reporting

You should always know what is happening and why.

  • Weekly written updates, usually by email.
  • Monthly performance summary and optional review call.
  • A shared dashboard for performance tracking.
  • Documented test plans and outcomes for key experiments.

Experimentation

  • GA4 remains the source of truth for measurement.
  • Where we run A B tests, we follow statistical best practice and aim for sensible minimum run times so decisions are not made on noise.
  • We normally roll out winners quickly, then move to the next highest impact opportunity.

Optional appendix: A B testing thresholds

If you want one small detail on rigour without adding clutter to the core process, these are the typical thresholds we aim for when A B testing is appropriate:

  • 95% two tailed statistical significance
  • No material sample ratio mismatch (plus or minus 2.5%)
  • A minimum run time of 14 days
  • No material anomaly in tracking or trading conditions

Some stores do not have enough traffic for rigid thresholds. Where that is the case, we agree sensible exceptions and document the decision.

Our CRO work includes speed, UX, experimentation, and implementation of agreed CRO improvements, subject to your signed scope.

Outside CRO scope

Anything outside the agreed CRO scope is treated as additional development on a time and materials basis, with written estimates and approval before work begins.

Common examples:

  • Legacy fixes in themes, plugins, custom code, or databases we did not build
  • Major new features or bespoke modules not tied to the CRO roadmap
  • Large migrations, replatforming, or complex third party system work
  • Marketing work such as paid media, SEO retainers, or content production

Rates and billing

Additional development is typically billed at £65 per hour plus VAT, with a 0.5 hour minimum, charged in 30 minute increments, unless agreed otherwise in writing.

Remedy period for defects

If a deliverable fails to meet written acceptance criteria within 30 days of acceptance, we investigate and correct it at no additional charge. After that period, changes are treated as billable development.

Support hours

Support hours are 09:00 to 17:30 UK time, Monday to Friday, excluding UK public holidays.

Support is provided by email or ticket. For P1 emergencies outside support hours, we provide best efforts support.

To contact support: support@strategyfive.io. For urgent P1 issues, you can also escalate via +44 20 4502 0343.


Severity levels and targets

  • P1 urgent: site down, checkout failure (not payment gateway), or critical security issue being actively exploited. Target first response: 2 hours. Target restore or workaround: 4 hours.
  • P2 high: major function materially impaired. Target first response: 4 business hours. Target restore or workaround: 2 business days.
  • P3 standard: routine defects or requests without material revenue impact. Target first response: 8 business hours. Target restore or workaround: 5 business days.

Targets exclude delays caused by third party outages, lack of access, missing licences, or client introduced defects.


Maintenance and blackout periods

  • Planned maintenance is scheduled outside UK working hours where possible, and we notify you in advance.
  • Peak retail periods may include agreed blackout periods, for example around Black Friday and Cyber Monday.
  • We prepare and test changes in staging before going live.

Data protection and AI summary

Security is built into our platform and operating process. For CRO services, you act as the data controller and StrategyFive acts as a data processor for personal data processed through analytics and experimentation tools.

We may use reputable AI tools to support internal research, drafting, and quality checks. We do not input your confidential information or personal data into public AI tools without your written consent. Human review governs outputs.


End of the Gateway: outcomes and next steps

At the end of the Gateway, we share a clear summary of work completed, what we learned, and what we recommend next.

If the success threshold is met

  • The Gateway is successful and invoicing starts for the successful rolling 30 day window, billed in arrears.
  • You move onto a fixed monthly CRO tier (no revenue share).
  • We agree the next 90 day roadmap and continue with a steady release and experimentation cadence.

If the success threshold is not met

  • You can leave owing £0 in CRO fees for the Gateway period.
  • We will still share the work completed and a recommended plan.
  • Some clients choose to continue on Platform Only (£250 per month plus VAT) or proceed with CRO on a different basis, but the decision is yours.

Typical tier pricing (confirmed in your Order Form)

  • Essentials: £1,750 per month
  • Growth: £2,750 per month
  • Scale: £4,500 per month
  • Enterprise: from £9,000 per month
  • Platform Only: £250 per month plus VAT

For full detail, see Our Model.


Useful links and contacts