Connecting your website to a CRM: what it actually does and how it works

What "CRM integration" means technically

When a visitor submits a form, the data goes to your website's server. From there it can take one of two paths: an email to your inbox, or a request to your CRM's API that creates a lead or a deal. Integration is the second path.

The mechanics are simple. The site assembles a package of data - name, phone, message, where the person came from - and sends it to the CRM over a secure channel. The CRM confirms receipt and returns a deal ID. If it doesn't confirm, the site needs to notice and hold on to the enquiry.

That last point is what separates a proper integration from one built in a hurry. The CRM can be unreachable for a minute, a token can expire, an account can hit its request limit. With no handling for those cases, the enquiry simply disappears - and you never find out.

What you get beyond saving your team some typing

Skipping manual entry is the most obvious win, but not the most valuable one. What matters more is the data that arrives alongside the enquiry - data nobody would ever retype by hand.

• Source of the enquiry: which page the person came from, which ad tag brought them. A month later you can see which channel produces deals and which one only produces clicks.
• The exact time the enquiry arrived. That gives you a basis for a "call back within X minutes" rule, and a way to check whether it's actually being followed.
• Duplicates. The CRM recognises that this phone number already contacted you in March and doesn't create a second record, so the client's history stays intact.
• Automatic routing: enquiries from a particular city or about a particular service go straight to the right person.

When you don't need it

If you get five enquiries a month and one person handles them, integration won't pay for itself. Email and a spreadsheet will cope, and you can spend the budget on something that actually brings enquiries in.

If you haven't chosen a CRM yet, or the process inside it isn't defined, there's nothing to integrate with. First work out which fields you fill in, which stages a deal moves through, and who owns what. Otherwise enquiries land in the CRM and sit there as dead weight - you've just moved the mess from your inbox into another system.

And honestly: if your pain is "the team doesn't call people back in time", integration won't fix it. It will give you the data to see the problem, but the discipline is a separate piece of work.

What the work looks like from the developer's side

The first step isn't code, it's a conversation. We need to know which fields exist in your CRM, which are required, what counts as a lead versus a deal, and which stage a new enquiry should land in. This is usually where it comes out that half the fields in the CRM are never filled in by anyone and can be left alone.

Then the connection gets set up: an app or access key in the CRM, server-side code on the website, and a mapping between form fields and CRM fields. We do this in Node.js and send from the server, so keys never reach the browser and can't be pulled out of the page source.

Failure handling is its own piece of work. The enquiry is saved in the site's own database until the CRM confirms it, the send is retried on error, and if it fails outright you get a notification rather than silence. Keeping a duplicate email notification for at least the first few weeks is worth it.

Testing before handover isn't "the form submitted". Send a test enquiry from your phone, go into the CRM and check: the record was created, the fields are filled, the source is recorded, an owner is assigned, and a second submission with the same phone number didn't create a duplicate.

What to ask before you pay

These questions separate someone who has built integrations from someone who read the documentation yesterday. Ask them in writing so you can reread the answers.

• Where does the enquiry go if the CRM doesn't respond at that moment? "That doesn't happen" is a bad answer.
• Exactly which fields will be filled, and where does the campaign tag end up? Ask for the field mapping list before work starts.
• Where will the access keys be stored, and who has access to them after the project is handed over.
• How can I check for myself that the integration is working: is there a log of sends, and where does an error notification go.
• What happens if I switch CRMs or add a field to the form - is that a support task or a new project.
• Who handles configuration on the CRM side: the pipeline, permissions, owners. Often that's outside the developer's scope, which is fine - but better to know upfront.

What it costs and what drives the price

The range is wide, and it depends on the number of scenarios rather than on which CRM you use. One form, four fields, a mainstream CRM with a documented API - that's a few hours of work. Five forms, a cart, payments, and order statuses travelling from the CRM back to the site - that's a project in its own right.

Budget separately for support. APIs change, tokens expire, you add a service and a new field with it. An integration isn't a one-off setup, it's a moving part.

On efimovdev.ru we publish starting price ranges by service - websites, online stores, Telegram bots, automation, support. CRM integration usually comes as part of a website build or as a standalone automation task; we quote precisely after a brief, once it's clear which CRM you have and how many scenarios you need. You'll discuss the work directly with the person running the project.