Broneerimissüsteem kodulehele — millal plugin ei sobi ja mida oma süsteem oskab

Broneerimissüsteem kodulehele tähendab, et klient valib aja ja koha sinu enda lehel — mitte välise teenuse juures, kuhu ta lingi kaudu ära saadetakse. Enamik ettevõtteid alustab pluginast või välisest broneerimisteenusest ja jõuab varem või hiljem sama probleemini: süsteem ei tea, kuidas nende äri päriselt töötab.

Allpool on kirjas, mida broneerimissüsteem peab oskama, millal plugin ei sobi ja kuidas me seda kahele kliendile ehitasime.

Kolm viisi broneerimist lahendada

Lahendus	Plussid	Miinused
Väline teenus (DinnerBooking, Calendly jt)	Valmis kohe, kuutasu on väike	Klient lahkub sinu lehelt, bränd katkeb, andmed on kellegi teise käes, kohandamine on piiratud
Plugin	Odav, paigaldatav minutitega	Sinu erireeglid ei mahu ära, kujundus on piiratud, iga uuendus on risk, litsents on aastatasuga
Oma süsteem	Teeb täpselt seda, mida vaja; kood ja andmed on sinu; ei mingit kuutasu	Suurem ühekordne kulu, vajab arendajat

Enamikule ettevõtetest piisab pluginast ja me ütleme seda ausalt. Oma süsteem tasub ära siis, kui su broneerimisreeglid on valmislahenduse jaoks liiga omanäolised — ja seda juhtub sagedamini, kui arvatakse.

Mida broneerimissüsteem peab päriselt oskama

Nimekiri tundub lihtne, kuni hakkad seda tegema:

1. Teadma, millal sa kinni oled. Mitte ainult pühad — ka „esmaspäeviti ja teisipäeviti oleme kinni” ja „viimane broneering kolmapäeval on 20:30, aga reedel 21:30″.
2. Piirama mahtu. Mitu inimest korraga, mitu broneeringut samasse ajaakna, mitu päeva ette.
3. Kinnitust ootama või mitte. Kas broneering on kohe kinnitatud või vaatab keegi selle üle.
4. Saatma kirju, mis kohale jõuavad. Kinnituskiri rämpspostis on sama hea kui saatmata.
5. Töötama telefonist. Nii kliendi kui sinu töötaja jaoks.
6. Mitte kaotama midagi. Kui e-kiri tõrgub, peab broneering ikkagi kuskil alles olema.

Kuidas me selle Fermendile ehitasime

Restoran Ferment broneeris laudu välise teenuse kaudu. Link viis külalise saidilt ära, bränd katkes ja restoranil puudus ülevaade oma kodulehel.

Asendasime selle saidisisese vormiga. Paar detaili, mis näitavad, miks valmislahendus poleks sobinud:

• Oma kalender. Brauseri enda date picker ei ole stiliseeritav ega oska nädalapäevi keelata. Kirjutasime kalendri nullist: brändivärvides, klaviatuuriga juhitav, möödunud kuupäevad ja esmaspäevad-teisipäevad hallid ja mitteklikitavad.
• Nädalapäevapõhised kellaajad. Klient märkas hiljem, et liiga hiliseid broneeringuid tuli pidevalt tagasi lükata. Lisasime viimase broneeritava aja iga päeva kohta. Ajad on defineeritud ühes kohas ja jagatud nii PHP-le kui JavaScriptile — lahtioleku muutus on ühe rea muudatus.
• Kinnitamine ühe klikiga, ilma sisse logimata. Iga uue broneeringu kohta tuleb kiri kahe nupuga: kinnita või lükka tagasi. Töötaja saab selle telefonist ära teha sekunditega.
• Külalise keel jääb meelde. Kinnituskiri saadetakse samas keeles, milles külaline broneeris. Töötajatele suunatud kirjad on alati eestikeelsed.

Iga broneering salvestatakse ka wp-admini alla, nii et ükski soov ei kao, isegi kui e-kiri peaks tõrkuma.

Kui broneerimisega käib kaasas ka maksmine

Matkakorraldaja HikingEstonia puhul oli vaja rohkemat: klient pidi saama koha kinnitada ja kohe maksta.

