To turn analytics results into an action plan, every finding has to be carried through to six fields: fact, cause, action, expected effect, owner and deadline. The items are then ranked by their effect on money and by how hard they are to implement, the top ones go into the queue, and the result is checked against a measure chosen in advance. Everything else stays a document that was read once and filed away.
Key takeaways
A report describes and a plan prescribes — that, rather than length, is the difference. A report leaves the reader asking “so what now”, a plan leaves them with a task in progress.
| Feature | Report | Action plan |
|---|---|---|
| What it contains | Charts, tables, statements: sales are down, conversion has dropped | A list of changes, each tied to a specific finding |
| Owner | Not named, or “the sales team” | One person per item |
| Deadline | None | A date by which the change has to be working |
| Success criterion | None | A measure and the direction it should move in |
| Priority | All items carry equal weight | Ordered by effect on money and by difficulty |
| What happens to it | It is read and saved | It is run as a task queue and closed out |
A plan holds data too, but the data supports the decisions instead of replacing them. Where the findings come from is a separate job: our article on the business audit covers how they are collected across sales and operations.
A working recommendation has six parts, and losing any one of them turns it back into an observation. The first four answer what to change and why, the last two answer who and when.
Example “We need to improve how we work with the customer base” is a wish: nobody knows what to do or who does it. “After a first purchase the customer receives no contact at all (fact, from the quarterly export); there is no repeat contact scenario (cause); build a two-step sequence in the CRM (action); raise the share of returning customers (effect); owner is the head of sales; by 1 November (deadline)” is a recommendation.
We use the same format in other write-ups, for instance in the article on the AI visibility report. One format across the company saves time: every report reads the same way and needs no retelling.
Priorities are set along two axes: effect on money and difficulty of implementation. That gives four groups, and each of them needs a decision — including the fourth, otherwise small easy changes hang in the list forever.
| Effect and difficulty | What to call it | What to do with it |
|---|---|---|
| Strong effect, easy to implement | Quick wins | Take them first: they bring money and build trust in the change process itself |
| Strong effect, hard to implement | Systemic projects | Plan them separately: stages, budget, owner, intermediate results |
| Weak effect, easy to implement | Small stuff | Do them in a batch when capacity frees up, and keep them out of the main queue |
| Weak effect, hard to implement | Candidates for rejection | Reject them in writing, naming the condition under which you would revisit |
Effect on money is estimated in money, not in the word “high”. The arithmetic matches the one used for losses in an audit: how often the event happens in a period multiplied by the average amount. The acquisition cost and margin formulas this needs are covered in our article on unit economics in plain terms.
Two axes stop being enough once the queue runs past a dozen items competing for the same people. At that point a numeric score helps — RICE, for example, described by Sean McBride of Intercom: the score is reach multiplied by impact and by confidence, divided by effort.
| Factor | What it means | How it is scored |
|---|---|---|
| Reach | How many people the change will affect in a defined period | The number of customers, leads or employees in that period |
| Impact | How much the change affects each of them | A scale from 3 for massive down to 0.25 for minimal (RICE) |
| Confidence | How confident you are in your own estimates | High is 100 %, medium 80 %, low 50 % (RICE) |
| Effort | How many person-months it will take | Whole numbers, with half a month as the minimum |
The value of the score is not the number itself but the fact that it forces confidence to be stated separately. An item with a huge expected effect and confidence of one half stops looking like an obvious decision.
A plan works best as a single table where each row is one change and the columns repeat the six fields of a recommendation plus the measure. Such a plan reads in a minute and needs no covering note.
| Column | What goes in it | The mistake it catches |
|---|---|---|
| Fact | What the data showed and for which period | A conclusion drawn from impressions and never checked against an export |
| Cause | Why it is happening | Treating the symptom instead of the cause |
| Action | What exactly changes | A wording that cannot be turned into a task |
| Measure | Which indicator you watch | A change whose result cannot be verified |
| Expected effect | Where and how far the indicator should move | An argument about the result after the fact |
| Owner | One person | “Everyone” means nobody in practice |
| Deadline | The date it is due | Open-ended items that migrate from plan to plan |
The measure is chosen before the change, not after it. The Google researchers' paper on user-centred metrics describes a separate process for exactly this: metrics are derived from product goals rather than picked afterwards to fit a result you already have.
Rolling out is separate work with its own rules, and it starts where the analytics ends. The sequence is simple, and every step in it is the one usually skipped.
A change counts as implemented not when the instruction goes out but when the new way of working has become routine and shows up in the chosen measure. Between those two moments lies the work of making the new order stick, and that is where most plans are lost.
It helps to accept in advance that not every idea works. At Bing, where changes are tested with controlled experiments, less than a third of ideas move the metrics they were designed to improve, as Ronny Kohavi of Bing R&D wrote in 2013. The share does not transfer to offline processes, which have fewer variables and fewer changes, but the conclusion does: without a before and after reading you do not know what worked.
A separate difficulty is tying a change to money rather than to an intermediate measure. Once the path from advertising to payment is assembled into one chain, it takes a single export; how to build that chain is covered in our article on end-to-end analytics.
The reasons plans fail repeat themselves, and almost all of them are visible while the plan is still being written. Walk through this list before handing the plan over.
Ending up with a shorter list is normal. A short list of implemented changes beats a long list of planned ones, and the items left out do not disappear: they wait on the backlog until the next review.
Syntra Systems does not sell a separate “change support” service: this work sits inside project development, from $1,500 a month. We collect and prioritise tasks together with you, allocate a fixed number of team hours per month, work in sprints with a demonstration of the result, and revisit priorities every quarter against the goals of the business. The terms are on the technical support page.
Technical changes do not stay in people's heads either: we keep documentation so that the new way of working can be handed to another team. And if there is no plan yet and it is unclear which findings to act on at all, the place to start is not this article but a review of the processes.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Cut the list down to what the team can close in a quarter. The rest moves to a backlog with a review date. A long plan does not speed work up, it dilutes ownership: when twenty items are in progress, none of them counts as urgent.
Each item needs one named person on your side responsible for it, not a department: a new way of working only becomes routine for the people who actually follow it. We can handle the technical changes as part of ongoing project development, from $1,500 a month — a fixed block of hours, sprints with a demo, and priorities revisited quarterly.
Look for a signal that reflects the goal indirectly: the number of enquiries, the share of repeat purchases, the duration of a stage, the amount of rework. If no signal exists at all, that is a reason to question the recommendation itself, as the goal is probably stated too broadly.
As many as can be spread across different processes and different owners. Inside one process change one thing at a time, otherwise you cannot tell what produced the result. This is a limit on the clarity of conclusions, not on the team's capacity.
Record it as a hypothesis and raise a short separate task to test it: an export, ten calls, a conversation with the people doing the work. Acting on an unknown cause costs more than the week it takes to establish it, and it usually produces no effect.
