Socialising Pleras internally
Bringing in a new way of working comes with a set of conversations.
This page helps you prepare for the most common conversations with your key stakeholders.
Where to start
What we've seen tends to work
You don't need to convince everyone at once. What follows is a pattern we've seen work most often. Adapt it to how your team actually moves, and lean on us if you'd like help with any of it.
-
Map your stakeholdersIdentify which of the roles below exist at your company. At smaller teams, one person often wears several of these hats. Larger teams tend to treat each as a separate review.
-
Send the right resource to the right personEach section below points to a Pleras doc designed for that role. We'd rather you spent the time on the conversation than on writing briefings from scratch, so share these as a starting point and we'll help fill in any gaps for your specific situation.
-
Propose a scoped pilot, not a switch"A paid two-month pilot" is much easier to approve than "let's overhaul how we do experimentation." The pilot guide walks through how it's structured and what we each bring.
-
Let the pilot make the caseA working programme on real traffic surfaces things no deck can. By the end of the pilot you'll have shipped real experiments and have a much better basis for the next round of internal conversations. We're happy to help you frame the results when you get there.
Stakeholder
Growth / Product Lead
Usually the champion. The person feeling the friction of 2 to 4 tests a month most directly.
The champion
- What they care about
- Hitting the quarter's targets and getting visible wins.
- The common worry
- "If we ship more experiments, the decision load lands on me. I'm already underwater."
- How to handle it
- Our goal is to help your team do more without adding to your workload. One of our own success metrics is increasing experiment velocity without adding stress to the team. We focus on the work that usually takes the most time, like analysing experiment results. Pleras reads each result for you and suggests follow-up experiments.
- Send them
Stakeholder
Engineering
Often the most rigorous review on a rollout. Engineers have good reasons to ask hard questions about anything that runs on the site.
The technical reviewer
- What they care about
- Site stability, performance budget, CSP compliance, no surprise dependencies, an easy kill switch.
- The common worry
- "I don't want third-party code making changes to our site I can't trace."
- How to handle it
- The fastest path is the documentation. The Security doc covers exactly what Pleras runs, the vendor allowlist, DOM-XSS protections, and how to verify it independently. The Developer Guide covers the snippet architecture, selector stability, CSP, accessibility, and anti-flicker handling. Most engineering reviews are resolved by these two docs alone, and we're happy to join a session to work through any questions they raise.
- Send them
Stakeholder
Brand & Design
Anyone who owns the brand and design standards on the site.
The brand owner
- What they care about
- Variants that respect brand voice, typographic system, colour palette, and accessibility. No surprises on the homepage.
- The common worry
- "AI is going to put something off-brand in front of our customers."
- How to handle it
- Pleras extracts a tone of voice and style guide directly from the website during its initial analysis, so what it generates is grounded in how the brand actually presents itself today, not a separate document that may or may not be current. That extracted guide becomes the basis for every variant, and the QA pipeline runs brand, tone, and accessibility checks on each one before a human reviewer sees it. If anything is off or missing, the extracted guide can be updated so future experiments stay in line. See the Quality Assurance doc for the full list of gates and what's still on you to check.
- Send them
Stakeholder
Finance
The person comparing the line item against existing spend.
The budget owner
- What they care about
- Cost per outcome, contract terms, how it fits next to existing spend, and what the budget impact looks like over the year.
- The common worry
- "Why can our team not do this? Why do we need to pay somebody else?"
- How to handle it
- Yes, a team can do this themselves, especially now with AI coding tools. The catch is that a single experiment still takes at least a day to put together internally, and that's not the kind of scale Pleras is built for. Pleras generates hundreds of experiments in hours, with a team continuously improving the system and learning from every experiment run on the platform. The cost works out lower than a single full-time hire. Pricing is value-based, so what you pay tracks the experiments you actually ship live, which makes the spend easier to justify internally. That frees your team to spend more time on strategy and direction, rather than the tactical work of putting individual experiments together.
Stakeholder
Legal
Common at larger or more regulated orgs. Less common at early-stage DTC, but worth knowing about.
The risk reviewer
- What they care about
- Data handling, GDPR posture, sub-processors, where data is stored, breach disclosure, vendor security questionnaires.
- The common worry
- "Another third party with access to our site is another risk surface."
- How to handle it
- The Privacy Policy covers how we handle personal data, our role as your processor under UK GDPR, the sub-processor list, where data is stored, international transfers, retention, breach notification, and your rights. For a vendor security questionnaire or a custom DPA, reach out and we'll send what your team needs.
- Send them
What to do next
Once you have the right people on side
The next step is almost always a scoped pilot that's small enough to approve but real enough to make a case from.