Adobe Journey Optimizer RFP Template

Before You Issue a Adobe Journey Optimizer RFP

AJO sits on Experience Platform, which means your journey ambitions are bounded by your data readiness. An honest RFP separates the two: what profile and event data exists today, what must be built, and which journeys are achievable in each state. Vendors who quote journey delivery without auditing data readiness are quoting fiction, and the polite way to find out is to ask what they need from your data before committing to dates.

If you are migrating from Adobe Campaign or another ESP, make rationalization explicit. A migration that faithfully recreates two hundred legacy campaigns transfers your technical debt to a more expensive platform. Require a campaign audit with keep/merge/kill recommendations. And do not let deliverability be an afterthought — IP warming, authentication and list hygiene determine whether the impressive new journeys actually reach inboxes.

What the Adobe Journey Optimizer Sections Cover

• Journeys ranked so the first release is defensible
• Channel setup per surface, push certificates included
• Experience Platform prerequisites, priced separately
• Sending domains, IP warm-up and reputation ownership
• Throttling and capping rules under real send volume
• Content authoring split between vendor and marketers

Writing the Adobe Journey Optimizer Scope of Work

Separate journeys from campaigns in the scope, because they are different constructs with different data requirements. Triggered journeys need a real-time event with a defined schema, a reliable emitter and an agreed definition of what the event means; scheduled campaigns need an audience and a send window. State how many of each you expect in the first phase, and for every triggered journey name the source system of the event and its owner. An RFP that lists journeys without naming their trigger events is asking vendors to price around an unknown, and they will price optimistically.

Scope the channels individually, with the work that sits behind each one. Email requires domain authentication, subdomain strategy and a sending reputation plan. Push requires application changes, certificate handling and a consent mechanism your mobile team must build. In-app and web channels require surface definitions and, in the case of in-app, a release of the application. SMS requires provider setup, number provisioning and country-level regulatory handling. Say which of these depend on teams outside the project, because those dependencies typically set the launch date rather than the configuration work.

Treat content production as a scoped deliverable with a named owner. Template design, reusable fragments, dynamic content rules, localisation and the approval flow before a message can send are all work, and they are frequently assumed to be the client's responsibility without anyone saying so. If decisioning or offers are in scope, that is a separate design exercise covering offer inventory, eligibility rules, ranking and capping, and it deserves its own acceptance criteria rather than being bundled into journey build.

Define done in operational terms. A reasonable standard is that a named journey runs end to end in production for a defined period with monitored error rates, that message volumes and unsubscribe rates are within stated bounds, that frequency capping and business rules demonstrably prevent a customer receiving conflicting messages from two journeys, and that your own marketers have launched at least one journey unaided before the engagement ends. Name explicitly what is out of scope: the upstream data work in Experience Platform, the retirement of the legacy platform, and any analytics build beyond delivery reporting.

Requirements That Actually Separate Adobe Journey Optimizer Proposals

• Event contract definition — require each triggered journey to have a documented event schema, expected volume, ordering guarantees and a defined behavior when the event arrives late, out of sequence or twice.
• Cross-journey conflict control — ask how frequency capping, business rules and journey precedence are configured so that a customer in three journeys receives a coherent sequence rather than three simultaneous messages.
• Sending infrastructure plan — require the subdomain, authentication and reputation approach in writing, including how volume is ramped and what monitoring triggers a pause if complaint or bounce rates move.
• Profile dependency mapping — ask which profile attributes each journey depends on, how freshness is guaranteed for each, and what the journey does when an expected attribute is missing on a given profile.
• Message fragment architecture — require a structure for reusable content fragments and templates so that a legal wording change propagates through one edit rather than through every message in the estate.
• Decisioning design — where offers are in scope, require the offer catalog structure, eligibility rules, ranking approach and capping model to be described, plus how a business user changes an offer without a developer.
• Operational monitoring — ask what alerting exists for journeys that stall, entry rates that collapse or messages that fail at the channel, since silent failure is the characteristic failure mode of orchestration platforms.

Common Mistakes in Adobe Journey Optimizer RFPs

• ✕ Journey ambitions scoped without an Experience Platform data-readiness audit.
• ✕ Migrating the full legacy campaign inventory instead of rationalizing it first.
• ✕ Deliverability and IP warming compressed at the end of the timeline, right before launch volume.
• ✕ Channel setup (push, SMS, in-app) priced in but the app and consent work on your side unscoped.
• ✕ Marketers trained on the tool but not the new operating model journeys require.

• ✕ Scoping push and in-app channels without confirming that the mobile application roadmap has capacity for the SDK work and a release slot within the project timeline.
• ✕ Designing journeys around attributes that update nightly while promising real-time relevance, so the experience the business signed off on cannot be delivered by the data underneath it.
• ✕ Counting journeys as the unit of work when a single journey with twelve branches, four channels and localisation is several times the effort of a three-step welcome series.
• ✕ Leaving the legacy platform running with no defined cutover for shared audiences and suppression lists, so customers receive duplicate messages from both systems during the overlap.

Questions Worth Asking Adobe Journey Optimizer Vendors

1. What does your data-readiness audit cover, and show a redacted output from one.
2. How do you run campaign rationalization in a migration — criteria, and typical kill rate?
3. Walk through your IP-warming and deliverability plan for our sending volumes.
4. Which journeys from your last AJO project drove measurable outcomes, and how were they measured?
5. What does marketer enablement include beyond tool training — operating model, governance, on-call support?

How to Weight the Adobe Journey Optimizer Evaluation

Weight data readiness assessment ahead of journey design skill. Journey Optimizer executes what your profile and event data can support, so a vendor who begins by auditing what exists is scoping the real project, while one who begins with journey diagrams is selling the pleasant part. Where proposals differ in how seriously they treat the upstream dependency, treat the more sceptical one as the more experienced one and score accordingly.

Give deliverability and channel operations meaningful weight, because these are the areas where a technically correct implementation still fails commercially. Messages that are built beautifully and land in spam folders, or push notifications blocked by a consent mechanism nobody tested, are failures the business will attribute to the platform. Evidence of running sending infrastructure at your kind of volume is worth more than additional journey-building capacity.

Score the operating model transfer heavily. The point of this platform is that marketers change journeys without a project, and that only happens if the implementation is built with reusable fragments, clear naming and guardrails that make independent work safe. Weight proposals on what your team will be able to change unaided at the end, and treat an implementation that only its builders can modify as a partial delivery whatever its technical quality.