Here's the situation I was trying to fix.
For two years I built a weekly dashboard for my own team. It worked: it turned a scattered set of numbers into something a director could read in five minutes and use to decide something. I'd tested it, tuned it, and it survived contact with a real job.
Then I tried to turn it into something a small business would pay for. The first version I pitched was, essentially, my dashboard. It failed. Not because the work was bad, but because a small business doesn't need what an internal team needs. They need a reporting package—a thing that arrives, makes sense, and doesn't require them to maintain anything.
This piece is the story of that conversion. It's the second in One-Person Offers, and it's the specific case of moving from an internal workflow to a sold deliverable.
Why the Internal Workflow Doesn't Convert Directly
Three mismatches, and they all showed up in the first pitch.
The Audience Is Different
My internal dashboard was built for a director who knew the business, knew the metrics, and knew what questions to ask. A small-business owner knows their business intimately and knows almost nothing about reporting. The dashboard assumed a reader who could interpret. The package has to assume a reader who can't—and shouldn't have to.
That's not dumbing it down. It's changing the job. An internal dashboard answers "what happened?" A client package answers "what happened, what it means, and what to do about it."
The Maintenance Is the Product
Internal dashboards get maintained by the team that uses them. A sold package can't. The moment a client has to update something, the value collapses—they didn't buy a tool, they bought a task.
So the package has to be either fully maintained by you, or self-contained enough that it needs no maintenance at all. There's no middle ground that survives.
The Scope Creeps Immediately
My internal dashboard had grown over two years, one feature at a time. A client package can't do that. Every feature is a promise. The first pitch included four metrics, two views, and a monthly summary. The client asked if it could also track a fifth thing. It could. And then a sixth. And then the package was a custom project.
The scope has to be fixed, written down, and defended—including by you, especially when a client asks for "just one more."
The Conversion
Here's the actual path from internal workflow to client package. Four moves.
Move 1: Change the Output, Not the Engine
The underlying data work—the queries, the joins, the cleanup—can stay largely the same. What changes is the output.
Internal: a dashboard the team opens.
Client: a brief that arrives.
The client doesn't want to log in and explore. They want something in their inbox on Monday morning that tells them what they need to know. Same engine, different wrapper. This is the single biggest change, and it's mostly about packaging, not rebuilding.
Move 2: Fix the Scope in Writing
Before any client conversation, write the package down:
What's included: the specific metrics, the specific cadence, the specific format.
What's excluded: explicitly, the things clients commonly ask for but that aren't in scope.
What the client does: usually, nothing—or one simple input.
What you do: everything else.
What happens when they ask for more: the answer, decided in advance.
That last one is the one that saves the business. The answer is usually: it's a separate add-on with a separate price. Not "sure, I'll add it." A separate, priced change.
Move 3: Add the Human Layer
This is the part that makes a package worth paying for and a dashboard worth ignoring. The client doesn't just get numbers. They get:
A brief. Two or three sentences at the top: what changed, and what it means.
A caveat. One line: what would change the picture.
The detail. The metrics, in an appendix, for anyone who wants to verify.
This is the same structure I use for internal briefs, and it converts almost directly. The difference is that with a client, the human layer is the product. They're not paying for the data—they can get data anywhere. They're paying for the interpretation.
Move 4: Price the Maintenance, Not the Build
The first pitch priced the setup: build the queries, set up the format, deliver the first one. That was a mistake. The client's real cost—and your real cost—is the ongoing work, not the initial build.
The pricing that worked had two parts:
A setup fee. One-time, for the initial build and the first delivery.
A monthly fee. For the ongoing delivery, the interpretation, and the small adjustments that inevitably come.
The monthly fee is the actual business. The setup fee just funds the transition. If the monthly fee doesn't work for the client, the package isn't a business—it's a project.
The Before and After
Same underlying work, two versions.
Before (the internal-style pitch):
I build reporting dashboards. I'd set up a weekly dashboard for your business with the key metrics, and you'd have access to it whenever you want. Setup is $X.
This described a tool. The client already had too many tools, and none of them got looked at after week two.
After (the package):
Every Monday morning, you get a one-page brief: what changed in your business last week, what it means, and what I'd watch. Three numbers, two sentences, one recommendation. You don't log into anything. You don't update anything. If something needs your attention, it's in the brief. Setup is X;ongoingisX;ongoingisY/month.
This described a habit. It arrived whether the client remembered it or not, and it made a small decision easier every week.
The second one sold. The first one didn't.
What Still Needs You
The parts of this conversion that can't be automated or templated:
Choosing the metrics. Which three numbers matter to this specific business is a judgment call. A model can suggest common ones; only you can decide which are signal for this client.
Writing the interpretation. The two sentences at the top—what changed and what it means—are the product. They require context about the business that lives in your head and the client's, not in the data.
Defending the scope. The client will ask for one more thing. Saying no—or pricing the yes—is a human call, and it's the one that keeps the package a business instead of a custom project.
Knowing when to walk. Some clients want a custom analyst, not a package. Recognizing that early and declining is the move that protects your evenings.
Deciding the price. The pricing model above is a shape, not a number. The number depends on the client, the market, and what your time is worth—and it has to be one you're not resentful about in month three.
The model can help you build and maintain the engine. You define the package, the interpretation, and the boundary.
The Four-Week Version
If you have an internal reporting workflow and you're wondering whether it could be a package:
Week 1: Write the package down. Output, cadence, scope, exclusions, what the client does, what you do.
Week 2: Convert one real dataset into the new output. If you don't have a client yet, run it on your own data or a public dataset. Make the brief.
Week 3: Show it to one small-business owner you know. Not to sell—to learn what they'd actually want in it. Adjust the scope based on what you hear.
Week 4: Price it. Setup plus monthly. Offer it to one person at that price. See what happens.
One month, one real conversation, one price. If nobody bites, you've learned the package isn't right yet—and you've learned it without quitting anything.
The internal workflow is the asset. The package is a specific, scoped, priced version of it. The conversion is real work, but it's the work that turns a skill you already have into something someone will pay for.
Better work first. More options next.
Make the workflow earn its place.
No feedback yet — submit the first.