The product
Five parts,
and no seams between them
Most CRMs are a database with a form in front of it, and the conversation happens somewhere else entirely — in a mailbox, a phone, a chat widget with its own little inbox that nobody has opened since March. iKonekt starts from the conversation and works outwards.
One inbox, every channel
Chat, forms, the reach-me widget, call-me, e-mail, phone and a QR code on a paper flyer. Eight doors, one room, and every arrival labelled with the door it came through.
Assignment on arrival
An owner in the first second, by rule, territory or rota. The shared mailbox — that famous retirement home for promising leads — does not exist here.
One thread, notes included
Every channel a customer has ever used, in one history, with internal notes in the same place and a private flag that genuinely holds.
A pipeline that reaches the invoice
Landed, assigned, in conversation, quoted, booked and paid, invoiced. Same record the whole way, so nobody retypes an address for the fourth time.
Separation the database enforces
Multi-tenant from migration one. Several brands, one install, and a boundary that holds even against a query written at five to five on a Friday.
And the part you do not see
Underneath all five sits castomAPI — the same account, the same wallet and the same infrastructure as every other product in the family. It is why the connectors are short.
How the five fit
Each one exists
because the one before it created a problem
This is not a feature list assembled by a committee with a whiteboard. Read in order, each part is the answer to the mess the previous part would otherwise make.
Catch everything in one place, and within a week you have a magnificent pile. Volume without ownership is just a louder version of losing things, so assignment has to happen on arrival — not when somebody feels moved to reply.
Give everything an owner, and the owner immediately asks the only reasonable question: what has this person already been told? Hence one thread per customer, across every channel, including the awkward parts. A seller who has to guess will guess confidently and wrongly, which is worse than not guessing.
Put the whole history in one thread, and the thread starts wanting to finish something. A conversation that ends in "great, send me the details" and then evaporates is not a conversation, it is a hobby. So the record carries on into quote, booking, payment and invoice without ever being copied into another system.
Carry a record that far, and it now holds names, numbers, prices and payment details — which is precisely when "we filter by company in the application layer" stops being an acceptable sentence. So separation moved down into the database, where a forgotten WHERE clause cannot undo it.
The honest version: each of those problems was discovered in the order written above, by people who thought they had finished the previous step. The tidy narrative is retrospective. The code is not.
What it is not
Three things iKonekt deliberately will not do
A product page that only lists strengths is a product page nobody believes. These are choices, and they are permanent ones.
It never sends a cold message
iKonekt answers, follows up and reminds. It does not start conversations with people who never asked for one. That rule is older than this product and it is not configurable, which has cost us at least one interesting meeting.
It does not score your customers
No mysterious number between 0 and 100 telling a seller who deserves attention. The thread is the evidence. If a lead is worth chasing, a person can see why in about nine seconds.
It does not replace your other tools
clickSomo keeps the messaging automation, FABLS keeps the publishing, your accountant keeps the accounting. iKonekt holds the conversation and the customer record. Everything else stays where it already works.
Start with the inbox.
The rest follows from it.
Connect one channel, watch where it lands, and add the next when you are bored of being impressed.
Open the console See it by the shape of your business