Product Readiness is in beta. It is available for evaluation and early use, but its features, policy options and API contracts are still evolving and may change, or be removed, before general availability. We recommend against relying on it for business-critical workflows until the full release.
Before creating your first Readiness Policy, take a few minutes to plan what "ready" means for your business.
Product Readiness is flexible. Different businesses have different publishing requirements, so there is no single policy that works for everyone.
This guide will help you decide how to organise your policies and design requirements that are easy to maintain as your product catalogue grows.
What is a Readiness Policy?
A Readiness Policy defines three things:
- The products to evaluate.
- The channels and locales to evaluate.
- The requirements those products must satisfy.
Every matching product receives a readiness score based on the requirements in that policy.
A product can belong to more than one Readiness Policy. Each policy produces its own readiness score.
Start with the business goal
Instead of asking "What attributes are required?", begin by asking:
"What am I trying to make this product ready for?"
Common goals include:
- Publishing products to an ecommerce website
- Sending products to a marketplace such as Amazon
- Preparing products for a retailer
- Launching products in a new country
- Making products available for print catalogues
Each business goal usually becomes its own Readiness policy.
Common policy strategies
There are several ways to organise Product Readiness. Choose the approach that best matches how your business publishes products.
| Strategy | When to use it | Example |
|---|---|---|
| By destination | Different retailers or marketplaces require different information. | Amazon, Shopify, Retailer A |
| By sales channel | Each channel has different publishing rules. | Website, Mobile App, Print Catalogue |
| By market | Requirements differ between countries or regions. | UK, France, Germany |
| By product range | Different product types require different information. | Furniture, Electronics, Clothing |
Most organisations create policies around business outcomes rather than departments or internal teams.
Example policies
Example 1 - Ecommerce website
Goal
Publish products to your online store.
Requirements
- Product title
- Description
- Hero image
- Price
- Primary category
Example 2 - Amazon marketplace
Goal
Prepare products for Amazon.
Requirements
- GTIN
- Brand
- Bullet points
- Main image
- Weight
Example 3 - French website
Goal
Launch products in France.
Requirements
- French product name
- French description
- French SEO title
- French SEO description
The same product could belong to all three policies and therefore have three separate readiness scores.
Design effective requirements
Focus on the information that genuinely determines whether a product can be published.
Good requirements are:
- Required by downstream systems.
- Easy for contributors to understand.
- Consistently applied across similar products.
Avoid adding requirements simply because the data exists. Every additional requirement makes products harder to complete and maintain.
When should I use requirement groups?
Requirement groups let you combine multiple checks into a single business rule.
Use an AND group when every requirement must be met
Example:
- Width
- Height
- Depth
The group passes only when all three dimensions are available.
Use an OR group when several alternatives are acceptable
Example:
- Lifestyle image
- Product video
Either asset is sufficient, so the requirement passes if at least one exists.
Understanding non-applicable requirements
Some requirements simply do not apply to every product.
For example, imagine a requirement checks whether a product has a battery capacity attribute.
- An electric drill has the attribute.
- A dining chair does not.
Rather than failing the chair, Product Readiness treats the requirement as non-applicable and removes it from the score calculation.
This lets a single policy evaluate different product families without unfairly penalising products that do not contain certain attributes.
When should I use locale fallbacks?
Locale fallbacks allow another locale to satisfy a requirement when the primary locale does not yet contain a value.
Example
- Evaluate: French (Canada)
- Fallback: French (France)
If Canadian French content has not been translated yet, the French content can temporarily satisfy the requirement.
Only configure locale fallbacks when sharing content between those locales is acceptable for your business.
What happens when I change a policy?
Whenever a Readiness policy changes, Akeneo recalculates every product that matches that policy.
Large policies may affect thousands of products, so review significant changes carefully before saving them.
If you use the Event Platform, recalculated products may also trigger readiness events when they cross the 100% threshold.
Best practices
- Create policies around business goals, not organisational teams.
- Keep requirements focused on information that genuinely blocks publication.
- Reuse policies where possible instead of creating many similar ones.
- When several channels share the same business goal and most requirements, use one policy and limit only the channel-specific requirements with Applies on. Create separate policies when the product selection, business outcome, or overall requirement set is genuinely different.
- Use requirement groups for optional alternatives rather than creating duplicate requirements.
- Test new policies on a small product selection before applying them broadly.
- Review policies regularly as business requirements change.
Next step
Once you've decided how to organise your Product Readiness strategy, you're ready to create your first Readiness policy.
Continue with Configure Product Readiness to build your first policy.