It looks like you’re from {country}
Communication
A new lead, a failed payment, a support ticket nobody has picked up: Slack is often the fastest way to get that in front of a person, because the person is already there. Nobody has to open a dashboard to see it — the message is the dashboard.
The failure mode is exactly as fast to reach. Connect every event a system can produce and the channel that used to matter becomes the channel with four hundred unread messages, and the one order that actually needed a human is buried under forty that did not.
An incoming webhook is the simple route: a URL that posts plain text or a basic card into one channel, no approval process, live in an afternoon. Right for a single alert nobody needs to act on from inside Slack — a deploy finished, a form was submitted.
A real Slack app is worth the extra setup once a message needs to do something. Block Kit lets it carry fields — customer, amount, order number — plus buttons: approve, assign, snooze, open in the CRM. Slack itself is owned by Salesforce, which is why a Salesforce-plus-Slack flow is one of the more common pairs we build: a deal update, with an 'open in Salesforce' button already on it.
All three come from the same instinct: connecting more than the one decision that actually needed a message.
A well-meaning setup posts every order, ticket and form submission into one channel. Within a week it is 200 messages a day; within a month somebody has muted it, and the failed payment needing a same-day reply sits unread next to nine order confirmations.
What you see instead
One channel per decision a person actually makes: a #failed-payments channel with five messages a week, each worth opening, rather than one channel with all of it.
'New order received' with no amount, no customer and no link creates a second task: go find out what it means. Multiply that by fifty messages a day and the channel does less than a plain email would.
What you see instead
The message carries the record — customer, amount, order number — and a button that opens or acts on it directly. Nobody switches tabs to find out what it was about.
Once a channel has taught people that most messages are noise, they stop reading closely — including the day the payment gateway actually goes down. The connection did its job every time; the habit it built made the important message invisible.
What you see instead
A threshold decides what becomes a message at all — a payment failure, not every payment; three failed retries, not the first. Everything under it goes into a daily digest instead.
The arithmetic runs the opposite way from most tools in this bank: the cost is not the retyping Slack saves, it is the reading time a badly designed channel adds. At 150 messages a day and ten seconds each to glance at and dismiss, that is 25 minutes a day per person watching it — over one hundred hours a year, spent reading messages that asked for nothing.
Set against that: a webhook connection is cheap to build, usually a day or two rather than a week. The honest question is not whether this is worth building — it almost always is — but whether it is worth building as its own project, and for most clients it is not: it rides along with a CRM or helpdesk connection that was happening anyway.
A Slack connection is rarely the whole project: it is usually the last, cheap step on a CRM, helpdesk or webshop connection that already decided what counts as worth a message.
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.
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.
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.
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.
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.
Almost everything below is 'in' — an event becoming a notification. The 'out' row is a button changing something back in the source system, and only a real Slack app can do it.
New leads or deals above a threshold (into the tool)
A deal above a set value, or a lead from a specific form, with the customer name, value and a link to the CRM record — not every lead, only the ones a salesperson should see today.
Failed payments and failed orders (into the tool)
The payment or order that did not go through, with customer, amount and reason, so somebody can follow up the same day instead of in a monthly report.
Support tickets that crossed a wait-time threshold (into the tool)
Not every ticket — the ones open longer than an hour with nobody assigned, so a quiet queue is visible before a customer complains about it.
Buttons that act from inside the message (out of the tool)
Approve a refund, assign a ticket, mark a lead as contacted, using Block Kit, writing the result back to the source system through its own API.
A daily digest for everything under the threshold (into the tool)
Order counts, form submissions, minor stock changes — worth knowing in aggregate, not worth forty separate pings.
Which of these earns a channel is a decision worth making before the connection is built, not after the first week of complaints about noise.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A Slack notification is usually the cheapest connection in this bank on its own, and cheaper still when it rides along with the CRM or helpdesk connection that decides what it sends: budget the lower end of the range, or nothing extra at all if it is one output of a bigger project.
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.
For a one-way notification with no buttons, an incoming webhook is enough and is live within a day. A real Slack app becomes worth it the moment somebody needs to act from the message — approve, assign, snooze — because that requires Block Kit and its own OAuth scopes, which a plain webhook does not have.
The two are not a big price difference in our experience; the decision is really about whether the message should do something or only say something.
Both. An incoming webhook is tied to one channel, public or private, chosen when it is created. A real Slack app can post into any channel it has been invited to, which matters when the recipients differ per topic — finance sees payment failures, sales sees deals, and neither sees the other's channel.
What we would push back on is a single private channel with everything in it for 'security' reasons: that is the alert-fatigue problem with an access-control label on it.
Often, yes — Slack and Salesforce are owned by the same company and the two are built to work together, so a deal stage change, a new opportunity or a support case can post to a channel with a button that opens the record directly. It is one of the more common pairs we get asked for.
It is still worth applying the same discipline: which stage changes actually need a message, not all of them, or the Salesforce feed becomes exactly the noisy channel described above.
It queues and is sent once Slack is reachable again, the same as any other connection we build — Slack's own uptime is good but not perfect, and a message that silently disappears during an outage is worse than a late one.
For anything time-sensitive we would add a second channel outside Slack — email or an SMS alert — because a single notification channel is itself a single point of failure, however unlikely it is to fail.
