Pricing an enterprise pilot by workload, not feature count

Why small pilots cost more than they look

An enterprise pilot starts long before anyone tests the feature. Your team spends time on calls, security questions, access rules, sample data, success criteria, and somebody else's approval chain. None of that shows up in a tidy scope document, but it still costs money.

That's why feature count is a bad way to price a pilot. A buyer might ask for "one workflow" or "a small paid trial," but most of the labor sits around the feature, not inside it. A two-page prototype can still require ten meetings, three rounds of data fixes, and daily check-ins once the pilot begins.

Support is where many quotes break down. Enterprise teams often want close help in the first few weeks because the pilot feels risky. They ask for status updates, import help, extra user roles, and small changes that sound minor on their own but add up fast.

A common example looks simple on paper: one dashboard, one import, two weeks. In practice, someone has to map columns from three exports, fix broken IDs, explain missing rows, answer daily questions, and rebuild the chart after a manager changes the cutoff date. The dashboard itself might take six hours. The manual work around it can take thirty.

Data causes even more trouble. The file a client sends rarely matches the format they described. Fields are missing, names are inconsistent, dates use mixed formats, and duplicates appear after the first import. If you don't price data cleanup up front, those hours come out of your margin.

Reporting is another quiet cost. First the client wants a weekly summary. Then they want it split by team, then by region, then without test records, then in a format they can paste into a leadership update. Each request sounds reasonable. Together they can eat days.

Small pilots aren't cheap because they're short. They get expensive when setup, support, data cleanup, and reporting all need hands-on work.

Where the work really hides

Most pricing mistakes start before anyone writes code or turns on a workflow. The feature list looks short, so the quote looks small. Then the team spends days on admin work, cleanup, follow-up, and reporting that nobody counted.

Access is usually the first drain on time. A "quick kickoff" turns into two or three calls with different people, followed by a chain of emails about logins, approvals, VPN rules, test accounts, and security forms. If the pilot touches internal data, IT, legal, or compliance may step in too. The feature set hasn't changed, but the hours keep growing.

Data work hides in plain sight. Clients often say their file is ready, but pilot data is rarely clean enough to use on day one. Column names don't match, records are incomplete, exports come from different systems, and edge cases appear only after the first test run. Even a small pilot can need a surprising amount of manual fixing before the real evaluation starts.

Support grows fast after training or rollout. People try the pilot, get stuck, ask the same question in three different ways, or use the tool in ways nobody expected. Even a solid onboarding session won't stop that. Five users sending two short questions each week can still turn into a couple of hours once someone reads the message, reproduces the issue, answers it, and checks the result.

Reporting deserves its own line in the estimate. Enterprise buyers usually want a weekly summary, status notes for managers, and some custom view of progress or usage. One report may take only 30 minutes at first. Four rounds of edits, screenshot requests, and extra context can turn it into half a day.

Scope drift usually arrives in harmless language. "Can we add one more file?" "Can this report break out one more segment?" "Can we invite the operations team too?" Each request sounds tiny. Together they change setup, testing, support, and reporting.

If you're running an AI or automation pilot, this becomes even more obvious. A small test may still need prompt review, sample cleanup, and careful checks on output quality before a client feels safe using it. That's real work, even when nobody asked for a new feature.

Questions to answer before you quote

Before you send a paid trial quote, pin down the work around the pilot, not just the feature the client wants to test. A pilot that looks tiny in a demo can turn into days of setup, cleanup, calls, and hand-holding once real people start using it.

Start with users. How many people will join? What jobs do they do? Who goes first? Ten operations staff following one process are very different from ten executives who each want a custom view. Early users shape onboarding time, access rules, training, and support volume.

Then ask about data. Where does it come from? Who owns it? What shape is it in right now? Clients often say the data is "mostly clean," but that can still mean missing fields, duplicate records, old exports, or mismatched IDs across systems. One spreadsheet import may take an hour. Three systems with inconsistent names can eat half a week.

Meeting load matters more than most people expect. Find out how often they want check-ins, who needs to attend, how fast they expect answers, and whether they want written status updates. Weekly steering calls, ad hoc Slack support, and a custom report every Friday can cost more than the original setup.

Success also has to be concrete. If the client can't say what a good outcome looks like, the scope will drift. Ask for one clear finish line. Maybe a team processes 200 records with fewer errors, or a report that used to take four hours now takes 30 minutes. That gives you something to build toward and something to stop at.

