ConnectWiz Booking

Appointment book na may database bilang gulugod.

Na-book man ng agent, ng AI, ng flow, o ng customer mismo — pumapasok ang bawat appointment sa iisang ledger kung saan tama ang pagtatagpo ng mga kuwarto, gamit, at practitioner, hinaharangan mismo ng storage layer ang double booking, at nagsi-sync sa dalawang direksyon ang totoo mong mga kalendaryo.

Apat na pinto ng booking, iisang katotohanan Database ang humaharang sa mga conflict Sync sa Google · Outlook · Apple
Availability — database ang nagpapasya
Huwebes
Kuwarto + gamit + doktor: bakante
Nagsasapawan — tinanggihan ng DB
Na-book ang 14:30
Naipasa sa Google · naibawas ang busy na oras
4
Pinto ng booking — panel, AI, hakbang sa flow, at self-booking ng bisita sa widget
0
Posibleng double booking — tinatanggihan ang mga nagsasapawan ng isang database constraint, hindi ng app rule na puwedeng maunahan
3
Calendar provider na naka-sync sa dalawang direksyon — Google, Outlook/Microsoft 365, at Apple/CalDAV
15 minuto
Dalas ng reminder engine — lumalabas ang mga paalala sa customer at alerto sa staff ayon sa lead time na itinakda mo

Apat na pinto

Iisang katotohanan ang pinagbabatayan ng lahat ng nagbu-book

Ang team, sa appointment book

Appointment book na naka-day view at buong pamamahala ng booking — mga uri, lokasyon, practitioner, variant ng serbisyo, mga status label na itinakda ng tenant, paghawak sa no-show, at mga line item.

Ang AI, sa dalawang pandiwa

Nag-aalok si Wiz ng totoong bakanteng slot, saka bino-book ang pinili ng customer — sadyang dalawang hakbang, dahil panlilinlang sa demo ang kusang pag-reserve ng unang bakanteng slot para sa isang tao, hindi serbisyo.

Flows, bilang isang hakbang

Ang booking node ay nagdadala ng pag-aalok ng slot sa anumang automation — ang reminder flow na nagtatapos sa na-rebook na appointment, nang walang taong kailangang makialam.

Mga bisita, sila mismo ang nagbu-book

Ang website widget ay may booking mini-app na hinahayaan ang mga customer na pumili mismo mula sa live availability — lumalabas lang kapag may bookable na serbisyo ka talaga.

Ang resource model

Mga kuwarto, gamit, tao — nagtatagpo gaya sa totoong buhay

Tatlong-panig na tanong ang "available": dapat sabay na bakante ang practitioner, ang kuwarto, at ang gamit. Karamihan sa mga booking tool ay iisang axis lang ang minomodelo at umaasa na lang; ang pagtatagpo mismo ang minomodelo nito.

Abstract na 3D na ilustrasyon: isang calendar grid na may isang esmeraldang slot, tatlong resource orb na naka-lock sa singsing ng liwanag, at isang nagsasapawang slot na itinutulak palayo ng force field

Mga role at container

May hawak na maraming resource ayon sa role ang isang booking — kuwarto, gamit, practitioner — at dahil sa mga container link, tamang hindi available ang gamit na nasa loob ng okupadong kuwarto, kahit walang nag-book ng gamit.

Constraint, hindi patakaran

Nasa storage layer ang pagpigil sa pagsasapawan bilang exclusion constraint — hindi puwedeng parehong manalo ang dalawang nag-uunahang request, dahil pisikal na tinatanggihan ang ikalawang pagsulat. Nangangako ang rule engine; gumagarantiya ang constraint.

Kapasidad bilang mga unit

Walong unit ang klaseng may walong upuan, hindi counter — kaya katotohanan tungkol sa isang tiyak na unit ang "isa na lang", at hindi nagugulo ang aritmetika ng mga refund.

Eligibility, hiwalay

May sariling matrix ang "puwede ba ang serbisyong ito sa kuwartong ito", hiwalay sa okupasyon — kaya hindi kailanman iniaalok ang resource na bakante pero mali, at nasisilip ang dahilan.

Sync ng kalendaryo

Ang mga kalendaryo mo, ibinabawas sa availability

Lumalabas ang mga booking

Lumalabas ang mga appointment bilang event sa Google, Outlook, o Apple calendar — at nawawala kapag kinansela. Hindi kailanman nahuhuli nang isang araw ang kalendaryo sa telepono ng practitioner sa appointment book.

