AI sent the report. Who is going to act on it?
You can automate a report. Responsibility for the next decision is harder to schedule.
ORIGINAL EPISODE: 101. Bygga e-handel i turbulenta tider: AI, forecasting och systemstödet som krävs · · Audio in Swedish
Jacob describes a weekly report that arrives automatically in Slack on Monday morning. I still want a growth manager to reply in the thread with their own interpretation and what the team should do. In episode 101, we discuss where AI can help with forecasting and analysis, and where someone needs to pause, check the evidence and make a decision.
When conditions change, the plan needs room to change too.
I can be optimistic when thinking about next year. Find the right ads, launch the right product and get execution working, and there is plenty to do. I say that in the episode too. But optimism needs to meet reality more often than at next year’s budget meeting.
We discuss revisiting the forecast regularly. Did what we expected actually happen? Are the same conditions still in place? What needs changing? The purpose is to get useful evidence for the next decision, rather than defend a number we once entered.
Inventory is part of that work. If an important product is supposed to sell, it needs to be available to buy. That sounds obvious. Yet discussing ad budget in isolation from the products those ads are meant to sell quickly becomes absurd.
Listen at this point · 14:33Demand a useful model. Understand its weaknesses.
Jacob describes connecting data and using AI to support forecasting. The solution he discusses is still under development at the time of the conversation. The interesting part is the problem he wants to solve: how can a system say whether things are going well if it does not understand what the company is trying to achieve?
We also discuss the limits. More data and a longer history provide a different basis from what a small company has. A new product makes comparison harder. Assumptions are necessary, and they need to be visible and open to discussion. A well-written conclusion from a system does not strengthen the underlying evidence.
Jacob argues that a model can be useful even if it never gets the result exactly right. I think that is an important starting point. What does it help us judge better? Where does the uncertainty become too great? Those questions need to accompany our use of the result.
Listen at this point · 17:10A sales dip does not explain its own cause.
We take a simple example: a product sold out in October. Sales fell. If next year’s plan simply follows that curve, we risk treating lack of stock as lack of demand. Those are quite different problems to solve.
The same goes for campaigns. What did the company do in the period we are comparing against? Which offers and emails were running? Jacob describes how past emails and discount data can reconstruct some of that context. Someone who knows the business then needs to review the picture.
If a product sold out, that needs to show when we build the next forecast. Otherwise the model may plan for low demand when what we need is a larger purchase. Campaigns and product launches need the same check.
Listen at this point · 23:00The Monday report needs a reply from someone who thinks.
Jacob describes an automated weekly report in Slack. It arrives early on Monday and gives the team a shared basis for discussion. That is a concrete example of work that can be simplified. Fewer manual steps can free time for analysis.
The risk is that everyone reads it, thinks it looks reasonable and moves on. The compilation is complete. Nobody has done the interpretation. That part needs time and an accountable person.
In the episode, I say a growth manager should still write their own summary in the thread, with actions based on the week. What does what we see mean? What do we prioritise now? That makes the report the beginning of a piece of work. Someone still needs to stand behind the interpretation and take it forward.
Listen at this point · 34:29Test the path from the ad all the way to purchase.
I describe a checkout bug at Såpa that was difficult to reproduce. Visiting the site and trying a purchase was not enough. The problem involved a particular combination of arriving from a Facebook ad, using iOS and choosing a payment method.
It is a useful reminder of how easily we simplify our own testing. We know the site, find our way immediately and use our usual device. The customer arrives from a different context and may have a different experience. A successful test of our path does not prove that the customer’s path works.
Overall figures can also be hard to interpret when campaigns, seasons and other improvements change at the same time. We describe how that complicated troubleshooting. The practical lesson is to take customer signals seriously and reproduce the circumstances, rather than settle for it working for us.
Listen at this point · 44:16Customer service knows what the next ad and product page need to explain.
Later in this part of the conversation, we discuss AI in customer service. Jacob describes a tool he is evaluating. One idea is particularly interesting: collect the most common questions about each product and use them to improve product pages and ads.
When many people ask the same thing, there is something to investigate. Is the information hard to find? Do we need to demonstrate how the product works? Has the ad left a question unanswered? A support reply can help one customer. Better content can help more people move forward on their own.
Ask customer service to collect recurring questions by product. Then choose what to answer on the page, in the instructions or in the next ad. There is a specific task to start with when a new system needs to prove useful.
Listen at this point · 53:00This article is based on the conversation and adapted for reading.