CRM

The lead filled in your form ten minutes ago. Salesforce finds out tomorrow morning

A prospect fills in a contact form at nine in the evening. It arrives as an email to sales@, sits in an inbox overnight, and gets forwarded to an account manager the next morning. By the time anyone calls, the prospect has already had a demo with a competitor who answered within the hour.

Salesforce did not cause that delay. The form was never talking to Salesforce. It was talking to an inbox, and an inbox is not a CRM, no matter how disciplined the person reading it is.

  • REST API and Bulk API, with OAuth 2.0
  • Leads, Accounts, Opportunities, orders
  • From €1,700 plus service fees
The tool

What Salesforce is, and where the API access actually sits

Salesforce is the largest CRM platform in the world, built around a small set of core objects — Leads, Contacts, Accounts, Opportunities, Cases — that almost everything else in the platform hangs off. Sales Cloud handles the pipeline, Service Cloud the support cases, and on top of both sits a genuinely deep customisation layer: custom objects and fields, Apex triggers, Flow automations, validation rules that can reject a record your integration just tried to create.

The detail that catches people out first is licensing. API access is included from Enterprise edition upward; on Professional edition it is a separate paid add-on, and on Essentials it is not available at all. We ask which edition you are on before we quote anything, because a project scoped assuming API access, discovering in week two that Professional needs the add-on purchased and provisioned first, is a two-week delay hidden inside what looked like a two-day task.

Salesforce also gives you sandboxes — Developer, Developer Pro, Partial Copy, Full — so a connection can be built and tested against a copy of your real data and org configuration before it ever touches production. We always insist on this where a sandbox exists: Apex triggers and validation rules that run automatically on record creation can silently reject or transform what an integration sends, and the sandbox is where you find that out safely.

What goes wrong

Three things that go wrong between a website and Salesforce

Not hypotheticals. These are the three we walk into most often when a sales team already runs Salesforce and the website was never told.

The lead cools down in an inbox before it becomes a Lead

Response time is the single biggest predictor of whether a web lead ever becomes a customer, and a form that emails sales@ instead of calling the API adds hours by default. Nobody decided this on purpose; the form was built before Salesforce was, and nobody has revisited it since.

What you see instead

The form posts straight to the REST API as a Lead, with UTM parameters and the page it came from in custom fields. Salesforce's own assignment rules fire immediately, and the owner is notified within a minute, not a morning.

The same person exists twice, and sales calls them twice

A returning customer fills in a form and becomes a brand new Lead, unrelated to the Contact already sitting under an Account with a year of Opportunity history. Two records, two follow-ups, and a customer who has to explain who they are to someone who already has their file.

What you see instead

The form checks for an existing Contact by email before creating anything, and routes a match to the owning Account instead of spawning a duplicate Lead. Sales sees one record with the full history, not two half ones.

The order and the Opportunity disagree about what happened

A webshop or a portal shows an order as paid and shipped. The Opportunity in Salesforce still says "Quote Sent", because nothing ever told it otherwise, and an account manager calls a customer to check on a quote that was accepted and delivered two weeks ago.

What you see instead

The order status pushes the Opportunity stage forward automatically, through the API rather than a person remembering to click a dropdown. The pipeline reflects what actually happened, on the day it happened.

The bill for doing it by hand

What a shared inbox in front of Salesforce costs you

Take a business getting 200 web leads a month through a form that emails an inbox rather than calling the API. Somebody checks that inbox two or three times a day, copies the details into Salesforce as a Lead by hand, at roughly three minutes per lead once you count finding the right owner. That is 10 hours a month of pure re-typing, before anyone has actually sold anything.

The response-time cost is larger and less visible. Studies on lead response consistently show conversion dropping sharply after the first hour, and a form-to-inbox-to-CRM chain routinely takes longer than that. If even one extra lead a month converts because it reached a rep in minutes instead of the next morning, and your average deal is worth anything above a few hundred euros, the connection has already paid for itself.

  • 200 leads a month, three minutes of manual entry each: 10 hours a month of retyping.
  • A lead answered the next morning instead of within the hour, and the conversion that goes with the delay.
  • A duplicate Lead and Contact for the same person, and two account managers who both think they own the relationship.
  • An Opportunity stage that is wrong by two weeks, and the awkward call that comes from trusting it.
What we build

We build the thing on the other end too

With Salesforce the useful first question is which edition and which licences you actually have, because that decides more of what is possible than anything on this page: a project scoped for Enterprise-level API access on a Professional org without the add-on is scoped wrong before it starts.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between Salesforce and your website

Built against a Connected App with OAuth 2.0, so access is scoped and revocable by your own Salesforce administrator, not a shared password. The arrow says which way the data moves.

  • Web form submissions as Leads

    Name, contact details, UTM parameters and the source page, deduplicated against existing Contacts by email before a new Lead is created, with your own assignment rules deciding the owner.

  • Contacts and Accounts

    Matched on email or company domain, kept level between your website login system and Salesforce, with one side named as the owner of a given field so the two stop overwriting each other.

  • Opportunity stage into a customer portal

    A logged-in prospect or customer seeing where their quote actually stands, read straight from the pipeline instead of a status somebody updates when they remember.

  • Webshop or portal orders as Opportunities, or moving an existing one forward

    A completed order can create a closed-won Opportunity for reporting, or simply move an existing one forward so the pipeline reflects what already happened rather than lagging behind it.

  • Support requests as Cases

    A contact form or a portal ticket becoming a Case in Service Cloud with the right record type and queue, so support never has to be told a request exists by a second email.

A first Salesforce project is almost always leads and deduplication, sometimes with the Opportunity or portal row added. Cases and full two-way Account sync tend to be a second phase once the first one has proven itself.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For Salesforce specifically: which edition you are on and whether custom objects are involved move the price more than the flows themselves do. Enterprise and above with standard objects is the straightforward end; heavy Apex customisation or Marketing Cloud in the mix means a longer discovery before we quote.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Salesforce

API access is included from Enterprise edition upward. On Professional edition it exists as a separate paid add-on your Salesforce admin has to enable; on Essentials it is not available at all, and no integration can create it.

We check this in the first conversation, because it is the single fact most likely to move a timeline. If the add-on has to be purchased and provisioned first, that is a conversation with your Salesforce account team, not with us, and it should happen in parallel with the build rather than before it starts.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan