Kung nakatayo ka na sa harap ng isang siksik na dim sum restaurant isang Sabado ng hapon, alam mo na ang problema. May kahoy na clipboard na nakalagay sa isang maliit na podium, kalahating dosenang pangalan na nakasulat dito, at isang host na hindi nakapag-look up sa loob ng dalawampung minuto. Ang ilang customer ay umalis na inaakala na walang pag-asa ang pila. Ang iba ay nakatayo sa labas ng pintuan nang siyamnapung minuto. Nawala sa restawran ang kita sa mga taong umalis at goodwill mula sa mga naghintay.
Ang solusyon ay hindi mas maraming staff. Ito ay isang virtual queue system na nakatira sa isang telepono at nag-a-update ng sarili.
Ano Talaga ang Ginagawa ng Virtual Queue
Ang isang virtual queue ay pinapalitan ang clipboard ng isang pampublikong web page. Ang bawat customer ay nag-scan ng QR code sa pintuan, nag-tap ng Reserve, at agad na nakikita ang kanilang queue number at isang tinatayang posisyon ("4 na tao sa harap mo"). Maaari silang maglakad sa kapitbahayan, umupo sa kanilang kotse, tapusin ang isang tawag sa telepono, o gawin ang anumang mas gusto nilang gawin kaysa makatayo sa bangketa. Kapang ang kanilang numero ay malapit na, bumabalik sila.
Ang sistema ay nasa pagitan ng dalawang kalahati ng parehong problema. Sa panig ng customer, sinasagot nito ang "kailan ang aking turn?" nang hindi kailangang magtanong ng sinuman. Sa panig ng restawran, sinasagot nito ang "paano namin pamahalaan ang daloy?" nang hindi kailangang sumulat ang sinuman ng mga bagay o tumawag ng mga pangalan sa isang abalang silid.
Ang teknolohiya ay simple. Isang maliit na dashboard sa tablet ng host ang nagpapakita ng waiting list na may mga timestamp at reference code. Ang host ay nag-ta-tap ng Call Next kapag nagbukas ang isang mesa. Ang telepono ng customer ay nag-a-update sa loob ng labinlimang segundo. Walang mga pager na mawawala, walang mga clipboard na mahuhulog, walang mga sinisigaw na pangalan na mawawala sa maingay na dining room. Ang buong bagay ay tumatakbo sa isang browser — walang pag-install ng app, walang friction.
Bakit Mahalaga ang GPS Gating
Ang naive na bersyon ng isang virtual queue ay nagpapahintulot sa sinuman, kahit saan, na kumuha ng numero. Mukhang maganda iyon ngunit agad na nasira. Ang isang teenager sa ibang lungsod ay nagpasya na maglaro. Ang isang tamad na customer ay humahawak ng numero mula kahapon at umaasa na makaligtas ng pila bukas. Ang kaibigan ng karibal ay nag-rereserta ng isang daang pekeng lugar upang gawing mas mahaba ang iyong queue kaysa sa aktwal.
Ang GPS gating ay nagaayos nito. Bago lumabas ang Reserve button, ang telepono ng customer ay nag-uulat ng lokasyon nito. Kinakalkula ng sistema ang great-circle distance sa restawran, at pinapagana lamang ang button kung ang customer ay nasa loob ng isang configured na radius — karaniwang limang kilometro para sa karamihan ng mga urban na restawran at isa hanggang dalawang kilometro para sa mataas na densidad na downtown na bloke.
Ang tseke ay nangyayari nang dalawang beses. Una sa browser, kung saan ang button ay hindi naka-enable hanggang hindi pa nasa range ang customer, na nagbibigay ng agarang feedback. Pagkatapos ay sa server, kapag ang reservation ay talagang nalagay na, dahil ang data ng lokasyon mula sa browser ay teknikal na mapeke. Ang parehong tseke nang magkasama ay nagpapanatili ng queue na malinis nang hindi pinahihirapan ang mga tunay na customer.
Para sa mga restawran na may maraming lokasyon, ang GPS gating ay awtomatiko rin na nag-ruta ng mga customer sa tamang branch. Ang isang customer na nagkataong malapit sa iyong downtown na lokasyon ay hindi aksidenteng napupunta sa queue para sa iyong suburban na lokasyon.
Anatomy ng isang Polled Wait Dashboard
Kapag ang telepono ng customer ay bukas sa queue page, anong frequency ang dapat nitong suriin para sa mga update? Masyadong mabilis at nagsasayang ka ng baterya at bandwidth. Masyadong mabagal at ang paghihintay ay pakiramdam na walang katapusan.
Ang labinlimang segundo ay lumalabas na ang sweet spot. Sapat na mabagal upang hindi mapansin ng iyong mga server, sapat na mabilis upang ang customer ay pakiramdam na "live" ang page. Sa loob ng labinlimang segundo ng pag-tap ng host ng Call Next, ang now-serving number ng customer ay tumatick up at alam na nila na mas malapit na sila. Kung bumaba ka sa ibaba ng sampung segundo, magsisimula kang makita ng kapansin-pansing pagbaba ng baterya sa mga telepono na bukas ang screen. Kung umabot ka sa tatlumpu o animnapung segundo, ang karanasan ay nagsisimulang maging parang tsina-check ang isang static na larawan.
Ang dashboard mismo ay dapat magpakita ng tatlong numero — wala nang hihigit pa. Ang kasalukuyang serving number, malaki at prominente. Ang sariling numero ng customer. At ang bilang ng mga tao sa pagitan nila. Anumang iba pa ay ingay. Ang isang queue page ay hindi isang karanasan sa brand — ito ay isang status check.
Anti-Cheat: Mga Reference Code
Ang bawat reservation ay nakakakuha ng isang anim na character na reference code na nabuo sa panig ng server. Nakikita ito ng customer sa kanilang telepono, sa nase-save na PNG ticket, at hinihiling na ipakita kapag tinawag ang kanilang numero. Nakikita ng host ang parehong code sa dashboard. Kung ang customer ay nag-aangkin na sila ay numero 42 ngunit nagpapakita ng isang code na hindi tumutugma sa kung ano ang ipinapakita ng dashboard para sa numero 42, alam ng host na may hindi tama.
Ang mga reference code ay gumagamit ng confusable-free na character set: walang zero o O, walang isa o I, walang lowercase na titik na mukhang mga digit. Mahalaga ito kapag ang isang tao ay nakasimangot sa isang telepono sa m희mang restaurant na ilaw at sinusubukang basahin ang isang code sa isang maingay na dining room.
Ang mga code ay single-issue din. Ang parehong customer ay hindi maaaring mag-reserve nang dalawang beses mula sa parehong browser, dahil nakikilala ng sistema ang kanilang persistent client identifier. Kung subukan nila, matatanggap nila ang parehong numero at code na mayroon sila noong una — hindi isang bago.
Gastos Bawat Reservation
Ang mga operator ng restawran ay kadalasang inaakala na ang mga virtual queue system ay nangangailangan ng mahal na hardware o mga kontrata sa subscription. Hindi sila. Ang gastos ng infrastructure sa pagpapatakbo ng isang queue para sa isang solong restawran sa AWS DynamoDB at S3 ay nasa cents-bawat-buwan na hanay, kahit sa isang libong reservation bawat araw, dahil ang mga dominanteng operasyon ay maliliit na atomic counter increment.
Ang isang clipboard ay walang gastos sa dolyar ngunit may makabuluhang halaga sa karanasan ng customer. Ang isang sistema ng pager ay nagtatayo ng daan-daang dolyar sa hardware kasama ang mga gastos sa pagpapalit bawat taon. Ang isang virtual queue ay walang gastos bawat customer bukod sa pinagbabatayan na bayad sa cloud. Ang mga ekonomiya ay simpleng pabor sa digital na diskarte sa sandaling gumawa ka ng higit sa iilan na reservation bawat shift.
Pagsisimula
Kung hindi ka pa nagtakbo ng virtual queue dati, magsimula nang maliit. I-enable ito para sa isang shift sa isang uri ng serbisyo — dine-in o takeaway — at obserbahan kung ano ang mangyayari. Panoorin kung paano ginagamit ng mga customer, kung saan sila nalilito, kung anong mga tanong ang itinatanong nila sa host. Ayusin ang iyong setting ng maximum-distance, ang iyong mga salita, at ang placement ng iyong QR code batay sa iyong matututunan.
Ang layunin ay hindi ang alisin ang host. Ito ay ang palayain ang host upang makapag-focus sa pagtanggap ng mga customer, pamamahala ng dining room, at paghawak ng mga paminsan-minsal na espesyal na kahilingan — sa halip na gumaganap bilang isang human spreadsheet para sa isang piraso ng karton. Ang isang magandang virtual queue ay nagpapasaya ng parehong mga customer at staff, at nagbabayad para sa sarili nito sa unang pagkakataon na maiwasan mo ang isang Sabado na gabi na chaos.
