ConnectWiz + Estesoft Stella

Інтеграція працює

Stella лишається вашою CRM. Розмови нарешті про це знають.

Перший провайдер у нашому провайдеронезалежному CRM-порту: живий контекст клієнта з Estesoft Stella просто в розмові, бронювання, записані назад у щоденник Stella, — і набір свідомих відмов, зафіксованих письмово, про те, чого комунікаційний продукт не має торкатися ніколи.

Контекст, прив’язаний до особи Броні повертаються у джерело Медичні дані: не читаємо ніколи
Estesoft Stella × ConnectWiz
Прив’язано до цього клієнта
Записи · пропозиції · баланс перед очима
Бронювання в чаті → щоденник Stella
Записи про лікування: не читаємо ніколи
10
Операцій читання, названих поіменно — записи на прийом, пропозиції, замовлення, баланс, нотатки, документи, каталог, персонал, локації, пошук клієнта
7
Визначених операцій запису — шість відкрито, одну притримано, доки її не виміряємо, і ми кажемо, яку саме
4
Запобіжники на кожному записі — адаптер, можливість, перемикач операції, власність даних
5
Класів записів, які переносить рушій міграції — записи на прийом, пропозиції, продажі, дебіторка, нотатки

CRM

Що саме вміє

Живий контекст, прив’язаний до особи

Записи цього клієнта, його пропозиції, непогашений баланс, нотатки й документи з’являються просто в розмові — і ШІ може прочитати їх рівно для цього клієнта, визначеного із самої розмови, а не з вгаданого ID.

Броні повертаються у джерело

Запис, зроблений у чаті, потрапляє в щоденник Stella — а там, де API вендора не може перенести якусь деталь, синхронізація каже, що саме вона відкинула, замість того щоб відкинути мовчки.

ШІ читає, але ніколи не пише

Стале правило для всього CRM-порту: читання прив’язане до особи, а запис лишається за людиною — ШІ, здатний неправильно прочитати баланс, це дешева репетиція того, що запише не того пацієнта.

Міграція, коли ви вирішите

Черговий рушій із можливістю продовження імпортує записи на прийом, пропозиції, продажі, дебіторку й нотатки в ConnectWiz — пропуски називаються поіменно, а власність даних переходить лише останнім кроком.

Платежі й замовлення пишуться назад

Фіксація платежу чи створення замовлення в ConnectWiz може піти в Stella — відкривається явним рішенням власника, за тими самими чотирма запобіжниками й режимом репетиції, що й усе інше.

Інкрементно, а не дзеркало

Опитування змін існує, щоб ловити пропущені події, а не щоб тримати другу копію реєстру клініки. Втратити цю різницю означає перетворити кеш на базу даних, тому це записано прямо.

Технічна частина

Шлях запису: чотири запобіжники й репетиція

Типово вимкнено — для кожної операції

Кожен запис постачається вимкненим, і кожна з семи операцій — нотатки, записи на прийом, скасування, клієнти, пропозиції, замовлення, платежі — має власний перемикач. Безпека тут це відсутність: якщо запобіжник не спрацював, немає самого об’єкта-записувача, який можна було б викликати.

Власність старша за перемикач

Над перемикачами окремих операцій стоїть власність даних: ділянка, якою володіє ваш робочий простір, ніколи не пише назовні в Stella, хоч би що казав перемикач. Порядок запобіжників фіксований і задокументований.

Репетиція на бойовому шляху коду

Режим сухого прогону збирає рівно той payload, який надіслав би бойовий запис, і зупиняється лише на транспорті — репетиція, що йде іншим шляхом коду, не доводить нічого, тому такої тут немає.

Записи перевіряють самі себе

Після кожного запису інтеграція читає назад те, що створила, і порівнює. Розбіжність спливає як попередження для людини — ніколи як автовиправлення, бо в API вендора немає ключа ідемпотентності, який зробив би виправлення безпечним.

Міграція в правильному порядку

Першими імпортуються записи на прийом — свідомо, бо щоденник це єдина поверхня, здатна знайти людей по всьому орендарю. Кожен пропущений рядок рахується поіменно: поза часовим вікном, невідома форма, немає контакту.

Читання ШІ замкнене на три замки

CRM-інструмент ШІ оголошує лише ті дії, які ваш робочий простір справді має, перевіряє дію ще раз у момент виклику й визначає клієнта із самої розмови — вигаданий варіант чи вгаданий ID помирає ще до транспорту.

