What does the tool cost when someone has to use it?

What should someone be able to do better?

I ask what a service simplifies, how much time it saves and what people should do with the time instead. That is where I want to start a discussion about another tool.

A lower price can be interesting. A new feature can too. But if nobody can describe which work should improve, it becomes hard to judge whether the purchase solved anything. You can get a prettier view of the same situation and remain equally unsure about the next step.

Make the assignment understandable before comparing options. Is recurring manual work taking too long? Is information missing when someone needs to decide? Does the customer need to do something that currently requires help? Different problems produce different requirements.

Count the work on both sides of the invoice.

Fredrik raises the relationship between a service’s price and the cost of developing and maintaining something yourself. I also raise integration time. Together, those questions make the comparison more useful than placing two monthly prices side by side.

There is a cost to starting with a tool and a cost to continuing to benefit from it. Someone needs to understand how it works, keep the inputs in order and notice when the result is wrong or no longer relevant.

Compare a ready-made service and an internal build on the same task. Include time to connect systems, check results and maintain the solution. A low monthly price says little about the total workload.

A small internal question can justify a tool of its own.

I describe a colleague who built an internal tool to track content produced by employees. It started with a specific question: how is that material performing, and how can the team receive feedback?

I am glad technology makes those experiments possible. An internal tool still needs judging by what it helps people understand. If the team uses a ranking, people looking at it need to know its parameters and purpose.

The parts need to work from the same reality.

Fredrik raises the problem of data scattered across different services. We also discuss connections between systems. Behind the technical talk sits a practical question: can we bring together the information the work requires?

In discussing delivery, I explain how information about picking, collection and transport affects what we can tell the customer. Several stages need to produce one credible message. A good-looking box on a product page helps little if it is disconnected from what happens afterwards.

I want the need to guide how we look at the system. What needs to be available, what needs to be accurate, and who notices if it stops being right? Starting with the task or customer situation makes those questions easier to ask.

Ask the same question about what you buy in marketing.

Later in the episode, we discuss influencer marketing and creators. I describe how we have reconsidered the channel’s place in our own work. This reflects our reasoning in the conversation, rather than a final verdict on every partnership.

We distinguish buying access to someone’s followers from obtaining content to use in advertising. Those are different things to assess. If we are unclear about what we want from the collaboration, we can easily talk past each other when evaluating the result.

As with a system purchase, I want to understand the assignment and cost. Which part of the work does the collaboration help? How will the material be used? What have we learnt that affects the next choice? That is more concrete than whether a channel feels fashionable or outdated.

What looks simple to the customer may require several stages to work.

When discussing returns flows, we encounter a specific technical problem. The customer does something on the site, but the order may already have been passed to an external warehouse and be about to be picked. A request in the interface therefore has to connect with a real process behind it.

It illustrates why a visible button does not mean the task is solved. Someone needs to understand what happens when it is used and what information comes back to the customer. Otherwise the simple surface can conceal another customer-service case.

Before adding the button, follow a real order through the warehouse flow. When can it be changed, what can you tell the customer, and who handles what cannot be automated? Those questions need resolving before the feature can be trusted.