A request for CRM integration services reads the same from almost every buyer: connect the CRM to the other systems we run. Vendors answer with a price and a list of connectors. What the price hides is that "integration" names three different jobs, and the three are scoped, built, tested and run in different ways. Buy one while expecting another and the project can pass its acceptance test and still fail the business.
We separate the jobs before we quote anything. Here is how, and the questions that tell you which one a statement of work really describes.
Sync copies a value from one system to another when something changes or on a schedule. A new contact appears in the CRM and in the marketing tool. A deal's stage appears next to an order. Success means the same value sits in both places. It needs a field map, a shared key and a direction, and its failure is quiet: the two values disagree and nobody is told.
Orchestration runs a multi-step process that crosses systems and keeps track of where each case stands. A quote is accepted, an order is created, an invoice is raised, a payment is posted back to the deal. Success means the process either completes or stops visibly at a named step. It needs state, an order of operations and a rule for what to undo when step three fails after step two succeeded.
Agent action handles the step where the right move is not fixed in advance. An order arrives without shipping terms, and someone has to read the quote history, decide what the customer most likely meant and ask the right question. An agent can do that reading and propose or take the action, inside permissions and limits set by people. It needs boundaries, an audit trail and a human gate where the step cannot be undone.
The three build on each other. Orchestration needs reliable sync underneath it. An agent needs reliable orchestration around it, because it acts on whatever record it is handed.
Most statements of work are written for sync. They list the fields, the schedule, the systems and a test with a handful of sample records. The buyer, meanwhile, is expecting orchestration: when a deal closes, the order and the invoice appear and nothing falls through.
Those are not the same promise. Sync moves the deal-stage field. It does not create the order, and it has no opinion about an order that arrives with a blank where the shipping terms belong. The order system may accept it, hold it in a draft, or reject it, and in none of those cases does a person find out unless someone built the place where they would find out. The distance between a field arriving and a process completing is most of the difference in price between a cheap integration and a good one, and the cheap one is invoiced as if it were the same product.
You do not need to read a mapping document to find out which job you are buying. Ask the vendor three things and listen for places and owners, not adjectives.
If the second system is down for an hour, what happens to the changes made in the first during that hour, and who sees that they are waiting?
If a person reverses an edit in the first system, what happens in the second, and which side wins if both were edited?
Where does a person look to see everything that is stuck right now, and who looks at it each morning?
A sync answers the first with "it retries" and the second with a winner rule. An orchestration answers all three with a queue, a state and a named owner. If the answer to the third question is "the logs", the process has no owner yet. We wrote about the second question at length in why a two-way sync is usually a design failure: the honest answer is that someone decided which system owns the value.
Sync is cheap to run and quiet when it breaks, which is its own cost. A mapped field that stops arriving looks like a missing value, not a failure, and it is often found when a report disagrees with a customer.
Orchestration costs more to run because it has something to watch: a list of cases that did not finish, a clock on each, and someone whose job includes clearing it. That is the work that turns an integration from a build into a managed asset, and it is the first thing dropped when the project closes.
Agent action costs the most in governance rather than in effort. It needs a boundary around what the agent may read and change, a record of what it did and why, and a gate before anything that spends money or leaves the company. The distinction between a workflow that merely phrases a choice and a system that makes one is covered in agentic automation against workflow automation.
Imagine a 60-person company that closes about forty deals a month. A sync copies the deal stage into the order system. Three deals a month reach the order system with no shipping terms, because the field is optional in the CRM and mandatory in the order system. The orders sit in draft. Nobody is told, and the shortfall appears three weeks later when the invoice run misses them.
Now add orchestration. The same three deals land in a queue named "needs shipping terms", each with an owner and a two-day clock. They show on a list on day one, and the cost of the gap is a short email instead of a missed invoice.
Now add an agent for that queue alone. It reads each quote, proposes the terms the customer used last time, drafts the question to the account owner with the proposal attached and waits for a yes. The people still decide. They decide from a drafted answer, not a blank screen.
Each layer was worth buying. Each was only worth buying on top of the one beneath it.
Use sync where a stale value is cheap: a contact's job title, a newsletter preference. Use orchestration where a missed step costs money or breaks a promise: orders, invoices, renewals, onboarding. Use an agent where exceptions are frequent and each one follows a pattern that a person already handles from notes and habit.
Do not buy an agent on top of a sync you do not trust. An agent acting on the wrong record is a faster way to be wrong, and the work that makes the layer worth having is the integration work underneath it, as we argued in what changes when the system acts on the record.
List your current integrations on one page. For each, write three things: which of the three jobs it is doing, who is told when it fails, and where a person can see what is stuck. Mark every row where orchestration was expected and sync was built. Those rows are next quarter's incidents, and you can find them this afternoon without spending anything.
We start with a no-risk discovery: we map your integrations by the job each one does, show where a sync is carrying the weight of a process, and you pay for the discovery only if you go on to the build. A build comes with a guaranteed estimate, so if we estimate low, we absorb the difference. After go-live, Managed Technical Operations keeps the stuck-case list watched and the failure owners named, which is the part of an integration that stays valuable after the project ends.
Name the job before you sign the scope, and the price will mean something.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
