Verkkolomake yritykselle ilman omaa PHP-käsittelijää

Hyvä verkkolomake yritykselle säästää aikaa kahdessa kohdassa. Viestistä näkee heti, mitä asiakas haluaa, ja yrityksessä tiedetään, kuka siihen vastaa. Kun jompikumpi puuttuu, yhteydenotto muuttuu kysymysten vaihtamiseksi tai jää odottamaan postilaatikkoon.

Lomakkeen takana on lisäksi tekninen kysymys, jota harvoin mietitään: mikä ottaa lähetetyt tiedot vastaan? Vastaus vaikuttaa siihen, kuinka paljon koodia sivustolla pitää ylläpitää ja kuka vastaa sen toimivuudesta.

Miksi lomake voi vähentää tai lisätä työtä?

Tavallisin ongelma on käytännöllinen, ei tekninen. Lomakkeessa on yksi kenttä nimeltä ”Viesti”, ja asiakas kirjoittaa siihen joko kaiken tai lähes ei mitään. Yrityksen täytyy kysyä perään osoite, ajankohta tai tuote, ja yksi yhteydenotto vaatii kolme viestiä.

Toinen yleinen ongelma on vastuu. Lomake lähettää viestin osoitteeseen, jota kukaan ei seuraa, tai viesti menee kolmelle ihmiselle, jolloin jokainen olettaa toisen vastaavan. Lomake on silloin teknisesti kunnossa, mutta asiakas odottaa vastausta turhaan.

Sivulla näkyvä lomake ja erillinen vastaanotto

Verkkosivulla lomake on vain kentät ja painike. Sen jälkeen jonkun on otettava tiedot vastaan, tarkistettava ne ja toimitettava eteenpäin. Perinteisesti tämä tehdään sivuston omalla PHP-käsittelijällä, joka lähettää tiedot esimerkiksi sähköpostina.

Toinen tapa on antaa vastaanotto erilliselle palvelulle. Staattinen HTML-sivu lähettää tiedot suojatulla HTTPS-yhteydellä Node-pohjaiseen vastaanottopalveluun. Sivustolle ei tarvita omaa PHP-käsittelijää, eikä sähköpostipalvelun salaisia avaimia tarvitse tallentaa verkkosivulle. KH Digiratkaisujen verkkolomake toimii näin, ja sen voi liittää nykyiselle sivustolle ilman KoHe Chatia tai koko sivuston uudistusta. Vastaanottopalvelun ylläpito hoidetaan keskitetysti.

Miksi selaimen tarkistus ei yksin riitä?

Selain voi huomauttaa tyhjästä pakollisesta kentästä tai virheellisestä sähköpostiosoitteesta, ja se helpottaa kävijän työtä. Selaimen tarkistus ei kuitenkaan yksin riitä suojaukseksi, koska sen voi ohittaa. MDN:n lomakkeiden validointia käsittelevän oppaan mukaan tiedot on siksi tarkistettava myös palvelimella.

Erillisessä vastaanottopalvelussa sallitut kentät, niiden tyypit ja muodot sekä lähetyksen enimmäiskoko tarkistetaan palvelimella. Kenttä, jota lomakkeelle ei ole sovittu, tai liian suuri lähetys ei mene eteenpäin. Tämä vähentää turhia ja virheellisiä lähetyksiä, mutta se ei tarkoita, että väärinkäyttöä ei voisi koskaan tulla.

Entä sivuston oma PHP?

Oman lomakekäsittelijän poistaminen pienentää sivustolla ylläpidettävää osaa, mutta ei poista ylläpidon tarvetta. Jos sivusto käyttää PHP:tä muuhun tai siinä on lisäosia, ne täytyy edelleen päivittää. PHP-käsikirjan mukaan uudet versiot tuovat tietoturvaparannuksia ja korjauksia, joten päivitysten ajan tasalla pitäminen on tärkeää. Mitä sivuston ylläpitoon yleensä kuuluu, selviää tekstistä verkkosivujen ylläpito yritykselle.

