LELO: Requirements-Led Delivery for a Global Luxury E-Commerce Brand
How Business Analysis Canada led requirements, process modelling and acceptance criteria for LELO's global e-commerce, then guided the build and support.
- 160+ countries where LELO sells, each with its own rules
- 1 signed-off requirements baseline for development, testing and support
- 4 market clusters covered in elicitation workshops
- ~3 months of requirements work before the build started
Project at a glance
- Client
LELO, a Swedish luxury intimate-wellness brand sold in more than 160 countries through its own online stores, retailers and distribution partners - Platform
Multilingual, multi-currency e-commerce storefronts on Drupal Commerce, connected to order management, warehouse and customer care systems - Engagement
Analysis-led delivery. We set a validated requirements baseline first, and software development and project support then followed that baseline. - Duration
About 3 months of requirements work, about 6 months of build in sprints, then ongoing project support - Our role
Business Analysis Canada led the analysis: stakeholder elicitation, business requirements, process modelling and acceptance criteria. Our analysts stayed on through development and support to keep delivery tied to the baseline.
The challenge
What problem was the client trying to solve?
Selling a premium product in more than 160 countries means one storefront has to follow many different sets of rules. LELO needed those rules agreed and written down before committing development budget.
- Rules scattered across teams
Prices, promotions, payment methods, tax display and shipping options varied by market, and the rules were spread across teams and spreadsheets. - Products restricted by market
Product availability differed by market. Some products could not be sold or shipped to certain countries, and some markets required age confirmation before purchase. - Customers expect discretion
Customers in this category expect discretion. Packaging, card statement descriptors, emails, SMS messages and account pages all had to respect that. - Warranty claims by email
Warranty claims, returns and replacements were handled by email, with manual checks of proof of purchase and product authenticity. Handling was slow and differed from region to region. - Complex return rules
Return rules were complex. Hygiene rules mean unsealed intimate products generally cannot be returned for a change of mind, but faulty products still have to be handled under warranty. - Change requests that caused rework
Earlier change requests had reached developers as short descriptions, which led to rework and disputes about what was in scope.
Our business analysis approach
How did we approach the engagement?
How did we build the requirements baseline?
The aim of the first phase was one set of requirements that the business had validated and signed off, so development could start from facts rather than assumptions.
- Stakeholder mapping
We identified stakeholders across e-commerce, marketing, customer care, finance, logistics, legal and compliance, regional market managers and IT. A RACI matrix set out who would contribute, review and sign off each requirement area. - Elicitation
We ran interviews and workshops, grouped by market cluster: Europe, North America, Asia-Pacific and the rest of the world. We also analyzed customer care tickets, current storefront behaviour, order patterns, and existing returns and warranty policies. - Business requirements document
The BRD captured business objectives, scope and exclusions, stakeholders, business rules, assumptions, constraints and success criteria for each requirement area. - Process modelling
We modelled the key processes in BPMN: order to delivery, promotion setup and approval, market availability management, warranty claims, and returns and refunds. Swimlanes covered customers, customer care, the warehouse, finance and regional partners. - Business rules and decision tables
Rules that vary by market or situation went into decision tables. These covered price list selection, promotion precedence and stacking limits, product availability, age confirmation, return eligibility and warranty eligibility. - Non-functional requirements
We set requirements for privacy and discretion, performance during seasonal peaks such as Black Friday and Valentine's Day, accessibility, and localization of languages, currencies, date formats and address formats. - Acceptance criteria
Every requirement received Given/When/Then acceptance criteria, written with the relevant business owner and validated in review sessions. - Baseline sign-off
LELO's product owner and business owners signed off the baseline. It was version-controlled, and from then on every change was measured against it.
Requirements
What did the requirements cover?
Area
Problem
What the requirements defined
Market configuration
Rules scattered across teams
A market rules catalogue and requirements for market-level settings: languages, currencies, payment methods, tax display and shipping options
Product availability
Restricted products visible in some markets
Availability rules applied consistently at catalogue, cart and checkout
Age confirmation
Market-specific legal requirements
An age confirmation step for markets that require one, with the rule controlled per market
Pricing and promotions
Conflicting promotions and unclear precedence
Price lists by market, promotion precedence and stacking limits, and an approval step before any promotion goes live
Discreet experience
Inconsistent handling across touchpoints
Discretion rules for packaging options, card statement descriptors, email and SMS content, and account pages
Warranty registration and claims
Claims handled by email
An online registration and claim flow with proof-of-purchase upload, a product authenticity check, eligibility rules and routing to regional teams
Returns and refunds
Different return handling by region
Return eligibility rules by market, including hygiene exceptions for unsealed products, a return authorization flow and refund rules
Integrations
Manual handoffs between systems
Data flows between storefronts, order management, the warehouse and customer care tools, with an agreed owner for each data element
Reporting
No shared definitions
Agreed definitions for return rates, claim reasons and promotion performance by product and market
Acceptance criteria
How did acceptance criteria keep scope under control?
Acceptance criteria were the contract between the business and the build. If a feature met its criteria, it was done. If someone wanted something different, it went through change control as a change request. Three examples from the baseline:
Product availability
- Given a customer is browsing a market where a product is restricted
- When they open that product's page
- Then the page shows the product is not available in their market
- And the product cannot be added to the cart
Promotion precedence
- Given two active promotions apply to the same order
- And the promotions are not set as stackable
- When the customer views the cart
- Then only the promotion with the higher precedence is applied
- And the cart shows which promotion was used
Return eligibility
- Given an order was delivered within the market's return window
- And the returned product is a hygiene item that has been unsealed
- When the customer requests a return for a change of mind
- Then the return is declined with the market's hygiene policy message
- And the customer is offered the warranty route if the product is faulty
Delivery and support
How did development and support follow the baseline?
Development and support used the same requirements, so the business validated a requirement once and then saw it carried through to the live site.
Backlog from the baseline
Epics and user stories were derived from the BRD, and each story was linked to its requirement, process model and acceptance criteria.
Analysts in the sprint cycle
Our analysts joined backlog refinement and sprint planning, answered questions on business rules, and clarified edge cases before development started on them.
Change control
New ideas were assessed against the baseline. Each one either became a change request, with its impact on effort, timeline and dependent stories recorded for the product owner to decide, or was parked for a later release.
Testing against criteria
Test scenarios came straight from the acceptance criteria. Business owners ran user acceptance testing market by market, and a story was accepted only when all of its criteria were met.
Hypercare and support
After launch, every issue was triaged against the acceptance criteria. If the build did not meet a criterion, the issue was a defect and was fixed. If the build met the criteria but the business wanted different behaviour, it was logged as an enhancement for the product owner to prioritize.
Living documentation
The baseline, decision tables and process models were updated with every approved change, so support teams always had current rules to work from.
Privacy
How did we handle privacy and discretion?
In this category, privacy affects how customers experience the brand, not just compliance. Discretion requirements were written for every customer touchpoint and tested like any other requirement.
- Data minimization: only data needed for orders, warranty and support was collected, with retention periods agreed for each data type.
- Order data, warranty claims and support conversations were treated as sensitive personal data under GDPR, with restricted access in back-office tools.
- Card statement descriptors, email subject lines, sender names and SMS content followed agreed neutral wording.
- Discreet outer packaging was a requirement for all direct shipments, with no product imagery on external labels.
- Proof-of-purchase uploads for warranty claims were stored securely and deleted after the claim was closed and the retention period had passed.
Which BA techniques and tools did we use?
Techniques
- Stakeholder mapping
- RACI
- Interviews and workshops
- Document analysis
- BRD authoring
- BPMN process modelling
- Business rules analysis
- Decision tables
- Given/When/Then acceptance criteria
- Non-functional requirements
- Requirements baselining
- Change control
- Requirements traceability
- UAT planning
- Defect triage
Tools
- Jira
- Confluence
- Lucidchart
- Miro
- Microsoft Excel
- Drupal Commerce
Results
What were the results?
- 160+ countries where LELO sells, each with its own rules
- 1 signed-off requirements baseline for development, testing and support
- 4 market clusters covered in elicitation workshops
- ~3 months of requirements work before the build started
A signed-off requirements baseline that development, testing and support all worked from.
- Scope tied to validated business needs, with changes handled through change control instead of being added mid-sprint.
- Consistent rules for pricing, promotions, availability and after-sales across markets.
- Warranty claims and returns handled through structured flows instead of email.
- A discreet customer experience built into the requirements for every touchpoint.
- A clear line between defects and change requests after launch, which reduced disputes during support.
“
Lessons learned
What can other e-commerce teams learn from this project?
- Validate before you build. A signed-off baseline turns scope debates into change decisions.
- Write acceptance criteria with the business, not just for it. Criteria the business helped write are criteria it will accept.
- Put market rules in decision tables. Global commerce depends on getting rule precedence right.
- In sensitive product categories, treat discretion as a requirement for every touchpoint, not a design preference.
- Use acceptance criteria to separate defects from changes. It keeps support fair to both the business and the delivery team.
Do your change requests keep turning into rework?
Talk to a senior business analyst about setting a validated requirements baseline before you build, then keeping delivery and support tied to it.
LELO: Requirements-Led Delivery for a Global Luxury E-Commerce Brand
