Pricing internal integrations without losing money

Why integration deals go wrong

Integration deals usually go bad for a simple reason: sales hears a familiar product name and assumes the work will be light. Delivery inherits the real job later.

When a prospect says, "You already integrate with Salesforce" or "You support SAP, right?", both sides think they agree. They usually do not. Sales hears "connector exists." Engineering hears a stack of unknowns about data, permissions, workflows, and exceptions.

Many teams call something an integration when they only have a basic connector. That might cover API access, a login flow, and a few standard objects. It does not mean the customer's fields, rules, security setup, old data, and edge cases will work without extra effort.

The gap shows up after the contract starts. Engineers open the sandbox and find custom objects, odd naming, half-filled records, approval rules, rate limits, and missing documentation. A job that sounded like "turn it on" turns into mapping, retries, logging, testing, and manual cleanup.

The hidden work is familiar:

• field mapping and data transforms
• auth setup and permission review
• error handling for bad or incomplete records
• testing in sandbox and production
• one-off business rules

A CRM sync is a common example. The product already connects to that CRM, so the software price looks reasonable. After kickoff, the team learns the customer has custom stages, separate ownership rules by region, and old records that no longer match current IDs. None of that was in the original quote.

Services hours grow in small pieces, which is why teams miss the problem at first. One engineer spends six hours on mapping. Another spends a day fixing auth. A senior developer steps in to deal with rate limits or a strange webhook issue. On paper the deal still looks fine. In practice, margin slips away week by week.

That is why integration pricing often fails even when the product price looks healthy. The software can be profitable while the labor around it is not. If sales promises "an integration" before anyone defines what the connector includes and what counts as custom work, the quote and the real effort separate fast.

What belongs in a connector and what belongs in custom work

Teams usually lose money when they mix reusable product work with client-specific service work. A connector should stay small, stable, and useful across customers. Custom work should cover the parts that change from one client to the next.

The connector usually includes the plumbing nobody wants to rebuild each time. That means authentication, token refresh, rate limit handling, retries, pagination, and the common endpoints most customers use. If nearly every client needs to read contacts, create orders, or pull invoices from the same API, that belongs in the connector.

Custom work starts where business decisions begin. Field mapping is custom because one client may map "account owner" to a salesperson while another maps it to a support rep. Workflow rules are custom because approval steps, routing logic, and timing vary a lot. Cleanup scripts are custom too, since messy data is rarely messy in the same way twice.

One-off reports and historical imports deserve separate line items. They sound small on a sales call, then turn into days of edge cases, broken CSV files, duplicate records, and manual checks. If a customer wants a special export for finance or a one-time backfill from an old system, price that separately instead of hiding it inside the connector fee.

Write down what every customer gets without changes. If you cannot describe it in a short reusable spec, it is probably not connector work yet.

A reusable connector usually has only a few fixed pieces:

• login and auth flow
• rate limits and retry behavior
• shared endpoints and standard actions
• error handling and logging
• version support rules

Keep that list fixed unless the product itself changes. Everything outside it should trigger a custom estimate.

This line matters during sales. If a rep promises "the integration" as one bundled thing, the team ends up doing product work, consulting, and data repair for one price. A cleaner quote separates the connector, the setup, and the custom work. Customers usually accept that split when you explain it in plain language, and your margin has a much better chance of surviving.

Scope rules to set before quoting

Most bad integration quotes are broken before any code starts. Sales hears "connect system A to system B" and treats it like one task. It never is.

A quote holds up only when it names the systems, the records, and the exact actions in plain words. If the client wants a CRM connected to billing, write the source and target by name and list the objects you will touch: contacts, companies, invoices, or payments.

"Customer data sync" is too loose. "HubSpot contacts to Xero customers, one way, every 15 minutes" gives both sides something they can actually check.

The first version needs hard limits. Start with a small action set, such as create and update only. Skip deletes, merges, backfills, historical cleanup, and odd edge cases unless the quote names them.

Teams lose money when they treat phase one like a full migration. A narrower first release is easier to test, easier to approve, and much easier to price.

Before you send numbers, put count limits in writing:

• up to 10 field mappings
• 1 workflow per direction
• 2 environments, usually sandbox and production
• 1 source of truth for each object
• 1 round of acceptance fixes after client testing

Counts matter because every "small tweak" adds review and test time. Two extra mappings can be quick. Ten usually are not.

Ownership rules protect margin too. The client should provide test data, admin access, sample records, and one person who can approve behavior. If nobody owns approval, your team waits, guesses, and reworks logic after the fact.