Integreerisime Montonio makselahenduse — klient valib osalejate arvu, maksab pangalingi või kaardiga ja saab tellimuskinnituse. Kassa lihtsustasime: ostukorvi vahesamm kadus ja tarneväljad, mida elamusteenus ei vaja, on eemaldatud.

Lisaks kirjutasime plugina, mis loeb ettevõtte Facebooki lehe üritusi ja loob neist saidil broneeritavad retked koos toodetega. Sama retke ei pea enam kaks korda sisestama.

Turvalisus, mida broneerimisvorm vajab

Broneerimisvorm on avalik lõpp-punkt, mis kirjutab andmebaasi. See tähendab, et ta on ka sihtmärk:

• Rämpsposti tõrje — peidetud honeypot-väli, ajakontroll ja rate limit.
• Serveripoolne valideerimine. Kõik, mida brauser kontrollib, tuleb serveris üle kontrollida — brauserile ei saa loota.
• Kinnituslingid peavad olema kaitstud. Kasutame salajast token’it ja timing-safe võrdlust. Lisaks kaheastmeline kinnitus, sest e-posti turvaskännerid laadivad linke ette ja võiksid muidu broneeringu kogemata kinnitada.
• Idempotentsus. Juba käsitletud broneeringut ei kinnitata teist korda ega saadeta topeltkirja.

Millal broneerimissüsteem ei tasu

Oleme ausad ka teistpidi. Oma süsteem ei ole mõistlik, kui:

• broneeringuid on paar nädalas ja telefon töötab hästi;
• olemasolev plugin teeb 90% tööst ja ülejäänu on kosmeetika;
• sinu reeglid on standardsed — lahtiolek iga päev sama, kestus alati sama;
• eelarve lubab ainult ehitamist, mitte hilisemat hooldust.

Mis see maksab

Broneerimissüsteemi hinda ei saa hinnakirjast lugeda, sest ta sõltub täielikult sellest, kuidas sinu äri töötab. Sama „broneerimine” tähendab restoranis, matkafirmas ja ilusalongis kolme eri asja.

Seepärast alustame protsessi kaardistamisest: uurime, kuidas broneering praegu käib, kes seda kinnitab ja mis läheb valesti. Alles siis räägime lahendusest ja hinnast. Kui selgub, et plugin teeb töö ära, ütleme seda.

Orientiiriks: kodulehe hinnas tõstab broneerimine projekti tüüpiliselt 4000 euro kanti, ja iga liidestus välise süsteemiga maksab 500–3000 €. Vt custom arendus.

Korduma kippuvad küsimused

Kas ma saan broneeringuid ise hallata?

Jah. Broneeringud on wp-admini all eraldi nimekirjas koos värvikoodiga staatusega — ootel, kinnitatud, tagasi lükatud. Kinnitada saab nii sealt kui otse e-kirjast, ilma sisse logimata.

Kas broneerimissüsteem töötab olemasoleva lehega?

Enamasti jah, kui leht on WordPressis. Kui leht on tehtud page builder’iga, tuleb üle vaadata, kas see ei hakka vastu töötama. Ütleme ülevaatuse järel, kas mõistlikum on lisada olemasolevale või teha koos uue lehega.

Kas saab broneeringu eest kohe maksta?

Jah. Integreerime Eesti ja Balti pangalingid ning kaardimakse (Montonio, Maksekeskus, EveryPay). Siis on koht kinnitatud alles pärast makset.

Kas Google’i kalendriga saab siduda?

Saab, kui teenusel on API — enamasti on. Ütle, millist kalendrit või süsteemi kasutad, ja vaatame üle, mis on tehtav.

Mis saab, kui e-kiri ei jõua kohale?

Broneering on ikkagi andmebaasis ja adminis nähtav — e-kiri ja andmebaas dubleerivad teineteist. Lisaks seadistame saatmise nii, et kirjad päriselt kohale jõuaksid: autenditud SMTP ja domeeni autentimine.

Kokkuvõte

Broneerimissüsteem kodulehele on mõistlik siis, kui su broneerimisreeglid on valmislahenduse jaoks liiga omanäolised — nädalapäevapõhised kellaajad, kinnitusvoog, mitu keelt või maksmine broneerimise hetkel. Enne ehitamist tasub kaardistada, kuidas protsess päriselt käib.

Räägi, kuidas su broneerimine praegu käib — ütleme ausalt, kas selleks on vaja arendust või piisab pluginast.