The owner of an online coffee store in Almaty wants a customer account with a "Repeat order" button. Right now some regular customers reorder through WhatsApp: Zhuldyz, the manager, finds the previous order, confirms the grind and address and sends the amount due. The owner thinks a button would take that work off Zhuldyz's hands and add sales. The developer asks for a spec. And you, the marketer, do not know the main thing, why people message Zhuldyz at all: ordering on the site is hard for them, or they want to ask about different beans.
It is the same store as in the retention architecture lesson: an order is 15,000 ₸, and 6,000 ₸ is left after goods and delivery. The store and pilot figures in this lesson are made up. Whether the account is worth building depends on how much of the conversation you can remove while the customer still gets what they wrote in for.
What a growth team does
Growth hacking is looking for growth through tests where marketing, product and analytics meet. The marketer knows where a customer came from and what the ad promised them. The product team owns checkout, and the analyst links people's actions to payments. And if customers ask how the coffee tastes, bring in someone who knows the beans: without them you cannot tell what exactly people are asking.
Every test ends in a decision. For the account there are three: build it, rework the idea, or drop it. The number of tests launched only shows how busy the team is. Its value shows in the decisions it made and what they rested on.
Test before developing the account area
Chats and interviews
Why buyers message before a repeat order
Mockup
Can buyers find their previous order
Decision
Build, rework the idea or drop it
Break the idea into assumptions
"One-click reordering" is several questions at once. Has the customer run out of coffee? Do they want the same beans? Were they happy with the last order and its delivery? What stops them ordering right now? Each answer leads to different work.
If someone wants to try a new flavour, an account that copies the last order solves only part of the problem. If the coffee arrived late last time, sort out delivery first. But if the beans and address are the same and Zhuldyz is just copying them from one record to another, a button would take exactly that work away. The repeat-order count alone cannot tell these cases apart.
So start by pulling up the repeat-order chats and noting what customers asked about. Then talk to a few people about their last purchase: when they decided to order, where they found the store, why they wrote on WhatsApp, what they needed to check. "Would you like a convenient account?" collects approval for the idea. A story about the last order shows which actions the account would have to replace.
Test first the assumptions that would make the whole build useless if they were wrong. Before arguing about the button colour, find out whether customers need to repeat the same order and can place it without talking to a manager.
Match the test to the question
| Team's question | What to do | How to use the result |
|---|---|---|
| Why do customers message the store before their second order? | Review the chats and ask about recent purchases | Choose which part of ordering to simplify |
| Will they find their previous order in the account? | Give them a task on a mockup and watch how they manage without hints | Fix navigation before development |
| Can the store fulfil a simplified order? | Run a small manual pilot, logging the manager's time and errors | Decide which operations to automate |
| Does the new checkout add paid orders? | Plan a comparison with the usual checkout | Estimate the effect on purchases and costs |
A mockup works for navigation: people show where they would click and what they understood. You cannot test payment on a mockup; that needs a working path through payment. A manual pilot shows what customers ask for and how much time it takes, but part of the result may rest on Zhuldyz's attention. A button will not have that attention, so allow for the possibility that some orders depended on the conversation, and check it with a comparison.
If payment breaks and the error can be reproduced, a growth test may be unnecessary. You fix the error and accept the work against the payment scenario. The comparison and decision rules are set in advance when you change the offer or the customer's path to get more purchases.
A manual repeat-order pilot
In the pilot, Zhuldyz writes to 40 suitable customers who have agreed to receive messages and offers to help with a repeat order. She shows what was in the previous order, asks what to change and places the order the usual way. Eight people pay. The whole pilot, including the chats with everyone else, took four hours.
8 / 40 = 20% of those invited placed an order. That is a good figure for describing the pilot. But it cannot tell you how many orders the help itself added: for that you need to know how many similar customers would have ordered without it. Some of the eight may well have been planning to write that day anyway.
For each conversation, Zhuldyz records what was needed: repeat everything, change the grind, choose other beans, check delivery. Keep the people who did not reply on the list of invitees. Count only those who joined the conversation and the report shows the most interested customers, while the time spent on everyone else drops out of the calculation.
After the pilot, decide what to carry into the product. If people keep changing beans, offering a choice before confirmation beats copying the last order word for word. If address checks take most of the time, the developer's task is a different one altogether. The spec gets these observations, not a promise that "the account will add 20%".
What the manager's help costs
Eight orders brought in 8 × 15,000 = 120,000 ₸ in revenue. After goods and delivery, 8 × 6,000 = 48,000 ₸ remained. Let's value an hour of Zhuldyz's time at 5,000 ₸, an internal estimate for the calculation: four hours cost 20,000 ₸. What remains is 28,000 ₸.
The hourly estimate is there so that manual work shows up in the calculation at all. Even if Zhuldyz is on a fixed salary, those four hours went on the pilot, and other tasks waited. If hiring or overtime comes up later, you will need the real cost of her time.
The 28,000 ₸ is eight orders after all the listed costs. We do not know how much contribution the pilot itself added. If all eight orders would have happened anyway, the help brought only 20,000 ₸ of extra cost. If it did add some orders, their contribution is weighed against that sum and against future development costs.
That gives the next test its question: will the extra orders pay for the manager's work? At 6,000 ₸ contribution per order, four extra orders would cover 20,000 ₸ of manual work: 24,000 - 20,000 = 4,000 ₸. This is the threshold for our pilot. A real plan would add refunds, support and the cost of the change itself.
Move from a pilot to an effect estimate
To measure the effect on purchases, take one audience and one change. Split eligible customers into groups before anyone sees the offer, do not change assignments along the way, and count the result across everyone assigned. The plan records the primary metric, schedule, group sizes and the reasons to stop the test if it harms customers or the data breaks. HADI is a handy format for the full card.
A reminder and a simpler checkout are different changes. The reminder test asks whether a message helps someone come back at the right time. The account would test something else: whether it is easier to place an order the customer has already chosen. The results inform each other, but if the reminder did not work or the outcome is unclear, the checkout question stays open.
A weekly review of the work is handy: what you learned, where the data broke, which decision is waiting. But the end date of the measurement comes from the test plan. The store counts a second order within 60 days, and no number of weekly meetings will shorten that window. Brian Balfour writes about how process, team and tactics fit together.
Exercise: a decision before development
Take one idea for your own product or store. Write down the decision the team is waiting for, three assumptions and a test for the most expensive one to get wrong. Add what you will do with each outcome and which costs you will count. For the account, the result could be a mockup and a list of the actions it should replace.
Now a calculation. Suppose a completed test with groups showed that Zhuldyz's help adds three orders for the same amount of work. Does the 28,000 ₸ left from the pilot justify the manual service?
Three added orders bring 3 × 6,000 = 18,000 ₸ of contribution. Four hours of work cost 20,000 ₸, so at this estimate the service is 2,000 ₸ in the red, and that is before any development. The 28,000 ₸ was counted over all eight orders, including those that would have happened without help, so it cannot carry this decision. The team has three options: make the help cheaper, find a change that does more, or drop the service in this form. And three orders is an estimate with its own error, so how precise it is affects how confidently the team can choose.
Video: an introduction to the approach
A talk by Alexander Onikienko. Once you pick a tactic from the video, write down which assumption about your customers it has to test.