Integrating your product with a CRM: what to check first

You have a product that works, and around it sit the systems the team opens every day: a CRM, a telephony provider, an accounting service, a payment gateway, a reporting API. Someone asks you to connect them. The first estimate counts endpoints and fields.

Almost nothing in that estimate is the work. An integration fails months later, and when it fails it is rarely the API call. It is a decision nobody took: who owns the record once both sides have it, what happens when the far side is down for four minutes, whether a retry creates a second row, whether the person who has to see a failure can see it, and which side is the source of truth when they disagree. Those five decisions are cheap before the first request. In the second invoice they are the most expensive line you have.

I have connected telephony, messaging and accounting services into one product, built platform-specific integrations for an online store, moved reporting APIs and background jobs between services, and written an AI result into a CRM as a card. The pattern is the same each time. The connection is the small part. The decisions are the work.

1. Who owns the record once both sides have it

Once both sides hold the record, two people can change it. A manager corrects a phone number in the CRM at nine in the morning. Your job overwrites it at midnight with the value it read in March. Neither side is broken. Both are following a rule nobody wrote down.

Write the direction of every field before you write the client. Which side creates the record. Which side may update which fields. What happens when both sides can write the same field, because last write wins is a rule too, and it should be chosen rather than inherited.

The field map in what a form-to-CRM copy actually moves is the same exercise from the other end: one row per value, one owner per field, and the judgments a person adds on the way.

Deletion is the part teams skip. If a manager archives a card in the CRM, does your product keep writing to it? If your product deletes a row, does the CRM follow? Answer both in one line each, before the first request.

A useful check: take the ten fields the integration will carry and name the side that owns each one. If two names sit on the same line, that line is where the first argument happens.

2. Four minutes of downtime is a design input, not an accident

The far side will be down. Not for a week, usually: for four minutes, in the middle of an order, on a Tuesday. That is not an edge case you discover in production. It is a normal property of any system you do not own.

Decide what your product does in those four minutes. Fail the request and tell the person what to do. Queue the work and send it when the far side returns. Or hold the request open until it times out, which is also a decision, just a slower one.

Then decide who reads the queue. A backlog nobody reads is the same failure at a slower speed. Name the person, the interval, and the depth at which they stop waiting and call someone.

Test it where it costs nothing: turn the far side off for four minutes and run one real order through. Write down what the person at the keyboard saw, and what is waiting in the queue when it comes back.

3. A retry must be safe before it is fast

A timeout does not tell you the far side did nothing. It tells you that you do not know. Networks retry. A background job runs twice after a deploy. A person hits refresh because the page looked stuck.

So the first question about a request is not how fast it returns. It is what happens when it is sent twice. If the answer is a second row, you will spend the second invoice cleaning duplicates out of a list the team has stopped trusting.

Give every business event one identifier the far side already knows: an order number, a call id, a phone number with the country prefix already normalized. Then make the write conditional on that identifier. One event, one row, even when the delivery happens twice.

This is the rule that keeps a note on a card as one note when the same call arrives twice, the shape an AI result written into a CRM card was built on.

Test it deliberately. Send the same payload twice, with a delay between the sends, and count the rows. If you get two, you have found the expensive part early, while it is still one function to change.

4. A failure nobody can see is a failure nobody fixes

Somewhere in the path a request gets rejected, a token expires, or a job dies halfway. The site still shows success, because the site finished its own step. The failure sits in a log nobody opens.

Decide who has to see it, where, and what they can do about it. An alert in a channel the team already watches beats a file on a disk. A row that says "not sent" next to the record beats a stack trace.

Decide what a person can do once they see it. Rerun one record without replaying the whole night. Correct one field and send again. If the only remedy is a developer and a console, the failure waits for a customer to mention it.

The same gap shows up as an empty pipeline: why a lead can vanish after a thank-you page is the check for the moment the site and the record disagree.

Test: break one thing on purpose, where it costs nothing, and see who finds out without being told. If nobody does, you have found the real work.

5. When the two sides disagree, one of them is right

Both systems hold a value for the same field, and the values differ. A price changed in the accounting system. A manager corrected a phone in the CRM. Your product still holds what it read this morning.

Source of truth is a per-field answer, not a per-system one. The accounting system owns the amount. The CRM owns the stage and the owner. Your product owns what it collected at the source. Write that table down, because whichever wrote last is also a rule, just an unreadable one.

Reports show the disagreement first. A report that reads both sides without knowing which one wins will show two numbers for the same day, and the team will stop opening it.

Check: change a value on one side on purpose, run the sync, and see which value survives. If that surprises anyone in the room, the rule does not exist yet.

6. What to write down before the first request

None of this needs a prototype. It needs one page, written before the first request, that two people can read in five minutes: the owner of each field, the answer for four minutes of downtime, the identifier that makes a retry safe, the person who sees a failure, and the winner when the two sides disagree.

• One owner named for each field, including the ones both sides can write.
• The answer for four minutes of downtime: fail, queue, or wait, plus who reads the backlog.
• The identifier that makes a second send of the same event safe.
• The person who sees a failure, the place they see it, and what they can rerun.
• The side that wins when the two systems disagree, decided per field.

Hand that page to whoever writes the first request, and to whoever will be paged when it breaks. If a line cannot be answered yet, that is the finding: the open question is the estimate, and it is cheaper to close it now than in the second invoice.

Services cover this kind of connection on the systems you already run. Selected work shows the same decisions next to a result on a product that runs. If you want it traced properly, ask for product integration, or write to me with the page you just filled in. Leave passwords and customer data out of the message.