One more question saves a lot of margin: who can approve extra work when the scope changes? In enterprise pilots, scope almost always changes. Security asks for another review. Legal wants a data note. A manager asks for one more dashboard. If nobody owns approvals, those requests slide into your time for free.

A simple comparison makes the point. A trial for six users with one CSV file and one review meeting might stay small. The same trial with 25 users, two messy sources, twice-weekly calls, and an executive summary every week is a different job.

Clear answers usually mean a cleaner pilot. Vague answers usually mean hidden work.

How to estimate the work

Start with the full path of the pilot, not the feature list. A client may ask for one workflow, one dashboard, or one integration. That still creates work before anyone sees a result.

Write down every task from kickoff to final review in the order your team will actually do it. Keep it plain. Include scoping calls, access requests, sample data checks, environment setup, test runs, fixes, weekly check-ins, report prep, and the last review meeting. If the pilot touches messy source data, list cleanup and validation as separate tasks. Don't bury them inside setup.

Then split the estimate into two buckets: one-time work and repeating work. One-time work covers kickoff, setup, data mapping, first configuration, the initial test, the report template, and the final readout. Repeating work covers weekly support, status calls, error review, small changes, report updates, and client follow-up.

That split matters because clients often say, "It's only a four-week trial." Four weeks can still carry a heavy setup load. Miss that, and the quote looks fine on paper but feels awful by week two.

Next, put a low and high hour range beside each task. Don't pretend you know the exact number yet. "Clean sample data" might take three hours if the file is tidy, or twelve if column names change, dates are broken, and half the records need manual fixes. A range lets you price uncertainty instead of guessing.

After that, add time for the parts clients create without meaning to. Handoffs between teams slow things down. Legal or security review can delay access. Stakeholders ask for changes after they see the first draft. Add a buffer for rework, waiting, and extra coordination. If your estimate has none of that, it's probably wrong.

A short checklist helps:

• What has to happen before the first useful output?
• What repeats every week?
• Where can data cleanup expand?
• Who approves each stage?
• What usually gets redone after the client reacts?

Before you send the number, review the estimate with the person who will do the work. Sellers remember the happy path. Operators remember the real one. If those two views don't match, the margin disappears first.

How to turn effort into a price

A pilot price should match the work people will actually do, not how short the feature list looks. If the client says, "It's just a small paid trial," but your team still has to clean data, answer questions, and explain results to five stakeholders, the quote needs to show that.

Start with a base fee. This covers the work that happens before the pilot produces results: kickoff calls, access setup, initial discovery, workflow mapping, permissions, and the first round of configuration. Even a simple pilot burns real time in week one, and that time shouldn't hide inside later line items.

A clean quote usually breaks the work into a few parts: a base setup fee, support during the pilot, data cleanup, reporting and readouts, and a clear rule for out-of-scope work. That structure makes the price easier to defend because each moving part has a place.

Support deserves its own pricing logic. Some clients need one short check-in each week. Others want fast replies, urgent fixes, and help for several teams at once. Price that difference on purpose. A weekly support fee works well for steady usage. A response-window model works better when the client cares about speed, such as next business day versus same day.

Data cleanup should almost never sit inside setup. Messy exports, duplicate records, broken formatting, and missing fields can eat more time than the product work itself. Put cleanup on its own line item with a limit, such as a set number of rows, files, or hours. If the client brings cleaner data than expected, great. If not, your margin stays intact.

Reporting is another place where teams underquote. A weekly summary sounds small until you count the time needed to gather numbers, check what changed, build a simple deck, and join a readout meeting. If three managers want separate updates, that's more work, not "part of the pilot."

A simple pricing structure

One practical quote might include a fixed base fee for week-one setup, a weekly support charge for the pilot period, a capped data cleanup line, and a fixed fee for each report or stakeholder readout. Then add one plain sentence for work outside the plan: anything beyond the agreed hours, files, integrations, or meeting count moves to extra billing after written approval.

That last rule matters. Without it, every "small" request lands on your team for free.

A realistic example

A buyer asks for a six-week pilot for 50 users. On paper, it sounds small. They want one connector, one CSV import, a weekly check-in, and a short report every Friday. If you price that by feature count, the quote can look almost harmless.