Hyvin ylläpidetty PHP-lomake voi silti olla aivan sopiva ratkaisu. Kieli ei yksin kerro, onko lomake turvallinen. Ratkaisevaa on, miten tiedot tarkistetaan, miten koodia päivitetään ja kuka siitä vastaa. Päivitysvastuu jakautuu käytännössä kahtia: sivuston omistaja tai ylläpitäjä huolehtii sivustolla olevasta koodista, lisäosista ja PHP-versiosta, ja erillisen vastaanottopalvelun päivityksistä vastaa sen ylläpitäjä. Kumpikin voi olla hyvin hoidettu tai laiminlyöty, joten kysy kummastakin, kuka päivittää ja miten muutoksista kerrotaan. Jos koko sivusto on vanhentunut ja lomake on vain yksi oire, kannattaa katsoa isompaa kuvaa: verkkosivut yrityksille -palvelusivulla kerrotaan, miten uusi sivusto rakennetaan.

Kaksi esimerkkiä: tarjouspyyntö ja palaute

Kuvitellaan huoltoyritys, joka saa tarjouspyyntöjä verkkosivun kautta. Hyödyllinen lomake kysyy kohteen tyypin, paikkakunnan, työn kuvauksen ja yhteystiedon. Kun nämä ovat jo viestissä, tarjouksen laatija voi aloittaa ilman ensimmäistä selvityspuhelua. Lisäksi on sovittu, kuka tarjouspyynnöt lukee ja kuinka nopeasti niihin vastataan.

Pakollisia kenttiä ovat tässä esimerkissä kohteen tyyppi, paikkakunta ja yhteystieto, koska tarjousta ei voi laatia ilman niitä. Toivottu aloitusajankohta ja kohteen koko voivat olla valinnaisia. Jos kävijä ei vielä tiedä niitä, hänen ei tarvitse keksiä vastausta vain päästäkseen eteenpäin, eikä yrityksen tarvitse arvioida työtä keksittyjen lukujen pohjalta. Tyhjä valinnainen kenttä kertoo vastaanottajalle, mitä kannattaa kysyä vastauksessa.

Toinen esimerkki on palveluyritys, joka haluaa kerätä asiakaspalautetta. Lomake voi olla paljon kevyempi: vapaa kommentti ja valinnainen yhteystieto sitä varten, että asiakas haluaa vastauksen. Kun palaute ohjataan sovittuun osoitteeseen, se ei huku yleisen yhteydenottopostin sekaan. Sovi myös, kuka lukee palautteet loma-aikana ja kuka toimii sijaisena, jotta viesti ei jää odottamaan yhden ihmisen paluuta. Kerro lomakkeen yhteydessä, voiko palautteeseen pyytää vastausta ja mitä yhteystietoa sitä varten tarvitaan.

Sama palveluyritys voi tarvita molemmat lomakkeet, mutta tarjouspyynnöllä ja palautteella on eri käsittelijä ja eri tavoite.

Mitä lomakkeelta kannattaa kysyä?

Kysy vain se, mitä ensimmäisen vastauksen antamiseen tarvitaan. Ylimääräinen kenttä voi tehdä lomakkeesta raskaamman täyttää, ja puuttuva kenttä lisää edestakaista viestittelyä. Hyvä tapa löytää raja on käydä läpi viimeiset yhteydenotot ja katsoa, mitä tietoa jouduit pyytämään erikseen.

Pakolliset kentät kannattaa merkitä selvästi ja pitää mahdollisimman vähäisinä. Kun kenttä jätetään valinnaiseksi, kävijä ei joudu keksimään vastausta vain päästäkseen eteenpäin.

Mieti myös, mitä tapahtuu, kun tieto on puutteellinen. Jos sähköpostiosoite on kirjoitettu väärin tai pakollinen kenttä jää tyhjäksi, kävijälle kannattaa kertoa selkeästi, mikä kenttä vaatii korjausta ja mitä siihen pitäisi kirjoittaa. Hyvä käytäntö on, että jo täytetyt kentät säilyvät korjauksen ajan, jotta kävijän ei tarvitse kirjoittaa pitkää kuvausta uudelleen. Kokeile käytännössä myös pitkää viestiä ja virheellistä yhteystietoa: kerätyn kuvauksen pitäisi auttaa jatkokäsittelyä eikä kadota yhden korjattavan kentän vuoksi. Valitun ratkaisun toiminta kannattaa tarkistaa käyttöönotossa.

