Inside the castomo family
Where the customer stops being eight customers
If you already use dash-b, castomo, clickSomo or FABLS, you have met the modern integration problem: everything connects to everything, and the same human being ends up existing eight times, spelled slightly differently, in eight places that each believe they are authoritative.
The usual fix is a synchronisation job, which is a machine whose entire purpose is to make two lies agree. It works until one side is edited during the run, at which point you have a third lie and a support ticket.
iKonekt is not integrated with the family. It is in it. Same sign-in, same account, same platform underneath — so the customer record does not need reconciling across products, because there is one of it.
castomAPI underneath
The platform layer every product in the family runs on: one account, one wallet, one set of services for auth, billing, payments and bookings. It is the reason the connectors are short rather than heroic.
clickSomo, both ways
Messaging automation stays where it is good — in clickSomo. What travels is the conversation and the outcome, so a sequence knows when a human took over, and a seller can see what a sequence already said.
FABLS, feeding the top
Blogging and socials produce readers; readers produce enquiries; enquiries land here with the article that produced them recorded as the source. The loop closes without a spreadsheet in the middle.
castomUI's forms
Sites and landing pages generated by castomUI carry forms that land here directly — not by e-mail, not by webhook you maintain. The page and the inbox were built by the same family.
dash-b, watching
Dashboards that read from the same account, so the number on the wall and the number in the CRM cannot disagree — a surprisingly rare property.
castomo, the house
The account you already have. If you have signed in to anything in the family, you have signed in to this — there is no second registration and no second password to lose.
What "both ways" actually means
Two-way is an overused word, so here is the specific version. A connector in this family is not a nightly export. When clickSomo sends a sequence and the customer replies, the reply is on the iKonekt thread, and clickSomo knows to stop sending — because a human is now talking. When a seller closes a job here, the products that care are told, once, in order, and can act on it.
The functionality does not move. clickSomo keeps being the messaging product and iKonekt keeps being the conversation. What crosses the line is the small set of facts each side genuinely needs, delivered reliably enough that neither side has to guess.
An observation from building it: the hard part of an integration is almost never the sending. It is agreeing what a thing is — whether a "contact" in one product is a "lead" in another and a "customer" in a third. Being one family means that argument happened once, internally, and did not become your problem.
One account, and one way out of it
Sharing an account across products raises the fair question of what happens when someone wants their data gone. In this family an erasure request is not a mailbox rule — it fans out to the products that hold anything, and each answers for itself. That is a good deal harder to build than a form, and it is the reason it is worth mentioning here rather than in a policy nobody reads.
If you are already in the family, you already have an account here.
Same sign-in, same customer, no migration weekend and no synchronisation job quietly inventing a third version of the truth.
“So we would need to sync it with everything else.”
There is nothing to sync.
One account across the family, one customer record underneath it. A synchronisation job is a machine whose whole purpose is making two lies agree; this has one truth instead.
See the platform →