Recommendation models trained on your transaction history using a hybrid approach: collaborative filtering identifies customers with similar purchase patterns (Alternating Least Squares matrix factorisation for implicit feedback data; Bayesian Personalised Ranking for sparse transaction logs); content-based filtering recommends products similar to what the customer has already bought (TF-IDF product attribute vectors or BERT-based embeddings for richer semantic similarity); and popularity signals ensure high-margin items get appropriate exposure to new customers with limited purchase history. Model outputs are merged and re-ranked using a lightweight gradient boosting reranker trained on click and conversion labels, so the final list reflects both predicted affinity and business objectives (margin, inventory clearance, new product introduction).

Recommendation types produced per customer: next product (what they're most likely to buy on the next visit), cross-sell (products bought together by similar customers, applied at basket or checkout), upsell (higher-margin variants of a viewed product), and replenishment timing (when consumable items are likely to run out based on average consumption rate). Feature store: customer features (30-day, 90-day, and lifetime purchase history aggregations, category affinity scores, day-of-week and time-of-day purchase patterns) stored in a Feast-compatible feature store or a materialised PostgreSQL/Redshift table with scheduled refresh. Model retraining triggered on a weekly schedule or when performance metrics drop below a defined threshold (precision@10 below 0.15, NDCG below 0.20).

Output integration: a REST API endpoint (POST /recommendations?customer_id=X&context=homepage&limit=10) returns a ranked product list consumable by your storefront, email platform, or in-store display system. Response time under 50ms p99 with Redis caching of pre-computed recommendation vectors. Recommendation widgets A/B tested from day one: a holdout group receiving static bestseller lists provides the baseline conversion rate against which personalised recommendations are measured. A 5-20% basket size lift is typical when personalisation replaces static featured-product logic; we track the specific metric agreed at project start.

SKU-level and location-level demand forecasts trained on your sales history, promotional calendars, and external signals. The forecasting stack combines multiple model types: LightGBM with lag features (7-day, 14-day, 28-day rolling sales, day-of-week indicators, month-of-year encoding, promotional flag), Facebook Prophet for strong seasonal decomposition (weekly seasonality, annual seasonality, holiday effects with a custom holiday calendar for your trading geography), and LSTM networks for SKUs with complex temporal dependencies that tree models underfit. An ensemble weighted by validation-set MAPE (Mean Absolute Percentage Error) per SKU is used in production -- different model types outperform on different SKU profiles, and ensemble blending produces lower aggregate error than any single model.

External signals incorporated where available: weather (temperature correlation for seasonal categories -- outdoor furniture, cold-weather apparel, ice cream), local events from an event API (sports fixtures, concerts, public holidays near each store location), and competitor pricing signals from web scraped price indexes where publicly available. Promotional lift modelling: each planned promotion is tagged with a promotional type (BOGO, percentage discount, multipack), and historical promotional events are used to fit a lift multiplier per promotional type per category -- so the forecast for a planned 20%-off promotion next week incorporates observed lift from comparable past promotions rather than ignoring the promotion entirely.

Forecast output: daily or weekly point estimates per SKU per location with 80% and 95% prediction intervals (not just a point estimate, because the variance drives safety stock calculations). Accuracy metrics tracked weekly: MAPE per SKU, WAPE (Weighted Absolute Percentage Error) across the SKU range, and a coverage rate (what percentage of actual sales fell within the predicted interval). Forecasts served via API to your replenishment or purchasing system -- reorder point and suggested order quantity computed from the forecast and safety stock formula (Z-score × forecast standard deviation × lead time). MLflow tracks all model versions, training parameters, and validation metrics so any model can be inspected and any historical forecast can be reproduced.

Dynamic pricing models optimise revenue or margin within rules you define, rather than replacing pricing judgment with an opaque algorithm. Rules layer: minimum price floor (cost + minimum margin %), maximum price ceiling (RRP or competitive ceiling), competitor price floor (never drop below competitor price × 0.95), and category-level price change frequency (e.g., electronics prices can update daily; fashion prices update weekly). Within these constraints, the model recommends prices based on demand signals.

Price elasticity estimation: the model learns the price-demand relationship for each product or category from historical transaction data, controlling for promotions, seasonality, and inventory position. Elasticity is estimated using linear regression on log(price) → log(demand) with control variables, or a causal inference approach (differences-in-differences on historical price experiments) where randomised price testing history is available. Products with high elasticity (demand drops sharply when price increases) are priced conservatively; products with low elasticity (demand is insensitive to price) can capture more margin from price optimisation.

Dynamic rules applied: demand-based uplift (price increases when conversion rate or add-to-cart rate is significantly above the category baseline -- indicating unmet demand at current price), inventory-based markdown (price decreases triggered by days-of-cover falling above a threshold -- clearing slow-moving stock before it becomes a write-off), time-based markdown for perishables (price reduction schedule triggered by days-to-expiry, calibrated to clear stock by expiry without excessive early discounting), and competitor response (price adjustment when a tracked competitor changes price within the monitoring window -- scraped via a price intelligence service or a custom web scraper).

Explainability: every price recommendation is logged with the primary driver (demand signal, inventory level, competitor price, expiry schedule) so the merchandising team understands and can override individual recommendations. Override rate is tracked as a quality metric -- a consistently overridden recommendation type indicates a model assumption that doesn't match merchandiser judgment and should be recalibrated.

Churn prediction for retail differs from subscription churn because there is no cancellation event -- customers simply stop buying. The model learns the behavioural patterns that precede departure: recency crossing a threshold (days since last purchase exceeding the customer's historical inter-purchase interval), declining purchase frequency (3-month trend vs. 12-month baseline), reducing basket size (comparing recent average order value to the customer's historical average), shift from full-price to promotional-only purchasing (a customer who previously bought at full price now only activating on discounts signals impending churn), and reduction in category breadth (a customer previously buying across 5 categories now buying from 1).

Model architecture: LightGBM classifier trained on a rolling window of RFM (Recency, Frequency, Monetary) features plus engagement signals. Features engineered at 30-day, 90-day, and 12-month windows with rolling ratios that capture trend direction, not just level. SHAP (SHapley Additive exPlanations) values computed per prediction so the retention team knows whether a specific customer's high-risk score is driven by recency (hasn't bought in 60 days), frequency decline (buying half as often), or value decline (spending 40% less per basket). SHAP-driven personalisation: the primary churn driver informs the intervention type (a recency-driven customer gets a "we miss you" offer; a value-declining customer gets a product upgrade recommendation).