Mitä käyttöönotossa kannattaa sopia ja testata?

Lomakkeen vaihdossa muutama asia kannattaa sopia ennen kuin vanha käsittelijä poistetaan. KH Digiratkaisujen lomakkeessa kentät, vastaanottaja ja toimitustapa sovitaan käyttöönotossa yrityksen tarpeen mukaan. Hyvä tarkistuslista:

• kentät: vain tarpeelliset, pakolliset selvästi merkittyinä
• vastaanottaja ja vastuu: kuka lukee viestit, kuka vastaa ja kuinka nopeasti
• virhe- ja onnistumisviestit: kävijä näkee, mikä meni vikaan ja milloin lähetys onnistui
• oikea reitti: testiviesti sivuston julkaistulta osoitteelta ennen vanhan käsittelijän poistamista
• puhelin: lomake kokeiltu myös mobiilissa

Vastaanotto ja vastaaminen ovat eri asioita. Se, että viesti on otettu vastaan, ei kerro, että joku on lukenut sen tai että vastaus tulee tietyssä ajassa. Lähetyksen vahvistuksen kannattaa perustua vastaanottopalvelun palauttamaan tulokseen. Kun palvelu hyväksyy viestin, asiakkaalle voidaan kertoa vastaanoton onnistumisesta. Lupaus vastausajasta kuuluu tekstiin vain, jos yrityksessä on oikeasti sovittu, kuka vastaa ja milloin.

Sovi myös poissaolot. Jos viestit menevät yhdelle henkilölle, päätä etukäteen, kuka lukee ne lomalla tai sairastapauksessa. Muuten lomake voi toimia moitteettomasti, vaikka kukaan ei ole lukemassa viestejä.

Testiviesti kannattaa suunnitella niin, että se kattaa koko reitin: lähetys julkaistulta osoitteelta, viestin saapuminen oikeaan vastaanottopaikkaan ja kävijälle näkyvä vastaus. Kokeile sekä onnistunutta lähetystä että tarkoituksella virheellistä, esimerkiksi puuttuvaa pakollista kenttää, ja katso, että kummastakin näkyy ymmärrettävä viesti. Kirjaa havaittu tulos ja korjaa puutteet ennen vaihtoa, jotta uuden lomakkeen toimivuus on varmistettu samalla sivulla, jolla asiakkaat sitä käyttävät.

Tarkistukset ovat suosituksia hyvään käyttöönottoon. Ne tehdään yrityksen omalla sivustolla, ja lopullinen tulos varmistetaan vasta, kun oikea testiviesti on kulkenut perille.

UKK verkkolomakkeesta yritykselle

Voiko verkkolomakkeen lisätä nykyiselle sivustolle ilman chatbotia?

Kyllä. Erillinen lomake ei vaadi KoHe Chatia eikä uutta verkkosivustoa. Liittämistapa ja tarvittavat kentät tarkistetaan käyttöönotossa.

Tarvitseeko staattinen HTML-sivu erillisen vastaanottajan?

Staattinen sivu ei pysty itse käsittelemään lähetettyjä tietoja, joten ne pitää lähettää jonnekin. Erillinen vastaanottopalvelu ottaa ne vastaan HTTPS-yhteydellä, eikä sivustolle tarvita omaa PHP-käsittelijää.

Onko PHP-lomake automaattisesti turvaton?

Ei ole. Kieli ei yksin ratkaise turvallisuutta. Hyvin ylläpidetty lomake, jossa tiedot tarkistetaan palvelimella, voi olla sopiva. Ongelmia syntyy, kun versioita ei päivitetä tai tietoja ei tarkisteta.

Miten valitsen lomakkeen kentät?

Lähde siitä, mitä tarvitset ensimmäisen vastauksen antamiseen. Jätä pois kentät, joita et käytä, ja merkitse pakolliset tiedot selvästi.

Sopiiko erillinen lomake yrityksesi sivustolle?

Kerro, mitä tietoja lomakkeella pitäisi kerätä ja kuka yhteydenotot käsittelee. Kysy verkkolomakkeesta, niin katsotaan yhdessä, mikä olisi järkevin ensimmäinen askel.