ConnectWizin integraatiot
Teknologiapinosi kytkettynä – ja kuvattuna sillä, mitä se oikeasti tekee.
Integraatiosivut listaavat yleensä logoja. Tämä listaa käyttäytymistä: mikä synkronoituu, mihin suuntaan, kenen omistuksessa ja missä rehelliset rajat kulkevat. Koska ”integroituu X:n kanssa” on väite syvyydestä, ei tarra.
Commerce
WooCommerce ja WordPress
WooCommerce – kaksisuuntainen ja hallittu
Paritus yhdellä klikkauksella, syvä tuotetuonti ja oikea takaisinkirjoitus – valitsemallasi kenttätason omistajuudella, harjoitustilalla operaatiota kohden ja näkyvällä ristiriitojen tapahtumakirjalla. Tästä kertoo tarkemmin Commerce-sivu.
Koko sivuWordPress-liitännäinen
Upottaa chat-widgetin sivustollesi ja luo allekirjoitettuja SSO-tokeneita – sisäänkirjautuneet asiakkaat tunnistetaan chatissa tilauksineen päivineen, ilman uutta rekisteröitymistä.
Koko sivuGooglen ja Metan ostosfeedit
Tokenoitu tuotefeed Googlen skeemassa (Meta Commerce Manager lukee samaa) pitää mainoskatalogisi ajan tasalla – ei sovellusarviointia tiellä, ei käsin tehtyjä uudelleenlatauksia.
Shopify Pian
Pohjatyö on oikeaa – Shopifyn asiakasidentiteetit federoituvat jo kontakteiksi, ja tänään Shopify-kaupat yhdistetään API:n ja webhookien kautta. Natiivi kaksisuuntainen synkronointi WooCommercen malliin on tiekartalla, ja tämä merkki vaihtuu silloin kun se on valmis, ei ennen.
Koko sivuTuki ja tiketit
Zendesk – silta siirtymävaiheessa olevalle tiimille
Push: tiketit ulos
ConnectWizin tikettikeskustelut luovat Zendesk-tikettejä ja peilaavat vastaukset kommentteina – niin Zendeskissä yhä elävä tiimi näkee työn ilman että sitä tarvitsee pyytää.
Koko sivuPull: asiakaspalvelijan vastaukset takaisin
Zendesk-liipaisin lähettää asiakaspalvelijan kommentit takaisin ConnectWiz-ketjuun – suojattuna jaetulla salaisuudella ja silmukkavahdilla, joka estää järjestelmiä pomputtelemasta samaa kommenttia ikuisesti.
Rehellinen laajuus
Se on tikettisilta – luonti, vastaus, molemmat suunnat kytkettävissä – ei Zendeskin ohjekeskuksen, makrojen tai SLA:iden tuonti. Tiimit käyttävät sitä siirtyäkseen vähitellen ja sammuttavat sen sitten.
CRM
Estesoft Stella – oma CRM:si näkyvissä keskustelusta
Ensimmäinen palveluntarjoaja palveluntarjoajariippumattomassa CRM-portissamme: Stellaa käyttävät klinikat pitävät CRM:nsä ja saavat keskustelukerroksen, joka oikeasti tuntee sen.
Reaaliaikainen konteksti, identiteettiin lukittuna
Stellan ajanvaraukset, tarjoukset, saldot, muistiinpanot ja dokumentit nousevat esiin keskustelussa – ja tekoäly voi lukea ne juuri tälle asiakkaalle, ei koskaan ID:tä arvaamalla.
Varaukset kirjautuvat takaisin lähteeseen
Chatissa tehty ajanvaraus päätyy Stellan ajanvarauskirjaan – ja jos toimittajan API ei kanna jotain yksityiskohtaa, synkronointi kertoo mitä se pudotti sen sijaan että pudottaisi sen hiljaa.
Tarkoituksellisia kieltäytymisiä
Hoitotietoja ei koskaan lueta eikä näytetä, toimittajan omia elinkaarimerkintöjä ei koskaan ylikirjoiteta eikä täyttä kaksisuuntaista peilausta teeskennellä – rajat ovat suunnittelupäätöksiä, ja ne on kirjoitettu ylös.
Estesoft Stella – koko sivu · Käytätkö toista CRM:ää? Portti on suunniteltu palveluntarjoajariippumattomaksi – kerro omasi. Ja kun olet valmis jättämään vanhan järjestelmän kokonaan, alla oleva siirtomoottori tuo historiasi mukanaan.
Markkinointi ja palveluntarjoajat
Tuo omat palveluntarjoajasi – talon filosofia
Tekoäly: omat avaimesi, 5 palveluntarjoajaa
Wiz toimii omilla palveluntarjoaja-avaimillasi viidellä tekoälypalvelulla ja kymmenillä malleilla – ei tokenikatetta, mallivalinta käyttötapauksittain ja vapaus lähteä mistä tahansa toimittajasta. Tästä kertoo tarkemmin tekoälysivu.
Push: oma OneSignalisi
Kävijöiden web push kulkee oman push-sovelluksesi kautta omalla domainillasi – koska niin web push oikeasti toimii, ja muun teeskentely hajoaa ensimmäisenä päivänä.
Varaukset ulos, varattu aika sisään
Varaukset työnnetään Googlen, Microsoft 365:n ja Applen tai CalDAV-kalentereihin ja katoavat peruutuksessa; ulkoinen varattu aika vähentää saatavuutta, joten mikään ovi – ihminen tai tekoäly – ei voi tarjota jo varattua aikaa. Tarkemmin kertoo ajanvaraussivu.
Suunta lähteittäin
Jokainen kalenteri näyttelee antamaasi roolia – luku, kirjoitus, molemmat tai vain varattu aika – joten klinikan jaettu kalenteri ja hoitajan henkilökohtainen kalenteri elävät rinnakkain ylikirjoittamatta toisiaan.
Mainonta ja vaatimustenmukaisuus
Putkisto keskustelujen, mainosalustojen ja viranomaisten välissä
Meta Conversions API
Voitettu kauppa raportoituu takaisin sille mainokselle, joka chatin aloitti – ostotapahtumana, jonka identiteetti täsmätään kanavakohtaisesti oikein – ja mukana kulkevat liidin laatusignaalit CRM-suppilostasi. Oma datajoukkosi, oma tokenisi, oletuksena pois päältä; neljä porttia (suostumus mukaan lukien) ennen kuin yksikään tapahtuma lähtee, ja terveyspaneeli, joka näyttää mitä lähetettiin ja mikä torjuttiin ja miksi.
Koko sivuİYS (Turkki)
Turkin kaupallisen viestinnän rekisteri integroituna: suostumukset työnnetään myönnettyinä tai peruutettuina, rekisterin puolen kiellot haetaan takaisin päivittäin ja tunnukset ovat paneelissa vain kirjoitettavia. Rekisterinmukaisuus putkistona – ja nykyisen puolitoistasuuntaisen laajuutensa kertoo İYS-sivu.
Koko sivuTämän osion rehellisyyssääntö
Mainonnan ja vaatimustenmukaisuuden integraatiot laukeavat vain suostumusporttien takaa, ja jokainen torjuttu tapahtuma kirjataan syineen. Jos numeroa ei voi täsmätä varmasti, sitä ei arvata – väärä identiteetti maksaa jonkun toisen yksityisyyden.
Siirtyminen
Jätä vanha CRM. Pidä historiasi.
Oikea siirtomoottori
Tuetuista lähdejärjestelmistä: kontaktit, ajanvaraushistoria, tarjoukset, myyntitilaukset, saatavat ja muistiinpanot tuodaan jonotetulla ja jatkettavalla moottorilla – yhdessä tiimimme kanssa, koska CRM:n vaihto ansaitsee operaattorin eikä nappia.
Ohitukset raportoidaan nimeltä
Moottori kieltäytyy keksimästä arvoja – tietue, jolta puuttuu valuutta tai päivämäärä, ohitetaan ja lasketaan, joten ”siirto valmis” ei koskaan peitä tietueita, jotka yhä elävät vanhassa järjestelmässä.
Omistajuus vaihtuu viimeisenä
Datan omistajuus siirtyy vasta viimeisenä vaiheena, kun tuonti on todistanut itsensä – vanha järjestelmä pysyy auktoriteettina siihen hetkeen asti, jona päätät toisin.
Yksi OpenAPI-sopimus
Koko alusta on määritelty yhdessä OpenAPI 3 -dokumentissa – samassa sopimuksessa, josta verkkopaneelimme ja mobiilisovelluksemme generoivat tyyppinsä. Ei varjoendpointteja, ei dokumentaation ajautumista.
Rajatut Commerce API -avaimet
Tenantin myöntämät avaimet eksplisiittisin oikeuksin – katalogin luku, tilausten luku, tilausten kirjoitus – pyörittävät omaa näyteikkunaasi tai sovellustasi meidän katalogi- ja tilausmoottorimme päällä.
Saapuvat webhookit, suojattuina
Minkä tahansa ulkoisen järjestelmän voi antaa käynnistää automaation: jokaisen liipaisimen takana on yksi työnkulku ja jokaisella webhook-liipaisimella on oma URL-osoitteensa, oma salaisuutensa, HMAC-varmennus ja toistosuojaus – ja hyötykuormat ovat dataa, eivät ohjeita.
Ulospäin: työnkulut soittavat sinulle
REST-askel kutsuu järjestelmiäsi juuri niinä hetkinä, jotka piirrät kankaalle. Yleistä tilaa-kaikki-webhookvirtaa ei ole vielä rakennettu – se sanotaan tässä, eikä sitä tarvitse keksiä myyntipuhelussa.
Syvyys voittaa logot.
Kytke ne palat, joita jo pyörität – ja tiedä tarkalleen, mitä kukin kytkentä tekee, ennen kuin laitat sen päälle.