Put one change rule in every quote. If a request adds new objects, new actions, more workflows, another environment, or a different sync direction, treat it as extra scope and price it separately. Write that rule before the call ends, not after the first surprise.

Clear scope does not make deals smaller. It makes them real.

How to price the reusable part

If a connector can sell more than once, do not dump its full build cost onto the first customer. That makes the first deal harder to close, and it hides the fact that you are building something with future sales value.

Treat the connector like a small product inside your services business. Estimate what it costs to design, build, test, document, and maintain. Then spread that cost across the number of customers you expect will buy it over a reasonable period, such as the next 6 to 12 deals.

A simple method works. If the connector costs $12,000 to build and you expect to use it in 8 deals, recover about $1,500 per deal before margin. Then add the margin you want instead of guessing a number because sales wants the quote to look smaller.

You can charge the reusable part as a setup fee tied to activation and configuration, or include connector access in your product or service plan. The right choice depends on how customers already buy from you, but the rule stays the same: the reusable part needs its own line item.

Support needs its own price too. APIs change, auth rules expire, fields get renamed, and webhooks stop behaving the way they did last quarter. If you include unlimited fixes forever, the connector turns into a slow leak in your margin.

A recurring support fee is usually cleaner than burying maintenance in the first quote. It can cover version updates, minor break fixes, and routine compatibility work. If the source system changes in a bigger way, price that as new work.

Keep the standard connector scope short and plain. Put it in writing so sales, delivery, and the client all use the same definition. A basic scope might include authentication and connection setup, field mapping for standard objects, one agreed sync direction or trigger flow, basic error logging and retries, and simple admin documentation.

Anything outside that list should move into custom effort, not into the reusable connector price. That one habit fixes a lot of bad quotes.

How to price custom work

Start with discovery, even when the client wants a fast number. Custom integration work goes wrong when a team prices delivery before anyone checks the source system, the field shapes, the edge cases, or who owns decisions on the client side. Discovery is not overhead. It is paid work that keeps the main quote honest.

A simple way to price the custom part is to split it into separate buckets instead of one blended estimate: discovery and validation, data mapping, business rules, testing and fixes, then rollout and support.

Discovery covers API review, sample payloads, access setup, and a short call with the people who know the process. Data mapping covers field matches, format changes, ID handling, and the rules for mismatched records. Business rules cover approvals, exceptions, conditional logic, and any manual steps the client wants to keep. Testing covers failed imports, retries, test cases, and user review. Rollout covers training, cutover, monitoring, and a short stabilization period after launch.

Most teams still miss two costs. The first is bad source data. If names, statuses, or dates are inconsistent, someone has to clean, normalize, or reject them. The second is missing API fields. When the system does not expose a field you need, the team often builds a workaround, adds manual steps, or opens a new request with the vendor. That effort belongs in the quote.

If requirements still move, use a range instead of a fixed number. You might quote 25 to 40 hours for rules and testing, with the lower end tied to one approval flow and the upper end tied to several exception paths. That gives sales room to move without pretending the scope is settled.

Put approval points between each stage. Finish discovery and get sign-off. Finish mapping and get sign-off again. Do the same before rollout. Small checkpoints stop quiet scope growth, and they give both sides a clean moment to change budget or timing.

A quote built this way is less slick, but it usually protects margin.

A simple deal example

A mid-sized company wants HubSpot customer data to show up inside its internal billing tool. The request sounds familiar, so sales may treat it like a quick add-on. That is where margin often disappears. Billing rules create the real work, not the login screen.

In this case, the team already has a reusable HubSpot connector. It handles authentication, token refresh, contact sync, and the basic connection flow. That part is already built, tested, and reused across deals. The buyer should pay for setup and configuration, not a full rebuild.

The custom work starts where the buyer's billing process gets specific. Their billing tool needs HubSpot contacts matched to invoice records with the right billing entity, tax fields, payment terms, and account owner. They also need status rules. If an invoice changes from draft to sent, or from overdue to paid, the sync has to react in a defined way. Retry logic matters too. A failed sync can create duplicate invoices or leave old balances in place.

A clean quote breaks the work into three lines: setup and configuration for the existing connector, custom delivery for invoice mapping, status rules, and retry handling, and ongoing support after go-live.

That split is easier to explain. The reusable part gets a lower, more predictable price. The custom part gets estimated from the buyer's actual billing logic. Support stays separate, so nobody assumes future fixes are included forever.

