# Case studies — gaganmalik.io Last-Updated: 2026-06-13 ## Case studies ### Simplifying sales reporting (Apple) [View case study](https://www.gaganmalik.io/en/success-stories/apple) **One live picture field teams and leadership could trust.** Conflicting apps left Apple's sales organisation reconciling spreadsheets instead of acting on one set of numbers. The opportunity was to unify reporting so everyone read the same view, with answers in the app instead of attachment chains. **The Opportunity** — Eight tools, no shared truth for performance questions Apple's global sales organisation ran on a patchwork of tools. Teams across major regions jumped eight apps for basic performance questions. Figures did not always match, field work slowed, and nobody had one live view that tied hardware, services, and channel together. **The Solution** — One mobile-first analytics app: same numbers for field, leadership, and partners We designed a mobile-first sales analytics app so fragmented data lived in one place for field teams. Dashboards drew the same numbers for every product line, region, and channel; analytics layers supported quarterly planning; channel views let account executives see distributors, carriers, and retail side by side; reporting replaced hand-built spreadsheets with up-to-date figures for spotting gaps. It worked with Apple's existing CRM, with offline modes for people working across regions. **The Impact** — One live view replaced eight tabs and cut weekly debates over the numbers One app replaced the habit of checking eight systems and disagreeing on the figure. Account executives saw the same real-time picture as leadership, so demand conversations and channel plans started from shared data. Partner briefings matched what executives saw without reconciliation drag. Less time matching spreadsheets meant more time on planning and execution; field plans could stay aligned with quarterly goals because everyone started from the same screen. Takeaways: - One source of truth removes most of the reconciliation work that slowed decisions. - Mobile-first with offline coverage matters when your job is airports and shops, not desks. - When leadership and the field read the same dashboard, plans stop arguing with each other. --- ### Better onboarding and activation (Google) [View case study](https://www.gaganmalik.io/en/success-stories/google) **Finish setup, then let ML earn.** Publishers and advertisers had capable tools, but activation stalled on onboarding: scattered guidance and manual steps meant many never enabled Auto Ads. The job was to simplify setup and shorten time to value with clearer onboarding email flows. **The Opportunity** — Two million publishers leaving revenue on the table without Auto Ads Auto Ads used ML to place ads and find inventory site owners missed, but most publishers never turned it on. The integration was one snippet, yet it read opaque if you did not ship code daily. Manual placements stayed familiar; the ML path sounded like a black box. Automated monetisation only paid off after setup finished; competitors were ready to capture anyone who quit halfway. **The Solution** — Segmented email: explain the product, paste the tag, verify reporting We used email to close the gap: segmented sends so each publisher saw copy that matched where they were stuck: first what Auto Ads actually did, then how to paste the tag, then what to check in reporting. Side-by-side examples showed ML placements next to manual ones; follow-up messages walked through the code with screenshots. Publisher stories with real revenue lifts went out as proof, and deeper mails covered mobile anchor ads, AMP, and cross-device setups for people ready for more. **The Impact** — Higher completion, fewer tickets, more inventory surfaced by ML Completion rates went up once the emails explained Auto Ads in plain steps, and support tickets dropped. More publishers switched Auto Ads on, so Google's models could surface inventory that manual setups skipped. Publishers spent less time babysitting placements and more time on their sites; AdSense kept category leadership because adoption finally matched product depth. Takeaways: - Segmented email met publishers where they stalled on Auto Ads setup. - Plain steps and screenshots beat abstract ML explanation for non-technical owners. - Proof from publishers who saw revenue lifts beat feature lists for cautious adopters. --- ### Improving restaurant order tracking (Just Eat) [View case study](https://www.gaganmalik.io/en/success-stories/just-eat) **Know each ticket's state before the courier arrives.** Restaurant teams run Orderpad beside rival tablets on one counter. Just Eat asked for a side-by-side review against Deliveroo, Uber Eats, Grubhub, and SkipTheDishes to see where friction appeared first. I ran a Nielsen-style heuristic audit that split quick UI fixes from deeper product bets. **The Opportunity** — Growth rode on counters where Orderpad lost the comparison Just Eat's partner base depended on small kitchens tolerating chaos: when a rider app, phone line, and multiple aggregators compete for attention, staff reach for the tablet that makes the next step obvious. Orderpad could accept orders, but it often failed to show **where** each ticket sat in the flow, **when** food needed to be ready for handoff, or **what** tapping **On Its Way** committed to downstream. Teams worked around those gaps; the cost showed up as late deliveries, support calls, and poor reviews. Partners also needed Partner Centre tasks (hours, radius, pricing, cancellations) without leaving the tablet during service. That gap hit live operations, not only convenience. Just Eat needed an outside-in read before roadmap and engineering commits. **The Solution** — Same rubric across five brands: product, surveys, and live-shift observation I structured the audit around six Nielsen-based review areas: system status, fit for kitchen work, control and speed, recognition over recall, layout clarity, and error recovery. I applied the same rubric to Just Eat, Deliveroo, Uber Eats, Grubhub, and SkipTheDishes so results were directly comparable. I combined product walkthroughs, competitor analysis, partner surveys, and in-restaurant observations during live service. That gave evidence from both interface behaviour and real operating conditions (noise, rush periods, multilingual teams). The output was one scoring sheet, short theme briefs with screenshots, and a prioritized readout that separated quick fixes from business-level decisions. **The Impact** — Lowest score on the five-brand roll-up, plus survey counts finance could fund against Across Deliveroo, Grubhub, Uber Eats, SkipTheDishes, and Just Eat, the combined heuristic roll-up put Orderpad last. That was uncomfortable in the room, but it replaced opinion with one curve everyone could point to: the gap ran across status, fit to kitchen reality, control, and recovery, not a single bad icon. Partner research gave the business hard counts to fund against. In-product surveys showed **82%** of partners rated reaching Partner Centre from Orderpad as important, and **56%** wanted a clearer view of drivers on busy nights (while optional driver tooling sat at almost no adoption next to rivals who ship live tracking by default). Those numbers turned "they keep asking" into backlog pressure with a size on it. Nothing in an audit ships pixels by itself. What shipped was clarity: a ranked set of themes, a cut between work that could ride normal release cadence and work that needed brand or policy concessions, and constraints spelled out in the deck so roadmap bets matched what ops could open and what contracts allowed. Takeaways: - A shared score beats slide battles when every team has a different favourite fix. - Survey percentages turn partner noise into something finance and product can sequence. - Say what you will not fix in v1; partners accept limits they can see on paper. --- ### Gamified car insurance (Aviva) [View case study](https://www.gaganmalik.io/en/success-stories/aviva) **Price cover from how people drive, not only where they live.** UK motor cover still leaned on coarse segments; Aviva saw a chance to differentiate with behaviour-based pricing and engagement: reward safer driving and make insurance feel personal instead of punitive. **The Opportunity** — Demographic buckets masked real driving risk on the road UK car insurance still leaned on broad demographic buckets: safer drivers often paid like risky ones because price was not tied to trips on the road. Most people think they drive better than average, so flat stereotypes felt unfair and missed real risk. Aviva needed a signal from the vehicle, not only the postcode on the form. **The Solution** — UK-first smartphone telematics: score the trip, quote from behaviour Aviva shipped the UK's first smartphone-based telematics app to price cover from how people actually drive. The app used GPS to log acceleration, braking, cornering, speed, and phone use over 200 miles. Drivers got a 1 to 10 score, quick feedback, optional sharing, and a direct path into a quote, so risk moved off postcode shortcuts and onto behaviour. **The Impact** — Downloads above plan, measurable savings, brand lift on invention Aviva Drive passed 1M downloads in about six weeks, well above the annual plan, picked up Apple's "App of the Week," and held around 4.5/5 in the store. Roughly four in ten users scored 7.1 or above and saved about £101 on average; most people in the programme qualified for some discount. The business case turned positive inside two years, and perception of Aviva as inventive moved up by 33 points, so telematics read as a practical product bet rather than a short campaign. Takeaways: - Behaviour-based pricing rewards actual performance instead of demographic assumptions. - Rewards landed when people could see them on the bill, not as decoration on a score screen. - Smartphone telematics can reach positive ROI within 18 to 24 months at scale. --- ### From Hold to Handled (Lloyds Banking Group) [View case study](https://www.gaganmalik.io/en/success-stories/lloyds-bank) **Move the busiest insurance jobs to self-serve without hiding edge cases.** Lloyds Banking Group needed retail service off hold queues and paper toward handheld, real-time flows. The opportunity was a shared UI pattern that put accurate policy actions in front of staff and customers at once. **The Opportunity** — National scale strain: three call types ate most handle time The UK's largest retail bank saw acute pressure in home insurance contact centres: high volume, rising cost, and frustrated customers. Three call types (amendments, cancellations, policy or cover queries) consumed nearly 75% of total handling time and over 250 FTEs. Average resolution ran from about six minutes to well over fifteen, leaving little slack for good service. **The Solution** — One design system, rule-based flows, volume shifted to digital routes As design director, I led a ten-person team across Lloyds Bank, Halifax, Bank of Scotland, and MBNA. We aligned on one design system, prototyped quickly, and tested with 200+ people to ship clear, rule-based flows for amendments and cancellations. Self-serve for policy queries reduced phone volume without pushing complexity onto customers, and agents stayed free for complex cases. **The Impact** — Average resolution fell about 75%; digital self-serve crossed 60% in six months Lloyds cut cost and frustration by moving the heaviest insurance jobs into digital self-serve: the same routes that had consumed three-quarters of handle time. Average resolution time fell by about 75%; digital self-serve crossed 60% within six months. Satisfaction climbed as waits and transfers shrank. Savings funded better service and simpler upsell paths on infrastructure the group could extend to the next wave of products. Takeaways: - One design system across brands cut rework while keeping Halifax, Lloyds, BoS, and MBNA consistent. - Self-serve for the highest-volume intents freed agents for judgement-heavy cases. - Rule-based flows tested at volume beat bespoke screens per brand for maintenance. --- ### Better product discovery (EE) [View case study](https://www.gaganmalik.io/en/success-stories/ee) **Match the mental model, stop the drop-off.** EE's range was vast, but navigation hid the jobs people came to finish. Tree testing and path analysis showed where the IA broke; the response was discovery rebuilt around real shopping tasks. **The Opportunity** — A £2.8B digital shopfront with navigation that leaked conversion EE UK's site carried enormous commercial weight, but the structure fought the customer. In testing, Shop read as overloaded and poorly grouped; fewer than half of wayfinding tasks ended in the right place. With most telecom sales starting on mobile and rivals offering cleaner paths, weak IA was direct revenue leakage. **The Solution** — Research-led mega-nav: My EE, Shop, Help instead of sprawl We ran tree tests and hybrid card sorts with ten people and rebuilt the nav around what they actually looked for: a three-bucket mega-nav (My EE, Shop, Help) instead of the old sprawl. Brands sat together in Shop; "Added benefits" moved to My EE because every participant looked there first; help content landed next to the tasks it supported. **The Impact** — Higher task success and faster discovery after the regroup After the change, tasks finished more often and people found products faster. Nobody had looked for "Added benefits" under Why EE; everyone expected handset brands under Shop. Odd buckets like "Good As New" and "EE TV" had confused two in five people; those labels got untangled. The durable lesson was simple: align structure with how people shop telecom on mobile, then measure completion instead of debating opinions. Takeaways: - Tree testing and card sorts pay off when navigation carries most of the discovery job. - Three buckets beat sprawl when shoppers need My EE, Shop, and Help without guessing. - Rename and regroup when completion scores show people never looked under the old bucket. --- ### Faster checkout (John Lewis) [View case study](https://www.gaganmalik.io/en/success-stories/john-lewis) **Cut discovery time and checkout friction without shrinking the range.** John Lewis customers navigated 400K+ products across home, fashion, and electronics. Finding the right item took too long, and checkout added drag. The work was to speed discovery and shorten checkout while keeping the breadth that defines the brand. **The Opportunity** — A loved brand, easy to get lost in a £15B online catalogue John Lewis runs enormous online range across 400,000+ SKUs. Loyal shoppers still stalled in category depth: filters failed to surface the right stock quickly, and Quick View stopped short of a confident buy. More than half of visits were on phones; next to Amazon and sharp DTC brands, small friction meant measurable revenue left on the table. **The Solution** — Filters with memory, Quick View that completes the job, clearer PDPs We focused on three pressure points in the shopping flow. **Filtering:** live counts, saved combinations, and suggestions from browse history so people narrowed the catalog without starting over each time. **Quick View:** size, colour, delivery, and checkout from the overlay instead of a dead-end preview. **Listing and product pages:** faster images, clearer hierarchy, and cross-sell blocks (including "Style with it") that nudged basket size without clutter. **The Impact** — About 35% faster discovery and roughly £8.2M incremental revenue in-year Filtering and Quick View cut time-to-product by about 35%; listing and product page work lifted engagement and basket size. The programme landed around £8.2M incremental revenue in the year we measured, with better checkout completion on mobile. Same brand promise with fewer dead ends: the durable gain was repeat visits that felt faster on small screens, not only a one-off campaign tweak. Takeaways: - Filters with live counts and saved combinations reduce restart friction on huge ranges. - Quick View earns its keep when size, delivery, and checkout live in the overlay. - Incremental revenue followed faster discovery plus clearer listing and product hierarchy. --- ### Predictable spend forecasting (Vodafone) [View case study](https://www.gaganmalik.io/en/success-stories/vodafone) **See IoT spend before the invoice closes.** Cost on Vodafone's IoT platform stayed opaque until billing landed; then finance, ops, and programme owners chased the same spike together. I tightened forecasting, caps, and alerts for earlier signal, and paired the UI with docs that matched how teams wired guardrails into production. **The Opportunity** — Spend moved for operational reasons; visibility landed after close On Vodafone's IoT platform, spikes came from rollouts, misconfigured devices, roaming, firmware shifts, and fleet usage, not one-off bugs. After billing closed you could explain what happened; you still could not reliably forecast the bill, set guardrails early, or catch drift in time to act. That gap hurt in three ways: **The Solution** — Plain-language forecasts, caps with a next step, operator-first alerts, docs that matched the API Forecasting answered "What will we likely spend this period?" in language finance teams use. Breakdowns followed how teams already group fleets and sites; weak signals were labelled clearly instead of presented as exact. Caps mirrored real ownership: warn before a hard stop, show "what next" when a threshold is crossed, and keep a simple log of who changed what. Anomalies stayed short and clear, with links to the slices teams already use to investigate. Developer docs used the same words as the UI (quota, threshold, alert), with quickstarts and copy-paste examples so integrations shipped with fewer round-trips. **The Impact** — Less rear-view billing, more steering while the period is open Teams shifted from "what happened last month" to what's coming, where caps apply, and what changed. Finance could plan earlier, ops could act before close, and programme owners could grow fleets with fewer invoice surprises. Clearer signals and shared vocabulary trimmed escalation noise and sped fixes, often before the billing period ended. Takeaways: - Forecast copy has to match how finance groups fleets and sites, not only engineering IDs. - Caps need a visible owner, threshold behaviour, and change log operators can audit. - Developer docs that reuse UI vocabulary ship integrations with fewer round-trips. --- ### Service requests made faster (Welsh Water) [View case study](https://www.gaganmalik.io/en/success-stories/welsh-water) **Trusted routing from the first report to the right crew.** When someone sees water on the pavement or the tap runs weak, Welsh Water needs **where** it is, **how serious** it is, and **what happens next**, without three hand-offs on hold. Dŵr Cymru Welsh Water serves millions across Wales and nearby regions as a not-for-profit: more money stays in pipes, treatment works, rivers, and bill support instead of dividends. When this programme ran, **self-serve** meant **guided digital journeys plus robotic process automation (RPA)** into back-office and work-management systems, not large language models. The design question was how to capture a clean, structured report so automation could move it, and field teams could respond with the right kit and priority. **The Opportunity** — Civic scale first, then one queue for bills and bursts Welsh Water already operated at **full civic scale**: storms, bursts on large mains, and heavy capital work were normal operating noise for a supplier serving **around three million people** across most of Wales and adjoining areas. Contact centres carried that load alongside everyday customer work. Most contact into a water company is still **billing and accounts**. That deserves a straight answer. **Leaks and supply hits** show up less often in the totals, but they do not feel rare when water is across the pavement or the shower drops to a trickle. Those two reasons were still landing in the **same phone queue**. Research on the phone-led path for service requests showed **about 20 minutes** average wait before a caller could finish during busy periods. Tolerable for a meter question; a poor match when water is leaving the pipe. The opportunity was to move **repeat, high-stakes reporting** (such as **reporting a leak**) onto **structured digital intake** that fed automation and dispatch without losing nuance. **The Solution** — One integrated design sprint: structured intake, then automation dispatch already trusted I ran a **design sprint** with product, operations, and content to agree what to build first: guided flows that walk someone through **reporting a leak** or another service request, capturing **location**, **severity**, **anything unsafe on site**, and **photos** when useful, with **plain-language** next steps on screen. Behind the scenes the target was **rules-based routing** and **RPA** into the systems dispatch already trusted, so the first payload matched how trunk repair, sewer inspection, and reinstatement were sequenced, not a generic CRM shape agents had to rewrite. We stopped at **MVPs** on purpose: enough to prototype and user-test, without treating one workshop as a production launch. **Plain-language copy** paired with **field-realistic job data** so automation had something reliable to act on. **The Impact** — Clearer tickets, fewer callbacks, emergencies exit the billing queue The aim was practical: **less ambiguity** when a request arrives, **fewer callbacks** to fill gaps, and **dispatch seeing what crews need on the first screen**. Agents kept doing what only people should do; automation took predictable steps that had been burning minutes and mis-keys. Satisfaction scores and capital programmes shift with regulation and weather. The durable bet was narrower: when intake is structured, people spend less time on hold for emergencies that should never have waited behind billing volume, and the organisation keeps **clear signal** through normal civic disruption: storms, bursts, and peak call periods alike. Takeaways: - When routine volume hides urgent operational reasons, give high-stakes reporting its own front door, not a longer queue. - For this programme era, smart self-serve meant reliable automation behind clear forms, not a clever paragraph generator. - Sprints earn their keep when MVPs map to how trunk, sewer, and reinstatement jobs actually run in the field. --- ### One workspace for team collaboration (Presto) [View case study](https://www.gaganmalik.io/en/success-stories/presto) **One governed workspace for boards, docs, and assistant runs.** Presto Platform (askpresto.com) combines workspaces, Kanban boards, rich-text Spaces, and an AI assistant with Ask, Plan, and Create, matching what ships today. Early builds felt like separate tools side by side. The job was one coherent place: a clear home, conversations tied to real work, and assistant output people could follow without losing context. **The Opportunity** — Boards, docs, and chat did not share the same objects Teams tracked work in one place, wrote knowledge in another, and opened generic chat when they needed help. Context did not carry across, so people repeated themselves and did not trust answers from AI that never saw the workspace. The product needed one governed place where boards, Spaces, and assistant threads all pointed at the same work. **The Solution** — One workspace for Kanban delivery, Spaces, reports, and the assistant In short: status lives on the board, drafts and reference live in Spaces, and the assistant sits on that same work, not a generic chat window off to the side. We designed end to end on a shared shadcn Maia system with role-based access. Workspaces and boards carry assignments, due dates, priorities, and lanes so status stays on the board instead of in spreadsheets. Spaces use Notion-style rich text for knowledge and drafts; Create mode and the draft drawer land AI output on real pages. The assistant uses Ask, Plan, and Create, with mentions, workflows, and models curated per workspace, plus reporting with day, week, and month views so managers could read movement over time. Home cards and the composer earned the first screen: weekly actions, integrations, and recent work visible at a glance. **The Impact** — Board, Spaces, and assistant finally agreed on what "this project" meant Teams stopped treating the board, knowledge base, and chat as three competing truths. Context rode with the work, so fewer reviews opened with a recap nobody had time for, and fewer assistant replies started with "I can't see that workspace." Managers could read movement in reporting instead of stitching a story from side channels and screenshots. Takeaways: - Board status, Spaces knowledge, and assistant threads should reference the same workspace objects. - Home cards and composer placement reduce hunt through menus for weekly actions. - Reporting views earn trust when they pull from the same assignments the board already tracks. --- ### Expert travel guides (Telegraph Travel) [View case study](https://www.gaganmalik.io/en/success-stories/the-telegraph) **Turn travel journalism into an app people open at the gate.** Travel already had heavyweight references: **Lonely Planet** defined premium guides for decades; **Google Trips** (later folded into Google's wider travel and maps surfaces) set expectations for itinerary-style, map-first planning at web scale. The **Telegraph Travel Guides** app was the bet to ship **Telegraph Travel** judgement in software: expert-led trips, offline-friendly reading, and map-led discovery for people who are tired, abroad, and deciding how to spend the next hour. The opportunity was to earn repeat opens without trading away the premium cues travellers already associate with the desk. **The Opportunity** — Earn shelf space beside Lonely Planet and Google-class trip tools Travellers do not lack lists; they lack **judgement they believe**. The competitive bar was never another generic travel app: people already compare you with **Lonely Planet** on authority and with **Google** on convenience. **Google Trips** became shorthand for Google-style trip planning before those patterns folded into wider Google travel and maps experiences. A guide from the travel desk only wins if it ships the depth readers associate with **Telegraph Travel**: shortlisted hotels, honest walk routes, food writing with a point of view. Then it has to present that depth on mobile without turning into a scraped aggregator. Public Telegraph Travel coverage of the Guides product has pointed to expert curation from the travel desk, itinerary-shaped trips, offline use, and maps: the behaviours that matter in transit. The question for the product was direct: how does respect for **Telegraph Travel** become a planning habit people return to on the phone, with a clear reason to open the app each trip? **The Solution** — Editor judgement in structured guides, not open-web listings The strategy was to **put Telegraph Travel judgement into the product**: structured picks, itineraries, and maps so the app reads as the travel desk in software, not a thin rebadge of generic listings. That is how you justify home-screen space next to Lonely Planet's brand and Google's infrastructure: different proof, same moment of decision. Execution sits between content design and trip-planning UX: reduce cognitive load when someone has thirty minutes in a new city, surface the next obvious step, and keep tone aligned with the Telegraph Travel voice travellers already trust. **The Impact** — An owned travel surface that competes on judgement, not aggregation The Guides line sits where editorial craft meets trip planning: Telegraph Travel's destination coverage shows how expert picks, itineraries, and offline-friendly reading translate into something travellers can pack for real journeys. The pattern is reputation converted into a repeatable planning ritual: the **Telegraph Travel Guides** experience competes for attention against brands travellers already know, with clarity at decision time instead of vague open-web aggregation. Takeaways: - Competing with Lonely Planet and Google-class trip tools takes editorial IP in the experience, not marketing claims on generic templates. - Travel punishes vague UX; the next obvious step on mobile matters more than feature sprawl. - When the brand promise is judgement, the product has to feel authored, not assembled. --- ### Loyalty for food lovers (Waitrose) [View case study](https://www.gaganmalik.io/en/success-stories/waitrose) **Make loyalty feel like the shop, not a bolt-on scheme.** Waitrose built loyalty around counter service, own-brand quality, food inspiration, and small treats that make a weekly shop feel personal. The challenge was to make My Waitrose work harder as a food lover's club: useful for value-conscious shoppers, distinctive for the premium brand, simple in the moments people already enjoy. **The Opportunity** — Report-backed scale first: membership growth, then the experience bet John Lewis Partnership's 2024/25 annual report says My Waitrose grew **7%** to **4.6 million active members** while more customers shopped with the Partnership's brands. Waitrose also grew sales to **£8.0 billion**, invested in lower prices, relaunched Waitrose No.1, refurbished stores, and expanded convenience and on-demand routes. Customers wanted value, but Waitrose could not win by becoming another points scheme. The stronger route was to turn loyalty into a clear membership experience: free coffee and treats, exclusive savings, more personalised offers, member-only events and promotions, and the feeling that Partners still knew food better than an algorithm. **The Solution** — Design loyalty around repeat rituals, food discovery, and transparent personalisation The story for My Waitrose is strongest when membership connects three loops. **Everyday reward:** keep the reasons to scan simple and visible: free tea or coffee, delicious treats, selected savings, and offers people can understand before they reach the till. **Food lover identity:** use the membership to make Waitrose feel like a club: recipe inspiration, counters, seasonal ranges, competitions, food magazine moments, and member-only events that make the shop about taste, not just price. **Personalised value:** make offers relevant without making the system feel opaque. The annual report points to personalised offers and improved My Waitrose benefits as part of the growth plan; the experience has to explain why a saving appears, when it expires, and how to use it online, in app, or in store. **The Impact** — A bigger active member base, stronger value story, and loyalty that still feels Waitrose The public results show the direction of travel. In 2024/25, My Waitrose reached **4.6 million active members**, up **7%**. Waitrose sales grew **4.4%** to **£8.0 billion**, revenue grew **4.7%** to **£7.5 billion**, volumes rose **2.6%**, and adjusted operating profit increased by **£122 million** to **£227 million**. Waitrose also reported a fourth consecutive The Grocer customer service award, **£150 million** invested in New Lower Prices since 2023, and on-demand grocery sales up **110%**. Loyalty does not carry all of that alone, and it should not pretend to. Its job is to make the broader proposition easier to feel: good food, helpful Partners, relevant value, and a reason to come back before the next voucher expires. Takeaways: - The best grocery loyalty feels like a better shop, not a separate scheme customers have to decode. - Personalisation earns trust when the benefit, expiry, and next step are obvious at the shelf, in the app, and at the till. - For a premium food brand, value and inspiration have to travel together: savings bring people in, food love keeps the relationship alive. --- ### Better team collaboration (Eutelsat OneWeb) [View case study](https://www.gaganmalik.io/en/success-stories/eutelsat-oneweb) **Reviewers and builders seeing the same truth, not conflicting attachments.** When programmes speed up, the risk is not fewer documents but more versions in flight. The teams behind Eutelsat OneWeb needed collaboration that matched how satellite work actually happens: hand-offs people could follow, review gates that did not stall because nobody knew which pack was current, and status that did not live in five inboxes. I designed workflow automation so engineers and reviewers could route, approve, and ship documentation together without losing traceability. **The Opportunity** — Strong engineering slowed by version drift and unclear ownership Satellite programmes pull together spacecraft, ground sites, suppliers, and regulators. When iteration speeds up, parallel changes multiply. The painful pattern was familiar: two disciplines referencing different revisions, signatures waiting on the wrong pack, and programme leads pulling status from mail instead of reading one clear picture. The answer was not another generic file share. People needed a simple story they could trust: where to start, who owns the next step, and what state the pack was in before the next gate. **The Solution** — Templates, routing, and live status beside the repositories teams already used We shaped automation around real programme rhythms: structured starting points so new specs and change packs did not begin from blank folders, routing that respected roles and boundaries, and review checkpoints only where policy asked for them. Notifications stayed short and pointed to the live artefact. Where product lifecycle management systems or document stores stayed the system of record, the workflow kept metadata and hand-offs aligned so search and audit stayed coherent. We proved each flow with a pilot programme first, then widened stream by stream so specialists were not forced through a big-bang tool swap during a launch window. **The Impact** — Less energy on reconciliation, more on engineering judgement Teams spent less time debating which file counted and more time on the technical decision itself. Review boards saw complete packs more often, which meant fewer round trips when integration windows were tight. Programme leads could scan document state at a glance instead of chasing answers across threads. The lasting shift was cultural: paperwork treated as part of the mission rhythm, not an admin sideshow after the real work was done. Takeaways: - Collaboration breaks down when ownership and version truth are fuzzy; make both visible early. - Automation sticks when it sits next to existing repositories instead of inventing a new source of truth overnight. - Pilot with one programme stream, then scale when reviewers believe the audit trail. ---