Price custom work in hours before sales eats your margin

Why small promises turn into unpaid work

Sales teams say yes because they want the deal to keep moving. A prospect asks for one custom report, one data import, or a quick security review, and it sounds small enough to fold into the quote.

The trouble starts later. Delivery teams do not see "one small request." They see field mapping, odd cases, test data, access rules, revisions, and support after launch. Work that sounded like two hours on a call turns into ten once someone has to build it.

Custom work usually does not crush margin in one shot. It leaks out in pieces. One report needs filters. One import needs cleanup. One security question turns into a questionnaire, a meeting, and permission changes. Each item sounds minor on its own, so nobody prices it properly.

A common deal looks like this: a buyer asks whether the team can import old data and add a dashboard. Sales says yes because the request feels normal. After the quote goes out, delivery learns the source file has inconsistent columns, duplicate records, and missing dates. The dashboard also needs role based access and three review rounds. The price stays the same, but the hours do not.

The biggest leaks usually come from the same places:

• custom reports with filters, exports, and revision rounds
• imports that need cleanup, mapping, and validation
• security requests that trigger reviews, documents, or access changes
• small workflow tweaks that touch testing and user training

That is why custom work should be priced in hours, even when it sounds easy. Hours force a real conversation before the quote leaves the building. They also give sales a cleaner way to respond: "Yes, we can do that. It adds 12 hours."

Margin rarely disappears because of one terrible deal. It slips away one promise at a time, and most of those promises sound polite, useful, and small.

The requests that hide the most hours

The work that gets underpriced almost always sounds harmless on the call. "Just one report." "A quick import." "A few security answers." Then delivery spends days on odd cases, bad data, rework, and follow up.

Custom reports are a classic margin leak. A buyer asks for a report, but the real work lives in the details: which fields count, which filters users can change, how date ranges behave, who can see what, and what happens when the numbers do not match another system. Building the screen is often the easy part. Agreeing on the logic and testing the result takes longer.

Imports create the same problem. Sales hears "we have a CSV." Delivery finds broken rows, missing fields, duplicate records, odd date formats, and bad IDs. Someone has to clean the file, map the columns, define rules for failed records, and decide what happens when an import stops halfway through. Sometimes the retry path takes longer than the first import.

Security requests look harmless because they do not always involve code. They still take time. Customer security questionnaires need review, written answers, and sometimes a call with the buyer's IT team. If the customer asks about logging, encryption, backups, or data retention, a senior person usually has to answer.

SSO and access rules are another trap. "Use our login" can mean SAML setup, role mapping, test accounts, fallback access, and rollout support. Once access rules enter the deal, more questions follow. Who can export data? Who can approve records? Who can see admin pages?

One off exports rarely stay one off. A prospect asks for a custom file for finance, operations, or a partner. After launch, they want the same file every week, then with one more field, then delivered on a schedule. What started as a small favor becomes recurring work.

When sales hears any of these requests, the safe move is simple: write them down, split them into hours, and keep them out of the base price unless they are truly standard.

How to estimate the work step by step

Start by rewriting the request in plain language. If sales says, "They need a custom report and a small import," that is too vague to price. Write what the team will actually do: "Build one weekly sales report, import a CSV with 20,000 rows, and limit access to finance users only."

That short rewrite removes guesswork and gives everyone the same picture before you attach a number.

Then split the work into parts people can estimate without hand waving:

• setup: access, sample files, field mapping, and a short kickoff
• build: the report, import logic, filters, or permission rules
• test: bad rows, odd cases, and user access checks
• support: fixes after client review and launch help

This is where hidden hours show up. A simple import often needs data cleanup. A quick report often needs two rounds of changes because the client sees the first version and asks for new columns.

Next, name an owner for each part. One person rarely does all of it. Sales may collect the request, a product lead may confirm fields, an engineer may build it, and someone from support or customer success may test it with real customer data. If nobody owns a step, that time never gets priced.