Налаштування

Як підключається

01

Підключіть Stella

Додайте свої облікові дані Stella; конектор перевіряє їх на живому API ще до збереження.

02

Працюйте з контекстом

Розмови показують CRM-картку клієнта; оператори і ШІ відповідають із фактів, а не з пам’яті.

03

Мігруйте, якщо і коли захочете

Запустіть керовану міграцію, щоб перенести всю історію — стара система лишається головною, доки ви не передасте власність.

Разом краще

З чим поєднується

Рушій бронювання

Бронювання з чату потрапляє в щоденник Stella, а система бронювання віднімає записи Stella з доступності — одна правда щоденника.

Картка у вхідних

Оператори бачать живий CRM-контекст клієнта — записи, пропозиції, баланс — поруч із розмовою у спільних вхідних.

Wiz, лише читання

Наш ШІ-агент відповідає на питання «коли в мене запис?» фактами зі Stella, прив’язаними до людини в цьому листуванні, — і за сталим правилом не може писати.

Безпека та гарантії

Нудні гарантії

Дані про здоров’я: не читаємо ніколи

Записи про лікування — це дані особливої категорії за KVKK. Завести їх на екран підтримки означало б розширити коло тих, хто їх обробляє, з лікарів клініки на всю команду — тому ці ендпоїнти існують, а ми від них відмовляємося, письмово.

Жодних невидимих рук

Ми ніколи не закриваємо задачі клініки, ніколи не змінюємо її сегменти клієнтів, ніколи не чіпаємо її бухгалтерський реєстр — кожне з цього задокументована відмова, бо автоматизувати чужий бізнес-процес із чату це найдорожчий клас помилок продукту.

Токени не потрапляють в URL

Вендор пропонує ендпоїнт перевірки токена, який кладе облікові дані просто в URL — де їх бачать логи й проксі. Ми його не викликаємо ніколи. Поводження з обліковими даними обирається для кожного ендпоїнта окремо.

Видалення: не пропонуємо

Ендпоїнти вендора для видалення клієнтів, лідів, рахунків і пропозицій лишаються невикористаними — м’яке це видалення чи жорстке, не перевірено, а видалення картки пацієнта не з’являється в жодному сценарії, який ми готові взяти на себе.

Дрібний шрифт — без прикрас

Межі, названі прямо

Свідомі відмови

Записи про лікування ніколи не читаються й не показуються, мітки життєвого циклу вендора ніколи не перезаписуються, і повного двобічного дзеркала ніхто не вдає — кожна відмова це задокументоване проєктне рішення, а не прогалина.

Інші CRM

Порт задуманий провайдеронезалежним — Stella перший провайдер, а не останній. Працюєте на чомусь іншому? Скажіть нам; це впливає на чергу.

FAQ про Estesoft Stella

Відповіді без води

Решту читайте в повному розділі FAQ — або напишіть нам напряму.

Власні записи клієнта, його пропозиції, замовлення, непогашений баланс, нотатки й документи — просто в розмові, де він пише, — плюс каталог, персонал і локації бізнесу, щоб ШІ мав із чого відповідати. Усі читання замкнені на клієнта з цього листування.

За правилом: на цьому порту ШІ лише читає, і читання прив’язане до особи. Помилковий запис у CRM клініки це інцидент у реальному світі; ми лишаємо записи за людиною і з можливістю аудиту.

Так — рушій міграції імпортує записи на прийом, пропозиції, продажі, дебіторку й нотатки чергою, яку можна продовжити, і звітує поіменно про те, що пропустив. Власність передається явним останнім кроком, тож нічого не лишається переміщеним наполовину.

Шість: нотатки про клієнта, записи на прийом (створення і скасування), нові клієнти, пропозиції, замовлення і платежі — кожен за власним перемикачем, усі типово вимкнені, усі стартують у режимі репетиції. Завантаження файлів визначене, але тримається закритим, доки не виміряємо поведінку ендпоїнта вендора — це прогалина у вимірюванні, а не рішення.

Кожен пропуск рахується поіменно: рядки поза обраним вікном, рядки, форми яких рушій не розпізнає, рядки з клієнтом, якого не вдалося зіставити. Цей підрахунок і є звітом — ви завершуєте міграцію, знаючи, що не переїхало і чому.

Чесна інтеграція краща за гучну.

Кожну інтеграцію тут описано за тим, що вона насправді робить, — разом із напрямком, власністю на дані та обмеженнями.