Quoting an automation project you have not built before.

A client asks for something involving an API, a CRM and a handful of automated steps. They want a number by Friday. You have not built this exact thing before, and the honest answer is that nobody could price it accurately yet.

Most agencies resolve that tension in one of two expensive ways. They pad the number until it feels safe and lose the work, or they guess low, win it, and absorb the difference for six weeks. Both are avoidable. The price is not the hard part. The unknowns sitting behind the price are.

What the client describes is never what you have to build.

A client request arrives as an outcome. “When someone fills in the form, put them in the CRM and tell the sales team.” That sentence contains almost no information about cost.

The cost lives in the layer underneath it, and that layer is discoverable in an hour or two of questions.

What the client says	What you have to find out before pricing it
Put them in our CRM	Which CRM, which plan, and whether API access is included at that tier
Tell the sales team	Slack, email or a task inside the CRM, and who decides the recipient
Check if they are already a customer	Which field is the match key, and how dirty the existing records are
Add company information	Which data provider, whose account, and who pays for the credits
It should be automatic	Whether a human approves anything, and what happens when they do not
Same as what we do manually today	Whether anybody has ever written the manual process down

Every row is a question with a short answer. Together they routinely move an estimate by a factor of two or three, which is exactly the range most agencies are trying to guess their way across.

Five things that reliably break a fixed price.

These are the recurring ones. They are not exotic, and none of them is visible from the client’s description alone.

Undocumented APIs

The vendor has a developer page. It documents the read endpoints thoroughly. The write endpoint you actually need is described in a changelog entry from two years ago, behaves differently in sandbox and production, and returns a 200 with an error in the body. You cannot know this in advance. You can find out in an hour.

Rate limits

A workflow that runs fine for one lead at a time falls over on the first bulk import. Limits are often per minute, per day and per account simultaneously, and the daily one is frequently undocumented. If the project includes migrating existing records, the limit is not an edge case. It is the schedule.

Legacy data

Deduplication sounds like a small feature until you look at the existing records. Two thousand contacts, some with the company in the name field, some with three variations of the same domain, a few hundred with no email at all. Cleaning that is real work, and it is work the client believes they are not paying for.

Hidden approvals

Halfway through the build somebody mentions that the sales director wants to review anything above a certain value before it reaches the CRM. That is not a small change. It turns a linear workflow into one with a pause, a state to store, a notification, a timeout and a path for what happens when nobody responds.

Credential access

You cannot estimate integration work you cannot log into. Getting API keys for a system owned by the client’s IT provider can take longer than building the integration. Ask who holds the credentials in the first conversation, not the week you plan to start.

Structure the quote so discovery is paid and bounded.

The mistake is treating discovery as something you absorb to win the work. It is the part of the project that removes the most risk per hour spent, and it produces something the client keeps regardless of what they decide next.

Quote it as a small, fixed, separate piece. A short technical scope with a defined deliverable: the systems involved, the endpoints that will be used, the failure cases that need handling, the data that has to be cleaned first, and a build estimate you are willing to stand behind.

Three things follow from that.

The client gets a real number instead of a padded one, because you are no longer pricing uncertainty. You get paid for the work that was previously free. And if the answer turns out to be that the integration is not viable at a sensible budget, everyone finds out for a small sum rather than a large one.

Six questions to ask before you send a number.

Ask these before quoting anything you have not built before. They take one call.

1. Which specific systems are involved, including plan or edition, and does the client already pay for API access on each?
2. Who holds the credentials for each system, and how long will it take to get them?
3. What is the volume today, and what is it at peak? Is there a historical backlog to migrate?
4. What is the match key that decides whether two records are the same thing?
5. Does a human approve, review or intervene at any point in the process?
6. What should happen when a step fails? Retry silently, alert somebody, or stop and wait?

The last two are the ones agencies skip most often, and they are the two that most often turn a two-week build into a five-week one.

What a defensible estimate looks like.

A number you can defend has three parts: what is included, what is explicitly excluded, and what would change the price.

The exclusions matter more than the inclusions. “Data cleaning of existing records is not included” is a sentence that saves a project. So is “this covers one CRM pipeline, not all four.” Clients rarely object to a clear boundary. They object to discovering one after they have signed.

State the assumptions you priced against, in plain language, in the quote itself. The API allows the operations required. The client provides credentials within a week. Volume stays under a stated ceiling. If any of those turns out to be wrong, you have a reasonable basis for a conversation rather than an argument.

Estimating is a skill you can borrow.

None of this requires you to become an integration shop. It requires an hour with someone who has looked at that API before and knows what it does badly.

If you are about to quote something involving APIs, a CRM or an AI step and you would rather not guess, send us the requirement the way the client sent it to you. We will tell you how we would approach it, which parts carry the risk and what the implementation would realistically involve. A rough description is enough to start, and the contact form is the fastest way through.