Before creating your first Readiness Configuration, 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 configuration that works for everyone.
This guide will help you decide how to organise your configurations and design requirements that are easy to maintain as your product catalogue grows.
What is a Readiness Configuration?
A Readiness Configuration 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 configuration.
A product can belong to more than one Readiness Configuration. Each configuration 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 Configuration.
Common configuration 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 configurations around business outcomes rather than departments or internal teams.
Example configurations
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 configurations 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 configuration 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 configuration?
Whenever a Readiness Configuration changes, Akeneo recalculates every product that matches that configuration.
Large configurations 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 configurations around business goals, not organisational teams.
- Keep requirements focused on information that genuinely blocks publication.
- Reuse configurations where possible instead of creating many similar ones.
- Use requirement groups for optional alternatives rather than creating duplicate requirements.
- Test new configurations on a small product selection before applying them broadly.
- Review configurations 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 Configuration.
Continue with Configure Product Readiness to build your first configuration.