Intervention threshold calibration: the probability threshold triggering intervention is tuned against customer lifetime value and promotional cost, not optimised purely for prediction accuracy. A threshold set too low wastes promotional budget on customers who would buy at full price anyway. A threshold set too high misses recoverable customers. We calibrate on a holdout cohort tracking 90-day repurchase rate by score decile, adjusting the threshold so the intervention ROI (incremental repurchase revenue minus promotion cost) is maximised. Customers above threshold route into a retention sequence in your email or CRM platform via API, with a 30-day measurement window to track whether the sequence recovered the customer or not.

Computer vision models that let customers find products by image: upload a photo of an item they've seen (in a magazine, on social media, on a friend), and the system returns the closest matches in your catalogue. Visual search is particularly effective in categories where the customer's intent is visual -- apparel, home furnishings, footwear, accessories -- and where keyword search underperforms because the customer cannot describe the specific item in text ("navy blue with a subtle diamond weave texture and a slight sheen" is not a natural search query; a photo is).

Model architecture: CLIP (Contrastive Language-Image Pre-training) fine-tuned on your product image catalogue produces embeddings that encode both visual appearance and semantic content in the same vector space. This enables combined text + image queries: "find this style but in green" processes the image and the text colour modifier together. For pure visual search, the query image is embedded by the same encoder, and approximate nearest neighbour search (using FAISS flat L2 index for catalogues under 500K items; FAISS HNSW or Pinecone Serverless for larger catalogues) retrieves the top-K closest product embeddings in under 100ms.

Product image preparation: each product image is preprocessed (background removal using rembg library or a fine-tuned segmentation model for apparel, where the clothing silhouette should dominate the embedding rather than the model, background, or props). Multiple product images per SKU (front, side, detail shots) are aggregated into a mean embedding with optional max-pooling over the detail dimensions to capture attribute-level similarity as well as overall visual match. The product embedding index is updated incrementally when new products are added -- no full index rebuild required for individual additions.

Integration: a REST endpoint (POST /visual-search with an image upload or image URL) returns ranked product IDs with similarity scores, consumable by your storefront search results page, mobile app, or in-store kiosk. Query images are not stored after processing unless the client opts in to using query logs for future model improvement.

NLP models that process customer reviews, support ticket text, and social media mentions at scale to extract structured sentiment intelligence: which products generate the most complaints, which complaints are trending week-over-week, which store locations or fulfilment centres generate disproportionate negative feedback, and which specific product attributes (fit, quality, durability, delivery speed, packaging) drive satisfaction or dissatisfaction. The output replaces quarterly customer satisfaction surveys with a continuous signal from unsolicited customer language -- a data source that captures authentic opinions without survey response bias.

Aspect-based sentiment analysis (ABSA) using a fine-tuned RoBERTa model identifies sentiment at the attribute level rather than the document level. A review that says "the fabric is beautiful but the sizing runs small and delivery took three weeks" extracts three distinct sentiment signals (positive: fabric quality; negative: sizing; negative: delivery time) rather than a single mixed-sentiment document score. This attribute-level granularity gives the product team actionable feedback: a sizing problem routes to the buying or design team; a delivery time problem routes to fulfilment operations.

Topic modelling using BERTopic (BERT embeddings + UMAP dimensionality reduction + HDBSCAN clustering) surfaces emerging complaint themes before they appear in aggregate ratings: a new quality issue affecting a specific product batch shows up as a growing topic cluster in review data 2-3 weeks before the aggregate rating changes meaningfully. Named entity recognition extracts product model numbers, store location names, and competitor mentions from unstructured review text for structured downstream querying.

Operational integration: a scheduled pipeline (daily or weekly depending on review volume) extracts new reviews from your review platform (Trustpilot API, Google My Business API, Bazaarvoice, Yotpo) and support tickets from Zendesk/Freshdesk, processes them through the NLP pipeline, and writes structured sentiment records to a database. A Metabase or Power BI dashboard surfaces the top-20 complaint topics by volume and trend, per-product sentiment scores over time, and the specific reviews driving any notable sentiment shift -- a direct link from the dashboard row to the source reviews so the operations or product team can read the verbatim language without needing to write a query.