---
title: "How to Calculate What a Task Is Worth Before Work Starts"
metaTitle: "Calculate What a Task Is Worth Before You Start"
description: "Simple arithmetic that shows the maximum possible return on any feature, campaign, or project - before the team spends weeks on it."
date: 2026-09-28
tags: [metrics, project-design, ai-implementation]
cover: cover.webp
coverAlt: "Every card on a coffee shop's planning board is checked off, while a pink-haired young woman times how long a customer takes at the new order kiosk"
---

Before a task starts, run it through four numbers: how many people will see the change, what fraction will respond, what fraction of those will pay, and what the average purchase is worth. Multiply those together and you have the ceiling - the best-case return. Compare that ceiling to the real cost of doing the work, including revisions and fixes, then make one of three calls: gather the missing numbers, ship a small version and measure, or just say no.

Sounds like extra friction. It saves weeks of team time on work that would otherwise ship without a measurable result.

## The difference between "shipped it" and "something changed"

People at work routinely conflate three separate things.

First: the process - what the team is doing right now. Second: the finished artifact - the release, the document, the presentation, the email. Third: the business change - customers buying more often, employees no longer spending hours on manual data entry. The standard terms are activities, output, and outcome.

A bank makes the gap visible.

One large bank was growing its key numbers with minimal engineering: teams were fixing friction in client registration, and metrics climbed. Then a consulting firm published a report ranking the bank fourth among peers by number of features in its app. The bank declared a three-month push. Eight product teams shipped 74 features in those three months.

There is no way to test 74 new things properly in 90 days. The features were buried in a help section and an operator chat so that clients would not stumble onto them by accident.

Three months later the next report came out. Still fourth.

74 features is output. Nothing moved in the ranking, and almost no client ever saw the new work because it was hidden. What had actually moved the metrics earlier were small registration fixes requiring almost no engineering at all.

Other banks were reading the same reports, and their leadership decided they were falling behind too.

Retail shows a similar pattern. One large online clothing retailer ran nine conversion-improvement projects over 18 months - "conversion" meaning the share of visitors who actually buy. Conversion fell. Something was fixed, but more was broken: SMS stopped arriving, registration got harder, new errors appeared.

Work is more honestly measured by what changed for a customer or an employee. The number of releases says nothing about that. Tasks still need to get done - just with a clear idea of which number should move.

## Why tasks get started without a calculation

Being accountable for a presentation is easier than being accountable for an outcome. Any document can be produced and filed in a folder where it changes nothing. Getting something to actually change is an order of magnitude harder. A system, all else equal, takes the path of least effort.

If a company pays for on-time delivery, people will deliver on time. If a process assigns accountability for tasks and releases but not for revenue and metrics, the process will reliably produce tasks and releases.

Almost any goal can be worded so it is guaranteed to be met - without any dishonesty, just a convenient formulation. The classic: "we want to improve." What specifically should grow goes unsaid. Any project clears that bar.

A metric is a number backed by the behavior of real people - customers or employees. You cannot move a metric without changing someone's behavior. A business has a short list of rational goals: grow revenue and profit, bring in new customers, cut costs, reduce churn. How any given task connects to those goals is often not obvious.

Every task someone dreams up is a hypothesis - an assumption that it will work. In daily life we are used to assumptions coming true: you go to the store for milk and it is on the shelf because many people worked to put it there. No one has done that work for your task. A task succeeds when people use its result and benefit from it. A finished artifact does not guarantee that yet.

In meetings, people arrive with fragments of information and spend five to 45 minutes generating ideas that land in the roadmap without any validation. The inefficiency is almost never converted into dollars, even though everyone notices when work is slow. The math is simple: you need to know what one hour of an employee's time costs, including taxes.

## How to calculate the ceiling

![In an empty, unfinished store, a pink-haired young woman stands at the window with a tally counter, counting passers-by](/blog/task-value-before-work/fig-reach.webp "How many customers could show up is visible before opening day: start by counting everyone who walks past")

