How Optimizely's Opal AI Is Transforming Marketing with Agentic Automation
3 juin 2025 • 2 Minute Read • Nahomi Lopez, Responsable du marketing numérique
See All Our Insights
5 Tips for Building a Successful Optimizely Opal Pilot
14 août 2026 • 6 Minute Read • Stephanie Saia, Responsable de pratique, personnalisation et optimisation
When clients first approach us about Optimizely Opal, they usually have no shortage of ideas. They want to create content, review pages, tag assets, summarize research, qualify leads, and connect work across systems. The harder part is choosing which idea should come first.
That choice matters. A focused pilot gives a team something it can test, measure, and improve. A long list of loosely connected experiments tends to create activity without answering the most important question: Is Opal improving the work in a way that proves its value and supports further investment?
What is Opal?
For teams still getting familiar with the platform, Optimizely Opal is an AI agent orchestration platform designed for marketing teams. It enables AI agents to support and coordinate work across the marketing lifecycle, from planning and research to content creation and campaign execution.
That flexibility creates a wide range of possibilities, which makes choosing the right starting point especially important.
Before building an agent or workflow, teams need to identify where Opal can create measurable value. The strongest use cases solve a recurring problem, rely on trusted information, have a clear owner, and support broader adoption. The following five tips focus on how to choose, test, and scale those opportunities.
1. Audit the Work Before Opening the Tool
Start by looking at what your team already does. Where are people repeating the same steps? Which tasks regularly slow down because someone has to manually gather information, reformat content, apply tags, check requirements, or move work between systems? Where do errors or review cycles tend to pile up?
A content team might spend hours adding metadata to new pages. A campaign team might gather the same background information every time it prepares a brief. A digital operations team might manually check pages against an established set of publishing standards. These are more useful starting points than asking teams what they would like to do with AI.
The first use case does not need to be revolutionary. It should occur often enough that improving it matters. Additionally, it should have tangible inputs and outputs that someone can review.
Consider the difference between asking Opal to “help with content” and asking it to review an article against an approved set of editorial requirements. The second job is easier to explain, test, and improve because the team already knows what the output should cover.
Work that depends on judgment, context, or brand standards can still benefit from Opal. However, those types of use cases are generally not the best for pilots, and the agent may be better suited to preparing a first pass that a person then reviews and finalizes.
2. Test One Task Before Connecting a Full Process
It's easy to start with an end-to-end vision. A team may want Opal to research a topic, prepare a brief, draft an article, check it against brand guidance, and send it for approval. That may eventually be a useful workflow. However, testing every part at once makes it difficult to see where problems begin.
Instead, it's best to start with one task. Give the agent a clear instruction, a controlled set of information, and an output that a team member with relevant expertise can evaluate. Do not test only the ideal examples. Include incomplete requests, conflicting source material, unusual subject matter, and missing information. These cases show whether the agent asks for clarification, makes unsupported assumptions, or produces a confident answer that cannot be trusted.
This process often exposes problems that existed before Opal entered the picture. Brand guidance may be outdated. Source documents may contradict one another. Reviewers may disagree about what good work looks like. Those challenges need attention before the process expands.
Once the first task is producing reliable results, connect it to the next step. Testing in smaller pieces may feel slower at first, but it makes problems easier to find and correct.
3. Be Clear About What Should Stay Manual
Some tasks may not be ready for automation, while others may need to remain human-assisted. Before approving a pilot, the team should be able to answer practical questions:
- Who owns the process?
- Which sources can the agent use?
- Can a reviewer determine whether the output is correct?
- What happens when information is missing?
- How much harm could an incorrect result cause?
- When does a person need to review or approve the work?
If the answers are vague, the use case probably needs more preparation.
Source quality is a common issue. An agent working from contradictory product descriptions, incomplete customer data, or outdated policy documents will carry those problems into its output. Rewriting the prompt will not fix information that the organization cannot trust.
Risk also changes the amount of oversight required. For example, an internal research summary differs from a public pricing statement, just as a first-pass content review differs from approving a legal claim. Work involving personal information, regulated language, contractual commitments, or direct customer communication should have clear limits and an identified reviewer.
Identifying which use cases aren't ready for automation helps narrow the focus to those that are. It also directs the team’s time and investment toward pilots with the clearest path to measurable value.
4. Treat Governance as Part of the Build
Governance discussions often happen late, after a team has already created something and wants permission to release it. By then, choices about access, data, and accountability may already be built into the process.
Prevent issues by addressing those questions at the start of the pilot, when the team can still shape the agent or workflow design.
For each agent or workflow, document its purpose, owner, approved information sources, access requirements, review process, and failure path. Someone outside the build team should be able to read that description and understand what the agent or workflow does, what it may access, and what it isn't allowed to do.
The amount of control should match the use case. A tool that organizes internal research may require a lighter review process. A process that prepares public content or uses customer information requires greater scrutiny.
Ownership and human intervention deserve particular attention. An agent may begin as an experiment run by one interested team member, but it can quickly become part of daily work. Someone needs to check whether the output remains accurate and consistent, whether the source material has changed, and whether the use case still makes sense.
That owner should also have the authority to pause the process. If quality drops after a change to the instructions, data, or connected systems, the team needs to correct the problem before it gets bigger.
5. Measure What Changed
Opal activity is easy to count. A team can track how often an agent runs, how many people use it, and how many credits it consumes. Those metrics help monitor usage, but they don't show whether the team is saving time, reducing rework, or getting better results.
Before the pilot begins, define what success looks like and document how the process performs today. For a content review use case, that might mean recording how long reviews take, how many rounds are typical, and which issues appear most often. For research, measure the time spent gathering and organizing information. For an operational task, track volume, delays, rework, and manual effort.
Without that baseline, a pilot can continue because people like using it, even when the team cannot show that it has improved the work or created enough value to justify the cost.
During the pilot, compare its performance against the same measures. The benefit may be faster turnaround, but it could also be more consistent output, fewer corrections, shorter approval cycles, or additional capacity for work the team could not previously complete.
Some pilots won't deliver enough value to continue. Finding that out early is useful. The team can identify what fell short, adjust the approach, or move on to a use case with a better chance of producing the desired result.
To determine ROI, weigh the value gained—such as time saved, reduced rework, faster approvals, or added team capacity—against the full cost of the pilot. Include both Opal credits and the time reviewers spend validating agent output. Then compare the results with the pre-pilot baseline to determine whether the improvement justifies further investment.
Put the Right Foundation Under Opal
The first Opal use case doesn't need to transform an entire department. It needs to solve a clear problem, use dependable information, and produce a result the team can evaluate.
That foundation makes future decisions easier. The organization can see what worked, what required more oversight, and where a broader workflow may be justified. It also prevents the Opal program from becoming a collection of pilots with no clear owner or measure of success.
As an Opal Specialized Partner and Optimizely Premier Platinum Partner, Verndale combines deep Optimizely expertise with experience across strategy, technology, data, experience design, and digital operations. We help clients prioritize use cases, configure agents and workflows, establish governance, and measure results, and determine when a pilot is ready to scale.
Get your free Optimizely Opal AI Agent Readiness Assessment to identify the right Opal use case and build a clear path to measurable value.