Add review time on purpose. Do not bury it inside build hours and hope it fits. If the task touches customer data, permissions, or outside files, add time for internal review and at least one rework pass. If the client can reject the first version, budget for that now.

Mark unknowns before you send the estimate. If you have not seen the sample file, do not pretend the import is clear. If nobody defined who can see the report, do not guess the access rules. Write the estimate with notes such as "includes one CSV format" or "assumes two user roles."

Last, turn the estimate into its own line item. "Custom report and CSV import - 12 hours" is clear. "Setup support" is where margin disappears.

Give sales a short intake form

Small extras stay small only when sales asks a few plain questions before the quote goes out. A short intake form can save hours of follow up and stop vague promises.

Keep it short enough that sales will actually use it. Five questions are usually enough:

• What does the customer want to see, export, approve, or change?
• Which system or file holds that data today?
• How clean is the source data right now?
• What date matters most for this request?
• Who can approve extra paid work?

The first question usually clears up the real job. The rest tell you how messy it will be, how urgent it is, and whether anyone can approve the extra cost.

A simple deal example

A buyer likes your product and wants to move fast. During the call, they ask for three custom reports, one CSV import from their old system, and a security review from their IT team. Sales could roll all of that into the quote and hope delivery sorts it out later. That is how margin disappears.

A better approach is to break the work apart instead of hiding it in one vague line:

• Report 1: sales by region with filters - 4 hours
• Report 2: renewal forecast - 6 hours
• Report 3: commission summary - 5 hours
• CSV import mapping and test load - 8 hours
• Security questionnaire and follow up call - 3 hours

Now the quote is easy to read. The base price includes the standard product setup, user onboarding, and the reports already in the product. The custom items sit in a separate section with their own hours and fees.

Sales can explain the split in one sentence: the base price covers the product you deliver for every customer, while the extra fee covers work built for this buyer only. Most buyers accept that logic when they see the scope in writing.

If the customer says, "We only need one report at launch," the team can trim the quote in minutes. If the security team waives the review, that fee drops out too. Nobody has to rebuild the whole deal.

A quote in this format might be as simple as:

• Base subscription and setup: included in standard price
• Custom work total: 26 hours
• Security review support: billed once
• Start date: after scope approval

The buyer sees what they are paying for before signing. Sales stays honest. Delivery gets a scope it can plan. Finance gets fewer surprises.

When to charge separately

A quote should cover the work you already understand. The moment a request needs original engineering work, it should move into its own line item. If you do not split it out, small sales promises turn into hours nobody can bill.

A good rule is simple: if the request changes how the product works, touches messy customer data, or pulls engineers into review calls and documents, charge separately.

A few requests almost always deserve that treatment:

• a report with custom logic, special filters, or a new data model
• an import that depends on old spreadsheets, inconsistent fields, or manual cleanup
• a security review that needs engineers to fill questionnaires, join calls, or prepare evidence
• a request with fuzzy scope and comments like "we'll know after a quick look"

Custom logic is the clearest case. A prospect may call it "just one report," but that can mean new queries, permissions, odd cases, testing, and support after launch. If your team needs to build something that will not exist for other customers, do not bury that time in the base price.

Data work gets underpriced even more often. Imports sound routine until you see duplicate records, missing columns, broken dates, and hand edited CSV files. When data quality will decide how long the job takes, split the estimate and state your assumptions.

Security work deserves the same treatment. Many teams treat questionnaires and review meetings as sales overhead. That only works for very simple deals. Once engineers need to explain architecture, gather logs, map controls, or answer follow up questions, the work is real and so is the cost.

If scope stays fuzzy, sell paid discovery first. A short fixed package works well: review the request, inspect sample data, answer security questions, and return a scoped estimate. That protects both sides.

It also helps to set a hard limit on free presales help. For example, give up to two hours at no charge, then move extra calls, data checks, and technical review into a paid block. Sales respects the boundary when you make it visible early.