The ceiling fits in one line.

**Ceiling = reach × response rate × conversion rate × average order value**

Reach is how many people will actually see the change - open the email, arrive at the screen with the new feature. Response rate is the share of those who take a first step: click the link, tap the button, try the thing. Conversion rate is the share of those responders who pay. Average order value is what one buyer spends on average.

Use the most generous plausible values for every rate. This is a ceiling, not a forecast. If even the ceiling sits below the cost of the work, skip the task in its current form.

A teaching example with made-up numbers.

| Step | Assumption | Result |
|---|---|---|
| Base | 3,000 contacts | 3,000 people |
| Reach | 30% open the email | 900 people |
| Response | 3% of openers click | 27 people |
| Conversion | 1% of clickers buy | 0.27 purchases |
| Average order | $100 | ceiling: $27 |

Less than one purchase.

Cost of the work (also made up): an employee costs the company $2,400 per month including taxes; a month has roughly 160 working hours, so one hour costs $15. Two working days of a marketer's time - 16 hours at $15 - comes to $240.

A $27 ceiling against $240 in costs. This campaign, as described, is not worth running. The calculation says nothing about email campaigns in general - it is about this list and these rates, and here the work would most likely be wasted.

Now take the same made-up rates with a different list: 30,000 contacts and an average order of $400. Nine thousand open, 270 click, 2.7 purchases, ceiling $1,080. That is 4.5 times the $240 cost, which makes it worth shipping a small version - send to a slice of the list and see the real rates.

One thing to watch with reach: count only the people who actually get to the place where the change lives. A chatbot-builder service mapped user paths through its analytics - the tool that records user actions on a site or in an app. The screen for one add-on feature had been seen at least once by 55% of users. The screen for setting variables (data the bot remembers about a conversation partner, like their name) had been opened at least once by 2.7%, even though building an automated bot is impossible without that screen.

If three people out of a hundred reach your screen, the ceiling is calculated from those three.

## What rework actually costs

