Selling dashboard and report templates to people who buy time

Every analyst has a file they have rebuilt four times. The weekly revenue report with the cohort tab. The paid-media dashboard with the blended-CAC panel that took a fortnight to get right. You carry it from job to job in slightly different forms, and every time you rebuild it you think, briefly, that someone should just sell this. Someone should. It is you.

Why templates are harder to sell than they look

A template is a product whose value depends on somebody else's data. That is the whole difficulty in one sentence. Your beautiful cohort tab assumes a table with one row per order, a customer identifier, a timestamp and a currency amount. The buyer has a spreadsheet with merged header cells and a column called value2. Nothing about your work is wrong, and it still will not run.

So the real product is a translation layer: a documented expectation of what goes in, and clear instructions on how to get from their mess to that shape. Sellers who skip this part end up doing it individually, over email, for every buyer, for free. That is not a support problem. That is a documentation problem wearing a support problem's coat.

The second difficulty is that your buyers are competent. They can build this themselves and they know it. They are buying the hours, not the capability, which sets the price honestly: what is two days of an analyst's time worth to the person paying for it, and what fraction of that will they hand you to skip the rebuild.

Handing over a file versus selling a template

Most analysts start by sending the file to whoever asks, which is generous and unbounded. The difference between that and a product is not the file; it is everything wrapped around it.

What ships with a template people can actually install

Assume your buyer is skilled, busy and working with data that does not match yours. Build the package as a digital download and treat the setup guide as part of the product rather than as an afterthought.

The questions that arrive whatever you do

• "Will this work with my warehouse or my spreadsheet?" Answer with the schema, not with a yes.
• "Can I use it for client projects?" Answer in the licence, in one sentence.
• "My numbers do not match my other report." Answer with the metric definitions page you already wrote.
• "Can you set it up for me?" That is a paid booking, not a support ticket, and it should have its own price.

What a template looks like as a small business

Say the template sells at £39. It is a serious price for a serious buyer, and it is trivially justified against two days of internal build time. If twelve people buy it over a quarter, mostly from one thread where you explained the cohort logic in public, that is a few hundred pounds against roughly a day of packaging work. Whether twelve happens depends on your audience and how visible your thinking is, and nobody can promise you that.

The compounding comes from the questions. The first five buyers ask eleven things between them. Six of those go into the setup guide, and the next twelve buyers ask almost nothing. Your product improves, your evenings return, and the version everyone holds is the improved one, because replacing the file updates every past buyer's download. If you want to see which plan gives you the analytics and the campaign tools to push a new version, the pricing page spells it out, and paid plans start with a 14-day free trial.

The mistake most analysts make

They sell the artefact and hide the assumptions. The screenshots look immaculate, the description talks about clarity and insight, and nowhere does it say the template expects one row per transaction with a UTC timestamp. Buyers discover that after paying, which converts an eager customer into a refund request and a slightly bruised reputation among people who all know each other. The second mistake is pricing like a stock-photo site. A £6 template attracts buyers who want you to rebuild their data model for nothing; a £39 template attracts people who value their own time and respect yours.

Handling the messages you do get

Technical products generate technical questions, and that is a good sign rather than a failure. Keep them in one place: the store.fan inbox sits next to the orders, so you can see what someone bought and when before you answer, and it is on your phone in the iOS app alongside products, orders and revenue. Answer once, properly, then ask yourself whether the answer belongs in the setup guide. If it does, edit the file, replace it, and the next buyer never needs to ask. Anything genuinely bespoke goes to a paid call with order-form questions so you get the schema before the meeting starts. There is more on how the pieces fit together in the FAQ.

The file is not the hard part; you built it years ago. The product is the schema page, the ten setup steps and the definition of churn you settled on at some point and never wrote down. Write those down once and you are selling the thing you actually know, rather than a picture of it.