Sales also needs to say what phase one will not include. In this example, the first phase does not cover full historical invoice backfill, custom reports, changes to HubSpot data structure, or a two-way sync from billing back into HubSpot unless the quote lists it. One short paragraph like that can save weeks of unpaid follow-up work.

Deals like this often close faster because the buyer can see where the money goes. The delivery team gets a scope they can build. If the client later asks for refund sync, dispute handling, or extra objects, the team can quote that as new work instead of absorbing it for free.

Mistakes that shrink margin

Margin usually disappears long before delivery starts. It slips away in the sales call, in a vague quote, or in one casual promise nobody priced.

The first mistake is calling something a "simple integration" before an engineer reviews it. A sync that sounds easy can hide odd authentication rules, missing API fields, rate limits, broken docs, or manual steps the customer forgot to mention. Once sales uses the word "simple," the customer expects a small bill and a fast finish.

Another common leak is hiding custom scripts inside a flat onboarding fee. That fee should cover setup, basic configuration, and handoff. It should not absorb one-off mapping logic, data cleanup, exception handling, or special admin tools for one customer. When teams mix reusable work and custom work into one line item, they lose track of effort and train customers to expect extras for free.

Scope also grows when the quote promises "all objects" even though the customer only needs two. If they need contacts and invoices, do not quietly include products, refunds, subscriptions, notes, and attachments. Broad scope sounds generous in the moment. It turns into weeks of edge cases later.

Costs people forget

Some costs do not look like build work, but they still eat time. Security questionnaires, review calls, waiting for sandbox access, user training, production cutover support, and bug triage after launch all pull people into the deal. They often pull senior people in too, which makes them expensive faster than teams expect.

Post-launch fixes create another margin problem. Teams often label them "cleanup" and do them for free. That only makes sense when the issue is your defect and it sits inside a short warranty window. If the customer changes field rules, adds a new workflow, or asks for better error handling after go-live, that is new work.

A small rule helps: write down what the customer will use on day one, who approves changes, and what counts as support versus project work. Teams that keep that line clear waste less time arguing after launch, and their quotes stay closer to reality.

Quick checks before you send the quote

Most losses start before anyone writes code. The quote goes out with vague words, sales hears one thing, engineering means another, and the team ends up doing unpaid work.

The first check is simple: split the reusable part from the one-off part. If you are building a connector your team can use again, price that separately from the custom mapping, rules, and edge cases for this client. When those pieces get mixed together, margin disappears fast.

Before you send anything, review the quote against this short list:

• separate reusable work and custom work into different line items
• put hard limits on objects, actions, events, reports, and environments
• write assumptions in plain language, including who provides access and sample data
• move anything outside the approved scope into a change request
• make sales and engineering approve the same written scope

A small detail often saves a lot of money: define the starting condition. If the client has clean data, active credentials, and a test account, the work is one thing. If your team has to chase missing access, fix broken records, or guess business rules, the work is bigger and the quote should say so.

One last test works well. Hand the quote to someone who was not in the sales call. If they cannot tell what is included, what is capped, and what triggers extra fees, the scope is still too loose. Ten extra minutes before sending can save weeks of rework later.

Next steps when your team keeps underquoting integrations

Start with a small audit, not a new pricing model. Pull your last three integration deals, then mark every task as either reusable connector work or custom client work. Most teams learn the same thing fast: they sold a connector once, then quietly paid for the custom mapping, testing, edge cases, and support around it again and again.

Write down what repeated across all three deals. If your team keeps building the same auth flow, field mapping pattern, sync job, retry logic, or admin settings, that work probably belongs in the connector. If the work changes because one client has odd business rules, old data, or approval steps, keep it in custom scope.

Then clean up the next quote. Move repeated tasks into a standard connector feature list. Remove vague promises from sales notes and proposals. Make custom requests trigger a separate estimate. Record who can approve scope changes after the deal closes.

Sales also needs a one-page scope sheet. Keep it plain. It should say what the connector includes, what always counts as custom work, what assumptions pricing depends on, and what sales cannot promise without delivery approval.

That one page prevents a common mess: sales says "simple integration," delivery finds six systems and two approval chains, and margin disappears by week two. If a rep cannot answer the scope sheet before quoting, they should not quote yet.

If pricing, delivery, and product keep pulling in different directions, an outside review can help. Oleg Sotnikov at oleg.is works with startups and smaller companies on technical scope, product architecture, and Fractional CTO support, which can be useful when integration estimates keep missing the mark.

Perfect pricing is not the goal. A quoting process that gets less wrong each month is. When more repeat work moves into a connector you can price on purpose, services stop eating the deal.