Pumapasok ang busy na oras

Ibinabawas sa availability ang mga event mula sa labas — hindi kailanman mag-aalok ang AI ng Huwebes 15:00 kung nakalagay na roon sa personal mong Google Calendar ang dentista.

Role at direksyon kada source

May sariling setting ang bawat nakakonektang source — babasahin, susulatan, pareho, o busy lang — kaya puwedeng magkaiba ang papel ng shared na kalendaryo ng klinika at ng personal na kalendaryo nang hindi nagbabanggaan.

Mga paalala at operasyon

Ang follow-through, naka-automate

Mga paalalang talagang lumalabas

Mga kumpirmasyon at paalala sa customer ayon sa lead time na itinakda mo — email, at SMS kung gusto mo — dagdag pa ang alerto sa staff kapag may bagong booking. Hindi na nakasalalay sa alaala ang "babalikan kita".

Kumokonsumo ng stock ang mga booking

Puwedeng kumonsumo ng mga piyesa mula sa stock ledger ang isang service appointment — sabay na nagtutugma sa iisang galaw ang gamutan at ang mga materyales na ginamit nito.

Pumapasok ang history

Lilipat mula sa ibang CRM? Ini-import ng migration engine ang kasalukuyang history ng appointment mo sa parehong ledger — hindi nagsisimulang walang alaala ang appointment book.

Ang fine print, walang paligoy-ligoy

Sinabi bago ka magplano sa paligid nito

Wala pang hiwalay na booking link

Nasa loob ng chat widget ng website ang self-booking — wala pang pampublikong booking page na parang Calendly na maipapadala mo sa email. Kung iyan ang pangunahing daloy mo, sabihin sa amin; nakakaapekto iyan sa roadmap.

Mas kaunti ang nadadala ng mga external na CRM

Kapag isinusulat palabas ang isang booking sa nakakonektang CRM, puwedeng hindi makaligtas ang detalye ng gamit at konsumo — hindi inilalathala ng mga API ng vendor ang mga axis na iyon, at sinasabi ng sync kung ano ang nalaglag sa halip na tahimik itong ilaglag.

Amin ang ledger, palagi

Anumang kalendaryo at CRM ang ikonekta, nananatiling sariling table ng ConnectWiz ang ledger ng booking — source at kopya ang mga panlabas na sistema, hindi kailanman master. Posisyon iyan sa disenyo, at tahasan naming sinasabi.

FAQ sa booking

Bago ka mag-iskedyul

Marami pang sagot sa buong FAQ, o kaya magtanong nang direkta sa amin.

Apat na pinto: ang team mo sa panel at sa appointment book na naka-day view, si Wiz na AI agent sa loob ng anumang pag-uusap, ang booking step ng isang automation flow, at ang mga bisitang nagbu-book mismo sa chat widget ng website. Sumusulat ang apat sa iisang ledger, laban sa iisang availability, kaya eksaktong iisa ang katotohanan kung sino ang may hawak ng aling slot.

Sa mismong database — dahil sa exclusion constraint sa storage layer, pisikal na imposibleng maisulat ang dalawang nagsasapawang hold sa iisang resource, alinmang pinto ang sumubok. Puwedeng magkaunahan ang mga application rule; hindi ang constraint.

Oo — Google, Outlook/Microsoft 365, at Apple/CalDAV, sa dalawang direksyon: lumalabas ang mga booking bilang event (at nawawala kapag kinansela), at pumapasok ang busy na oras mula sa labas at ibinabawas sa availability, kaya hindi kailanman mag-aalok ang AI ng slot na nakuha na ng personal mong kalendaryo. May sariling setting sa role at direksyon ang bawat source — basa, sulat, pareho, o busy lang.

Sadyang sa dalawang hakbang: nag-aalok muna ito ng totoong available na slot, saka bino-book ang pinili ng customer. Kapag pinagsama ang dalawa sa iisang hakbang, kusang irereserba ang unang bakanteng slot para sa isang tao — maginhawa sa demo, perwisyo sa totoong buhay.

Puwedeng mauwi sa naka-hold na slot ang bawat "kailan ka bakante?".

I-set up nang isang beses ang mga resource mo — pagkatapos, iisang katotohanan ang pinagbabatayan ng mga agent, AI, flow, at customer sa pag-book.