# Intent Specification: Abandoned Cart Recovery System

> **Intent-Driven Development - Worked Example**
> Version 0.2 | 13th April 2026
> intentdrivendevelopment.org

---

## About This Example

This is a complete IDD intent specification for an e-commerce abandoned cart recovery system. It demonstrates how the six elements of an Intent-Driven specification work together in practice.

The example is deliberately comprehensive. Not every specification needs this level of detail; the depth of specification should match the level of risk and complexity involved. But teams new to IDD will find this useful as a reference for what a thorough specification looks like when the stakes are high.

This worked example is referenced in Chapter 4 of the [IDD ebook](https://intentdrivendevelopment.org).

---

## Element 1: Intent - The Why and the What

### Problem Statement

Approximately 70% of online shopping carts are abandoned before checkout. Each abandoned cart represents a customer who demonstrated clear purchase intent but did not complete the transaction. The reasons vary: unexpected costs, friction in the checkout flow, distraction, comparison shopping, or simply not being ready to buy.

Currently, the organisation has no systematic mechanism for re-engaging these customers. Abandoned carts represent the single largest source of lost revenue in the e-commerce operation.

### Purpose

Build an abandoned cart recovery system that identifies carts at risk of abandonment, re-engages customers through personalised, well-timed communication, and provides a low-friction path back to checkout, whilst respecting customer preferences, privacy, and regulatory obligations.

### Business Outcome

Recover a measurable proportion of abandoned carts, increasing completed transactions without introducing aggressive or intrusive behaviour that damages brand trust.

### Success Metric

Recover at least 12% of abandoned carts within the first 90 days of operation, measured as completed checkouts directly attributable to recovery communications.

### Who Benefits

- **Customers** - reminded of items they intended to purchase, with a convenient path back to checkout.
- **The business** - increased conversion rate and revenue from existing traffic, without additional acquisition spend.
- **Customer support** - reduced volume of "where did my cart go?" enquiries.

### Who Is Accountable

The Product Owner for the e-commerce platform is accountable for the business outcomes. The engineering team is accountable for the technical implementation. The marketing team is accountable for communication content and tone. The data protection officer is accountable for compliance with data handling obligations.

---

## Element 2: Domain Context - The World

### Bounded Context

This system operates within the **Shopping** bounded context and interacts with the **Customer**, **Payments**, and **Communications** bounded contexts. It does not own the checkout process, payment processing, or customer identity; it consumes events and data from these contexts.

### Key Entities

| Entity | Description | Owned By |
|---|---|---|
| **Cart** | A collection of items a customer intends to purchase. Has a lifecycle: active → abandoned → recovered → expired. | Shopping |
| **CartItem** | A product added to a cart, with quantity, price at time of addition, and variant details. | Shopping |
| **Customer** | The person who owns the cart. May be authenticated (logged in) or anonymous (cookie-based). | Customer |
| **RecoveryAttempt** | A single communication sent to recover an abandoned cart. Tracks channel, timing, content variant, and outcome. | Recovery (this system) |
| **RecoverySequence** | The full series of recovery attempts for a single abandoned cart. Tracks escalation rules and suppression. | Recovery (this system) |
| **CommunicationPreference** | The customer's opt-in/opt-out status for each communication channel. | Customer / Communications |

### Aggregates

- **Cart** - the aggregate root for the shopping context. Cart state transitions (active, abandoned, recovered, expired) are the primary events this system consumes.
- **RecoverySequence** - the aggregate root for the recovery system. All recovery attempts for a given cart are managed through the sequence, which enforces timing, escalation, and suppression rules.

### Ubiquitous Language

| Term | Meaning |
|---|---|
| **Abandoned** | A cart that has had no customer activity for a configurable threshold period (default: 60 minutes). |
| **Recovery** | The process of re-engaging a customer whose cart has been classified as abandoned. |
| **Recovery window** | The time period during which recovery attempts are permitted (default: 72 hours from abandonment). |
| **Suppression** | A rule that prevents further recovery attempts - triggered by customer opt-out, completed purchase, or maximum attempts reached. |
| **Attribution** | The mechanism for crediting a completed checkout to a specific recovery attempt. |
| **Re-engagement** | A customer returning to their cart via a recovery communication link. |
| **Cart expiry** | The point at which an unrecovered cart is archived and no further recovery is attempted (default: 30 days). |

### Domain Rules

1. A cart is classified as abandoned only after the threshold period has elapsed with no customer activity.
2. Recovery attempts must not begin until the minimum delay has elapsed (default: 60 minutes after abandonment).
3. A maximum of three recovery attempts are permitted per abandoned cart.
4. Recovery attempts must respect the customer's communication preferences. If the customer has opted out of a channel, that channel must not be used.
5. If the customer completes a purchase (of any cart), all active recovery sequences for that customer are immediately suppressed.
6. Recovery communications must reflect the cart contents at the time of sending, including current stock availability and pricing.
7. If a cart item is no longer available, the recovery communication must acknowledge this rather than linking to an unavailable product.

### Integration Points

- **Cart Events**: consumes `CartAbandoned`, `CartUpdated`, `CartCheckedOut`, `CartExpired` events from the Shopping context.
- **Customer Service**: reads communication preferences and customer profile data.
- **Communications Service**: sends recovery messages via email, SMS, and push notification channels.
- **Product Catalogue**: reads current product availability, pricing, and imagery at the time of sending.
- **Analytics**: publishes recovery events (`RecoveryAttemptSent`, `RecoveryLinkClicked`, `CartRecovered`, `RecoverySequenceSuppressed`) for downstream analysis.

---

## Element 3: Success Criteria - The Done

### Functional Requirements

1. The system correctly identifies abandoned carts within 5 minutes of the abandonment threshold being reached.
2. The first recovery communication is sent within the configured delay window (default: 60–90 minutes after abandonment).
3. Recovery communications are personalised with the customer's name (if known), cart contents, product images, and a direct link back to their cart.
4. The system supports three communication channels: email, SMS, and push notification.
5. The system enforces the configured maximum number of recovery attempts per cart.
6. The system suppresses all recovery activity for a customer who completes a purchase or opts out.
7. The system correctly attributes recovered carts to the recovery attempt that prompted re-engagement.
8. The system provides a real-time dashboard showing: carts currently in recovery, recovery rate, revenue recovered, and channel performance.

### Non-Functional Requirements

| Requirement | Target |
|---|---|
| **Latency** | Cart abandonment detection within 5 minutes of threshold. |
| **Throughput** | Support up to 50,000 simultaneous abandoned carts in recovery. |
| **Availability** | 99.9% uptime for the recovery service. |
| **Email delivery** | First recovery email sent within 90 minutes of abandonment. |
| **SMS delivery** | Recovery SMS sent within 5 minutes of scheduled time. |
| **Push notification** | Delivered within 30 seconds of trigger. |
| **Attribution accuracy** | 99% accurate attribution of recovered carts to recovery attempts. |
| **Data retention** | Recovery data retained for 13 months for analytics, then anonymised. |

### BDD Acceptance Criteria

```gherkin
Feature: Cart Abandonment Detection

  Scenario: Cart is classified as abandoned after threshold
    Given a customer has items in their cart
    And the customer has had no activity for 60 minutes
    When the abandonment detection process runs
    Then the cart is classified as "abandoned"
    And a CartAbandoned event is published

  Scenario: Cart activity resets the abandonment timer
    Given a customer has items in their cart
    And the customer has had no activity for 45 minutes
    When the customer updates their cart
    Then the abandonment timer is reset
    And the cart remains classified as "active"

  Scenario: Empty cart is not classified as abandoned
    Given a customer has an empty cart
    And the customer has had no activity for 60 minutes
    When the abandonment detection process runs
    Then the cart is not classified as abandoned

Feature: Recovery Communication

  Scenario: First recovery email is sent after configured delay
    Given a cart has been classified as abandoned
    And the customer has opted in to email communication
    When 60 minutes have elapsed since abandonment
    Then a personalised recovery email is sent to the customer
    And a RecoveryAttemptSent event is published

  Scenario: Recovery respects communication opt-out
    Given a cart has been classified as abandoned
    And the customer has opted out of email communication
    When the recovery sequence is initiated
    Then no email is sent to the customer
    And the system attempts the next available channel

  Scenario: Recovery is suppressed after purchase
    Given a customer has an active recovery sequence
    When the customer completes a purchase
    Then all active recovery sequences for that customer are suppressed
    And no further recovery communications are sent

  Scenario: Recovery is suppressed after maximum attempts
    Given a customer has received 3 recovery communications
    When the system evaluates the next recovery step
    Then the recovery sequence is marked as complete
    And no further recovery communications are sent

Feature: Cart Recovery Attribution

  Scenario: Recovered cart is attributed to recovery attempt
    Given a customer received a recovery email
    When the customer clicks the recovery link in the email
    And the customer completes checkout within 24 hours
    Then the completed checkout is attributed to that recovery attempt
    And the recovery sequence is marked as "recovered"

  Scenario: Organic return is not attributed to recovery
    Given a customer has an active recovery sequence
    When the customer returns to their cart via a direct URL (not a recovery link)
    And the customer completes checkout
    Then the completed checkout is not attributed to recovery
    And the recovery sequence is suppressed

Feature: Out-of-Stock Handling

  Scenario: Recovery communication reflects current availability
    Given a cart contains an item that is now out of stock
    When a recovery communication is generated
    Then the communication indicates the item is no longer available
    And suggests similar products if available
    And does not include a link to the unavailable product
```

---

## Element 4: Validation - The Proof

### Test Strategy

| Category | Approach |
|---|---|
| **Unit tests** | All domain logic (abandonment detection, timing rules, suppression logic, attribution) tested in isolation. |
| **Integration tests** | Event consumption from Shopping context, communication delivery via all channels, product catalogue lookups. |
| **End-to-end tests** | Full recovery flow from cart abandonment through communication delivery, customer re-engagement, and checkout attribution. |
| **Performance tests** | Load testing with 50,000 concurrent abandoned carts; verify latency targets under load. |
| **Chaos tests** | Communication service failure, product catalogue unavailability, event bus delays. |

### Critical Edge Cases

1. **Customer abandons, then returns and abandons again.** The second abandonment should start a new recovery sequence only if the previous one has completed or been suppressed.
2. **Customer is mid-recovery when they make a purchase from a different device.** The purchase event must suppress the recovery sequence regardless of device or session.
3. **Cart items change price between abandonment and recovery communication.** The communication must reflect the current price, and if the price has increased, this should be clearly indicated.
4. **Customer receives a recovery email, clicks the link, but the cart has expired.** The system should present a meaningful message and offer to recreate the cart if the items are still available.
5. **Bulk abandonment event** (e.g., site outage causes thousands of simultaneous abandonments). The system must rate-limit recovery communications to avoid overwhelming the email service and triggering spam classification.
6. **Time zone handling.** Recovery communications must be sent during reasonable hours (08:00–21:00) in the customer's local time zone. Communications scheduled outside this window are deferred to the next appropriate time.
7. **Customer unsubscribes via the recovery email.** The unsubscribe action must be processed immediately, suppressing all further recovery communications and updating the customer's communication preferences.
8. **Concurrent cart updates during recovery.** If a customer updates their cart while a recovery communication is being generated, the communication must reflect the most recent cart state or be cancelled and rescheduled.

### Failure Modes

| Failure | Expected Behaviour |
|---|---|
| Email service unavailable | Retry with exponential backoff (max 3 retries). If all retries fail, fall back to next available channel. Log the failure. |
| Product catalogue unavailable | Defer the recovery communication until the catalogue is available. Do not send a communication with stale product data. |
| Event bus delayed | Recovery timing is based on the abandonment timestamp in the event, not the time the event is received. Late events are still processed correctly. |
| Database failure | Recovery state is event-sourced. The system can rebuild state from the event log. |
| Customer service unavailable | Use cached communication preferences (max cache age: 5 minutes). If no cached data is available, defer the communication. |

---

## Element 5: Constraints - The Boundaries

### Technical Constraints

- **Architecture**: Event-driven microservice. Consumes events from the shopping context via the existing message bus (Kafka). Publishes its own events to the same bus.
- **Infrastructure**: Deployed on the existing Kubernetes cluster. Must operate within the current infrastructure budget with no additional dedicated hardware.
- **Data store**: PostgreSQL for recovery sequence state. Event log stored in the existing event store.
- **Communication delivery**: Uses the existing Communications Service API. Does not implement its own email/SMS/push delivery.
- **Monitoring**: Integrated with the existing observability stack (Prometheus, Grafana, PagerDuty).

### Architectural Patterns

- Event sourcing for recovery sequence state.
- CQRS for read models (dashboard queries separated from command processing).
- Idempotent event handlers (duplicate events must not result in duplicate recovery attempts).
- Circuit breaker pattern for external service calls (communications service, product catalogue).

### Regulatory Constraints

| Regulation | Requirement |
|---|---|
| **GDPR** | Customer data processed under legitimate interest for existing customers. Consent required for marketing communications. Right to erasure must be supported; customer deletion removes all recovery data. Data processing records must be maintained. |
| **PECR / ePrivacy** | Email recovery communications are permitted for existing customers under the "soft opt-in" provision, provided the customer has an easy opt-out mechanism and the communication relates to similar products. SMS requires explicit prior consent. |
| **PCI-DSS** | The recovery system must not store, process, or transmit payment card data. Cart data must not include payment details. |
| **WCAG 2.1 AA** | Recovery landing pages and any web-based communications must meet WCAG 2.1 AA accessibility standards. |
| **CAN-SPAM / CASL** | Where customers are in US/Canadian jurisdictions, recovery emails must comply with CAN-SPAM (US) and CASL (Canada) requirements, including clear identification, valid physical address, and functional unsubscribe mechanism. |

### Existing System Constraints

- The Cart service publishes events but does not support synchronous queries for cart state. Cart data is embedded in the event payload.
- The Communications Service has a rate limit of 500 emails per minute. Recovery communications must be scheduled to stay within this limit.
- The Customer service exposes communication preferences via a REST API with a 200ms SLA.
- The Product Catalogue API has a 500ms SLA and supports batch queries of up to 50 products.

---

## Element 6: Ethical Considerations - The Should We

### Impact Assessment

| Stakeholder | Positive Impact | Potential Harm |
|---|---|---|
| **Customers who want to complete their purchase** | Reminded of items they intended to buy; convenient return path. | None, this is the ideal case. |
| **Customers who abandoned deliberately** | None, they chose not to buy. | May feel harassed, pressured, or surveilled. May damage brand trust. |
| **Vulnerable customers** | May be reminded of essential items they forgot. | May feel pressured to spend money they cannot afford. Recovery communications could contribute to financial harm. |
| **The business** | Increased revenue from existing traffic. | Reputation damage if recovery is perceived as aggressive. Regulatory risk if compliance is not maintained. |

### Ethical Principles

1. **Respect over revenue.** The system must prioritise customer experience over conversion. A customer who feels respected is more valuable long-term than a single recovered transaction.
2. **Transparency.** Customers must understand why they are receiving recovery communications and how their data is being used. No dark patterns.
3. **Easy exit.** Opting out of recovery communications must be immediate, permanent (until re-opted-in by the customer), and require no more than one click.
4. **No pressure tactics.** Recovery communications must not use false urgency ("only 2 left!"), manufactured scarcity, or emotional manipulation. If stock is genuinely low, this may be stated factually.
5. **Frequency limits.** The maximum of three recovery attempts is an ethical boundary, not just a business rule. Beyond three contacts, the customer has made their decision.
6. **Vulnerable customer protection.** The system should detect patterns that may indicate vulnerability (e.g., repeated abandonment of essential items, unusually high cart values relative to the customer's history) and suppress or modify recovery communications accordingly. This is a v2 enhancement but should be architecturally accommodated from the start.

### Mitigations

| Risk | Mitigation |
|---|---|
| Customer feels surveilled | Recovery emails explain clearly: "You left items in your cart. Here's a link to return to them." No implication of tracking behaviour beyond the cart itself. |
| Aggressive frequency | Hard cap of 3 attempts. Minimum 12 hours between attempts. Escalation only to less intrusive channels (e.g., email → push, never email → phone). |
| Financial pressure | No discount escalation in recovery sequence (e.g., no "10% off if you buy now" in the third email). Discounts, if used at all, are consistent across all recovery attempts. |
| Dark patterns | No countdown timers, no false scarcity, no guilt language. Communications are informational and helpful. |
| Data misuse | Recovery data is used only for recovery and analytics. Not shared with advertising, not used for profiling, not sold. |
| Accessibility | Recovery emails are screen-reader compatible. Landing pages meet WCAG 2.1 AA. Alternative text provided for all product images. |

### Ethical Boundaries — Not Delegated

The following decisions are permanently under human control and are not subject to AI optimisation:

- **Maximum contact frequency.** AI may not increase the number of recovery attempts beyond the configured maximum, even if data suggests higher frequency would improve conversion.
- **Communication tone.** AI may personalise content but may not introduce urgency, scarcity, or emotional pressure language.
- **Discount strategy.** AI may not autonomously offer discounts to recover carts. Discount strategy is a business decision with margin implications.
- **Channel escalation.** AI may not escalate to more intrusive channels (e.g., from email to SMS to phone) without explicit configuration by the business.
- **Vulnerable customer identification.** Criteria for identifying and protecting vulnerable customers are defined by humans, not learned by the system.

---

## Summary

This specification defines a system that is commercially valuable, technically bounded, ethically grounded, and measurable. It provides enough structure for an autonomous system to implement reliably, while keeping the decisions that matter, tone, frequency, ethics, and customer respect, firmly in human hands.

The six elements work together:

- **Intent** establishes why this system exists and what outcome it must produce.
- **Domain Context** grounds the specification in the business reality it operates within.
- **Success Criteria** define what "done" looks like, in measurable terms.
- **Validation** specifies how we will prove it works, including edge cases and failure modes.
- **Constraints** establish the technical, architectural, and regulatory boundaries.
- **Ethical Considerations** ensure we are building something we should build, not just something we can build.

> *Govern Intent. Delegate Execution.*

---

*This worked example is part of Intent-Driven Development (IDD), a methodology for specifying, measuring, governing, and scaling human intent in the age of agentic AI.*

*Download the free ebook at [intentdrivendevelopment.org](https://intentdrivendevelopment.org).*

*Original articles at [richardstockley.com](https://richardstockley.com).*