![At a residential complex gate, a guard checks a parcel's address against a list while a pink-haired courier waits by a scooter full of parcels](/blog/task-value-before-work/fig-redelivery.webp "A parcel with an imprecise address travels twice, and the second trip rarely shows up in anyone's cost column")

Rework is work that one person created for another. Every "redo this, that's not right" message in a work chat means something went off track.

A familiar complaint: "Requirements keep changing - we start a task on Monday and by Wednesday it needs to be redone."

The cost of rework uses the same arithmetic.

**Cost of rework = hourly rate × hours lost**

Hours lost means time spent on tasks that came back for changes, shifted direction mid-flight, or were never accepted. Another teaching example, numbers still made up.

A team of 10 people. Each loses 4 hours a week to rework - one tenth of a 40-hour week. Ten times four is 40 hours per week. That is one person's full working week. Forty hours at $15 (same made-up rate) comes to $600 per week, $2,400 per month - exactly one additional salary.

The formula only counts paid hours. It does not see launch delays, which means it gives a lower bound, not an upper one.

How much waiting between work steps costs, and how to see it, is covered in the article on the [cumulative flow diagram](/blog/cumulative-flow-diagram/).

Lost hours rarely get tracked, but they are not hard to find. A task tracker shows how many tickets moved back from "done" to "in progress" and how much time they consumed. Work chats hold the messages that say "redo," "that's not it," "requirements changed" - they can simply be counted. If no tracking exists, one week of observation is enough: log every return and how long it took.

## Three decisions after the calculation

The most expensive or most contested task deserves a pre-work breakdown. The calculation leads to one of three choices.

First: gather the missing numbers. If the formula contains a factor you do not know - how many people reach the relevant screen, what fraction opens your emails, how many hours go to rework - finding out is cheaper than doing the task blind. Past campaign statistics, basic analytics events, or one week of observation give enough to fill the formula with real numbers.

Second: ship a small version and measure. This makes sense when the ceiling is clearly above costs but the rates in the formula are still guesses. A small version is a slice of the list, one screen, one team. The key condition: name the number that must move before you start, and check whether things got better or worse. New errors or rising support tickets mean something went wrong.

Third: say no, if even the generous ceiling sits below the cost of the work. Weeks of team time freed up is also a result.

From a long list of ideas, two or three can realistically move forward; the rest get dropped. Sometimes the most useful thing is simply giving yourself permission not to do something. And if you cannot name the number that should change, the task is probably not ready to start.

In AI implementation, a small version is a pilot on one process. How to choose that process and check readiness for launch is covered in [the article on five AI implementation mistakes](/blog/ai-implementation-process/).

## Checklist: what to find out before picking up a task

Eight questions worth asking before work begins.

1. What should change, and in which number? "We want to improve" is not an answer.
2. Whose behavior needs to shift - customers' or employees'?
3. How many people will actually see the change?
4. What fraction will respond, what fraction will pay, and what is the average order value?
5. What is the ceiling in dollars at the most generous plausible rates?
6. How many hours will the task take, including fixes and revisions - and what does an hour cost?
7. What number will tell you things got better rather than worse?
8. Which of the three decisions are you making?

What you know about a task at the start is always less than what you will know two or three weeks in. A large quarterly project built on a brief written at the beginning carries more risk than short steps with course corrections - precisely because the requirements at the start are incomplete.

## What changes when an AI agent does the work

An AI agent is a program you assign a task to in plain language, and it works through the necessary steps on its own. Agents produce a first version, a prototype, quickly. Getting that work to the point where everything runs reliably and creates no new problems is a big job.

With agents, it is very easy to move fast in the wrong direction. They leave behind files and decisions that will need to be redone later. One manager got a single word wrong in a task brief for an agent, and the agent spent two hours doing the wrong thing. Those two hours were gone.

The same output/outcome swap appears in AI implementation reports. "Agent launched" is output. "Employees stopped transferring data by hand" is outcome. More on that distinction in [the piece on how AI use differs from AI impact on business](/blog/ai-adoption-myth/).

An AI implementation is a product like any other. It has first use, habit formation, retention, and economics: agents cost money and must return money. To implement AI, you have to change the behavior of people inside the company.

Learn to deliver value first, then automate it. If there is no value, there is nothing to automate.

At Majento, an implementation project starts with one process and one question: what change needs to be measured. Sometimes an assessment reveals that the problem is more cheaply solved with a rule, a template, or a standard integration with no AI at all - and stopping there is the right call. How [Majento approaches AI implementation](/ai-implementation/) is described on the service page.

## Questions and answers

### What do "output" and "outcome" mean in plain terms?

Output is what you made: a release, a document, an email, a presentation. Outcome is what changed in a customer's life or in how the company works because of it. A presentation is output. "Customers bought more often after seeing the new screen" is outcome. Work is more honestly measured by outcome because output can be produced indefinitely with no effect at all.

### What if I don't have the numbers to fill the formula?

That is the first of the three decisions: gather those numbers. It is cheaper than doing the task blind. Past campaign statistics, basic analytics events, or one week of watching the team work give enough to replace the guesses with real figures.

### How do I price a task that doesn't directly generate revenue?

Through hours and the cost of an hour. Count how many times per month the operation happens and how many minutes the task would save on each one, convert to hours, and multiply by the employee's hourly rate. Hourly rate: total monthly cost of the person including taxes, divided by working hours in the month. That number is the money the task frees up.

### Will this calculation screen out good ideas?

It screens out ideas with a low ceiling - ones that won't pay off even at the most generous assumptions. If the ceiling is clearly above costs, the idea is not screened out: the decision becomes "ship a small version and check the real rates." That way the team spends time on tasks with real upside, and guesses get replaced by data.

If you want to run the numbers on a specific task or process before committing weeks of team time, message us on [Telegram](https://t.me/shimaoz) or email [hello@majento.ai](mailto:hello@majento.ai).