The main workflow, step by step
The window follows a returning customer from a notification to a delivered order, and the retailer's team behind it. Choose a step to see its screen. The retailer, the customer and the products shown are invented for the demonstration.
Back in stock
Trail runner, size 42Available- Opened from
- Alert the customer asked for
- Lands on
- The product, size preselected
- Signed in
- Yes, from the last visit
- Stock
- Read live from the store
Off the pathIf the item has sold out again by the time the customer opens the alert, the page says so and offers to keep the alert.
Checkout
ORD-77410Paid| Step | Detail |
|---|---|
| Address | Saved, confirmed with a tap |
| Payment | Phone wallet, by fingerprint |
| Loyalty | Points added |
| Basket | Same as on the website |
Off the pathA declined payment keeps the basket and offers another saved method, without returning the customer to the start.
My orders
ORD-77410Out for delivery| Feature | State |
|---|---|
| Tracking | Live from the carrier |
| Updates | Notifications, as chosen |
| Buy again | One tap, previous sizes |
| Returns | Started in the app |
Off the pathAn item that cannot be returned under your policy shows the reason instead of a return button.
App content
Home screenPublished- Banner
- Autumn collection, scheduled
- Featured
- Three collections, reordered
- Offer
- For loyalty members only
- Release needed
- No
Off the pathContent scheduled for a date goes live without a store submission, since only the app's code needs review.
App results
This monthOld version in use| Measure | State |
|---|---|
| Orders from the app | Shown beside web orders |
| Repeat purchase | Tracked per channel |
| App version | Some users on an old one |
Off the pathUsers on a version that no longer works with the store are asked to update before they can check out.
Who uses it, and what each role can do
An app adds a channel, not a second shop. The roles are the same people who run the store, with tools to manage what the app shows.
| Role | Sees | Can do |
|---|---|---|
| Customer | Catalogue, basket, orders, loyalty and preferences | Shop, pay, track, return and set notifications |
| Marketing manager | Home screen, collections and campaigns | Publish content and send messages to consented customers |
| Customer service agent | A customer's orders and app activity | Help with orders, returns and account access |
| Ecommerce manager | Sales by channel, app versions and errors | Decide priorities and approve releases |
When the work leaves the usual path
The app depends on the store, the payment provider and the customer's phone. These are the points where one of them falls short.
| Situation | What the system does | Who decides |
|---|---|---|
| Store interface slow or unavailable | Shows cached catalogue and pauses checkout clearly | Ecommerce manager |
| Item sells out before checkout | Removes it from the basket and says why | Customer |
| Payment declined | Keeps the basket and offers another method | Customer |
| Notifications refused | Works fully without them, with email as fallback | Marketing manager |
| Old app version no longer compatible | Requires an update before checkout | Ecommerce manager |
| Customer asks to delete their account | Starts deletion, keeping records the law requires | Customer service agent |
What it connects to
Almost everything in the app comes from systems you already operate. What the app can do is set by what those systems expose.
| System | What moves | Direction |
|---|---|---|
| Ecommerce platform | Catalogue, prices, stock, basket, customers, orders | Both ways |
| Payment provider and wallets | Card and wallet payments | Both ways |
| Loyalty or CRM | Points, tiers and customer preferences | Both ways |
| Notification service | Messages, with consent and categories | Out of the app |
| Carrier tracking | Delivery status per order | Into the app |
What a first release includes
Shared store data
Catalogue, prices, stock, basket and accounts read from your store through its interfaces, with no copies.
Fast checkout
Saved addresses and cards, phone wallets and biometric confirmation, tested with real payments.
Reorder and lists
Buy again, favourites and saved lists placed one tap from the home screen.
Chosen notifications
Order updates, back-in-stock and offers by category, each only with the customer's agreement.
Editable home screen
Banners, collections and offers managed by marketing and scheduled without a release.
Store listings and release
Listings, privacy declarations, submission to both stores and a plan for regular updates.
Often added after the first release
- Barcode scanning in shops
- A loyalty card for use at the till
- Visual search from a photograph
- Viewing products in the customer's room
- Stories and video content
What we need from you
- The ecommerce platform and plan you are on, and its interfaces
- Your share of orders from returning customers
- Payment methods and loyalty rules in use
- Brand guidelines and the design of your current website
- An ecommerce manager and a marketer to test on their own phones
Ownership and licensing terms are defined in the project agreement.
What to do next
Tell us which platform your store runs on and what your regular customers buy. We reply with what the platform's interfaces allow, a first release and a proposal. Start a conversation or book a 30-minute call.
Common questions
Do we need an app if our website already works on phones?
Only if enough of your customers come back often. First-time buyers arrive through search and adverts and land on the website, which should be fast in any case. An app pays for itself with regular customers, through staying signed in, quick reordering and notifications they value. Start by measuring your share of repeat orders.
Will the app work with our current store platform?
In most cases, yes. The common platforms offer interfaces for catalogue, basket, customers and orders, with differences by plan. We confirm what yours provides before design, because it defines what the app can do. Where the platform's own checkout must be used, the app hands over to it at payment and returns afterwards.
Should we build for iPhone and Android together?
If your customers are split between them, launching on both avoids leaving a large group out, and cross-platform frameworks make that practical with one codebase. Your website analytics show the split. Where one platform dominates strongly, starting there and following with the other is a reasonable way to learn first.
How do we get customers to install it?
Offer it at moments when it clearly helps: after a second order, in order emails, on packaging. Give a concrete reason, such as faster reordering or delivery updates. Showing an install banner to every first-time visitor mostly irritates. Measure installs by source and whether those customers go on to order in the app.