The trouble starts when real work shows up. The first CSV file arrives with duplicate records, missing fields, and names that don't match the data in the source system. Now the pilot needs cleanup rules, manual review, re-imports, and a few calls to confirm what the client actually wants to keep.

A simple quote might assume 35 to 40 hours. That's where margin disappears. A more honest estimate often looks closer to this:

• Connector setup and testing: 12 hours
• CSV mapping, cleanup, and rework: 18 hours
• User support during the pilot: 20 hours
• Weekly reporting and calls: 12 hours
• Project admin and small fixes: 8 hours

That total is 70 hours, and it's still fairly tight.

Support is the line most people miss. During week one, the buyer may need only a few answers. After they train their own team, question volume usually jumps. Suddenly you're replying to login issues, bad imports, edge cases, and "can you check this one record" messages from five different people instead of one sponsor.

Reporting eats time in a quiet, steady way. A weekly report sounds light until you count the actual steps: pull usage numbers, explain what changed, note data issues, write a clear summary, join the call, and send follow-ups. Even if each report takes only two hours, six weeks means 12 hours gone.

If your rate is $175 an hour, 70 hours puts the pilot at $12,250. Add a small buffer for unknowns and the fixed quote may need to be closer to $13,500 or $14,000. If you quoted $7,000 because the pilot had only "two features," you didn't price the real job.

The features may stay small. The manual work rarely does.

Mistakes that cut your margin

The fastest way to underprice a pilot is to trust the word "small." Clients use "small" to describe scope, not labor. A pilot with one workflow can still eat days of work if you need access approvals, messy exports, hand fixes, weekly check-ins, and a report for six stakeholders.

Another common mistake is rolling setup, support, and reporting into one flat fee. That looks simple on the quote, but it hides the parts that grow first. Setup expands when access is delayed. Support grows when users test edge cases. Reporting grows when leadership asks for one more cut of the numbers, then another slide for finance, then a version for operations.

The margin leak usually isn't the build. It's the extra labor around the build.

Stakeholder time gets missed all the time. One pilot can pull in an ops lead, an IT owner, a security reviewer, a procurement contact, and a manager who wants updates before every meeting. Even if each person needs only 20 minutes, the total adds up fast. Add a vendor form, a security questionnaire, a redline on terms, and two status calls, and the "small paid trial" has already grown by half a day or more.

Unlimited support during the trial is another quiet loss. Clients hear "pilot" and expect close help. If you say "reach out anytime," they will. A few Slack threads, a couple of urgent calls, and several rounds of "can you just check this" can wipe out your profit. Put limits on response windows, channels, office hours, and who can ask for help.

Reporting can hurt even more if you promise a final report before you inspect the data. Dirty source data changes everything. Missing fields, duplicate records, broken timestamps, and inconsistent names can turn a basic summary into manual cleanup work. If the data is worse than expected, the report stops being a wrap-up task and becomes its own project.

One simple rule helps: split the quote into separate lines for setup, live support, data cleanup, and reporting. Then add a cap for meetings and admin time. If a pilot touches product, data, and infrastructure at once, an outside review can help too. Oleg Sotnikov at oleg.is does this kind of Fractional CTO advisory, and a quick scope review can surface hidden work before it turns into unpaid hours.

If the client won't agree to limits, the pilot isn't small. The price should reflect that.

Before you send the quote

Pressure-test the work from four angles: setup, support, data, and reporting. A pilot can look tiny on paper and still eat days of manual work once access requests, file cleanup, status calls, and approval delays start piling up.

Features are easy to count. Hours disappear in the handoffs around them.

Before you send the quote, make sure each work bucket has an owner. Decide who handles setup, who answers support questions, who fixes or maps data, and who prepares reports. Write the scope in plain language. List what you'll do, what the client must provide, and what sits outside the trial. Put the end date in writing, along with what happens after that date. Check the data before you commit, and check the approval path too. If legal, security, procurement, or an internal data team need to weigh in, expect waiting time and follow-up work.

A small example shows why this matters. A client may ask for a two-week pilot with one dashboard and one import. Sounds simple. Then you learn their CSV has mixed date formats, two departments must approve access, and they want a Friday summary for leadership. The feature list stayed short. The workload didn't.

If you can't name the owners, the scope, the trial end date, and the likely delay points, the quote isn't ready yet. Fix that first. Then send a number you can defend.