Mistakes that drain margin

Margin usually leaks through work nobody names out loud. A sales call ends with "one small report," "an easy import," or "a few security answers," and the quote stays the same. The team pays for that optimism later with extra meetings, rework, and support time.

One common mistake starts with reports. A report sounds small until someone checks the source data, filters, odd cases, export format, and permission rules. If the data is messy or split across systems, a simple report can take longer than the feature it sits on.

Another mistake is bundling unknown work into the base price. If sales includes custom fields, data cleanup, migration mapping, or admin setup without a cap, the deal looks better on paper than it feels in delivery. Pricing those items in hours forces a useful pause: what is included, and what needs separate approval?

Teams also miss the quiet work after launch. Testing takes time. So does fixing odd cases the client finds in the first week, answering behavior questions, and updating docs when the setup changes. If nobody prices that follow up work, margin drops after the contract is signed.

Security requests create the same problem. A customer may ask for a questionnaire, an architecture call, data handling notes, or a review with their IT team. None of that writes itself. If your quote includes security help with no limit, you can spend hours in calls before the project even starts.

A few habits prevent most of this:

• check the data before agreeing to any report
• keep unknown items outside the base price until someone scopes them
• add time for testing, launch support, and client questions
• count security forms, review calls, and approval meetings
• require approval before sales promises any change

The last mistake is process. Sales says yes to keep momentum, then delivery inherits the promise. A simple rule fixes a lot: no change enters the quote until the person doing the work reviews it first.

A 5 minute check before you send the quote

Before a quote leaves your inbox, read it like the person who has to deliver the work. Five minutes now can save days of argument later.

This is the point where teams usually lose money. A quote says "custom report" once, but delivery hears data mapping, filter logic, revisions, testing, and user questions. If the work is custom, attach hours now.

Use one fast review before anyone sends the final number:

• write down every request outside your standard package
• put an hour range next to each item
• add one short assumption for each custom item
• name anything included at no charge and who approved it
• make sales and delivery read the same scope before it goes out

A simple example shows why this matters. Sales promises a quick import for a new customer. Delivery later finds three file formats, duplicate records, missing fields, and two rounds of test data. What looked like two hours turns into fourteen. The problem was not the work itself. The quote never spelled out what "quick import" meant.

Healthy teams make invisible work visible. They do not rely on memory, optimism, or chat messages. They name the extra requests, attach time, and record assumptions while the deal is still small.

What to do next

Start with your last ten closed deals, not your next one. Old quotes tell the truth quickly. Look for every extra report, import, access rule, audit question, or one off workflow that sales promised and delivery handled quietly.

Mark each extra with a rough hour count. You do not need perfect data. If a custom report usually takes three to six hours, write that down. If import estimates swing from four hours to twenty because cleanup always shows up late, record that too. Do the same for security review work, especially when a buyer asks for questionnaires, SSO details, or vendor review calls.

Then turn what you find into a short operating rule for sales:

• review the last ten deals and list unpaid extras by type
• set default hour ranges for reports, imports, and security requests
• bring delivery in any time a buyer asks for something outside the standard package
• record every promised extra in your CRM or quote notes before the proposal goes out
• check those ranges once a month until they stop moving

This does not need a heavy process. Sales needs one clear rule: if the buyer asks for custom data work, a special report, or a security item that is not already in the offer, get delivery hours before sending the quote.

Keep the tracking simple. One note field in the CRM is often enough if people actually use it. Some teams prefer a quote template with three lines: custom reports, imports, and security review. Either way, the point is the same. If nobody writes it down, margin disappears and nobody can explain why.

If your team needs help tightening this process, Oleg Sotnikov at oleg.is works with startups and smaller companies as a Fractional CTO and advisor. He helps teams scope technical work more clearly, improve handoffs, and build a more practical quoting process.