Inom castomo-familjen
Där kunden slutar vara åtta kunder
Om du redan använder dash-b, castomo, clickSomo eller FABLS har du stött på det moderna integrationsproblemet: allt kopplas till allt, och samma människa hamnar till slut finnas åtta gånger, stavade lite olika, på åtta ställen som alla tror sig vara auktoritativa.
Det vanliga botemedlet är ett synkroniseringsjobb, vilket är en maskin vars hela syfte är att få två lögner att hålla med varandra. Det fungerar tills ena sidan redigeras medan jobbet körs — då har du en tredje lögn och ett supportärende.
iKonekt är inte integrerat med familjen. Det är i den. Samma inloggning, samma konto, samma plattform under — så kundposten behöver inte stämmas av mellan produkter, för det finns bara en.
castomAPI under
Plattformsskiktet som alla produkter i familjen körs på: ett konto, en plånbok, en uppsättning tjänster för autentisering, fakturering, betalningar och bokningar. Det är därför kontakterna är korta i stället för heroiska.
clickSomo, åt båda håll
Meddelandeautomatiseringen stannar där den är som bäst — i clickSomo. Det som färdas är samtalet och resultatet, så en sekvens vet när en människa tog över, och en säljare kan se vad en sekvens redan sagt.
FABLS, som matar toppen
Bloggning och sociala medier skapar läsare; läsare skapar förfrågningar; förfrågningar landar här med artikeln som skapade dem registrerad som källa. Loopen stängs utan ett kalkylblad i mitten.
castomUI:s formulär
Sajter och landningssidor genererade av castomUI har formulär som landar här direkt — inte via e-post, inte via en webhook du själv underhåller. Sidan och inkorgen byggdes av samma familj.
dash-b, som tittar
Instrumentpaneler som läser från samma konto, så att siffran på väggen och siffran i CRM inte kan säga emot — en förvånansvärt ovanlig egenskap.
castomo, huset
Kontot du redan har. Om du har loggat in på något i familjen har du loggat in på det här — det finns ingen andra registrering och inget andra lösenord att tappa bort.
Vad "åter ömsesidigt" egentligen betyder
Tvåvägskommunikation är ett slitet ord, så här är den konkreta versionen. En koppling i den här familjen är inte en nattlig export. När clickSomo skickar en sekvens och kunden svarar hamnar svaret i iKonekt-tråden, och clickSomo vet att sluta skicka — för att en människa nu pratar. När en säljare stänger ett ärende här får de produkter som bryr sig om det besked, en gång, i ordning, och kan agera på det.
Funktionaliteten flyttas inte. clickSomo fortsätter vara meddelandeprodukten och iKonekt fortsätter vara konversationen. Det som passerar gränsen är den lilla uppsättning fakta som varje sida verkligen behöver, levererad tillförlitligt nog att ingen av sidorna behöver gissa.
En iakttagelse från att bygga det: det svåra med en integration är nästan aldrig själva sändandet. Det är att komma överens om vad en sak är — om en "kontakt" i en produkt är en "lead" i en annan och en "kund" i en tredje. Att vara en familj betyder att den diskussionen skedde en gång, internt, och inte blev ditt problem.
Ett konto, och en väg ut ur det
Att dela ett konto mellan produkter väcker den berättigade frågan om vad som händer när någon vill att deras data ska försvinna. I den här familjen är en raderingsbegäran inte en postlåderegel — den sprids ut till de produkter som har något, och var och en svarar för sig. Det är betydligt svårare att bygga än ett formulär, och det är därför det är värt att nämna här i stället för i en policy som ingen läser.
Om du redan är i familjen har du redan ett konto här.
Samma inloggning, samma kund, ingen migreringshelg och inget synkroniseringsjobb som i tysthet hittar på en tredje version av sanningen.
"Så vi skulle behöva synka den med allt annat."
Det finns inget att synka.
Ett konto i hela familjen, en kundpost under det. Ett synkroniseringsjobb är en maskin vars hela syfte är att få två lögner att stämma; det här har en sanning i stället.
Se plattformen →