Mobiilisovellus vai mobiilisivusto — kumpi yritykselle?

Kysymykseen vastaa kolme kysymystä, ei budjetti. Tässä päätössääntö, vertailu rivi riviltä ja se osuus, joka unohtuu tarjousvaiheessa: mitä sovellus maksaa vuodessa julkaisun jälkeen.

Mustafa Tarabya, VectaAI:n perustaja, DT Nova Tmi. Yhteystiedot ja suora numero.

Päätössääntö: rakenna natiivi mobiilisovellus vain, jos tarvitset vähintään yhtä kolmesta asiasta: push-viestit, toiminnan verkkoyhteydettä tai puhelimen anturit (kamera skannerina, sijainti taustalla, NFC, terveysdata). Jos et tarvitse mitään näistä, mobiilisivu tekee saman halvemmalla, päivittyy samana päivänä eikä vaadi asiakasta lataamaan mitään. Suurin osa pienyrityksistä, jotka pyytävät sovellusta, tarvitsee itse asiassa nopean mobiilisivun.

Kysymys tulee yleensä muodossa "pitäisikö meidän tehdä oma sovellus". Vastaus on melkein aina jompikumpi kahdesta, eikä se riipu budjetista vaan siitä, mitä sovelluksen pitäisi tehdä. Ero on tekninen ja yksiselitteinen: mobiilisivu on verkkosivu, joka on rakennettu toimimaan puhelimessa. Sovellus on ohjelma, joka asennetaan puhelimeen kaupasta ja jolla on pääsy puhelimen omiin ominaisuuksiin.

Tämä sivu antaa päätössäännön, jolla vastaus löytyy noin viidessä minuutissa, ja kertoo mitä kumpikin vaihtoehto käytännössä maksaa ylläpidossa — se on se kohta, jossa moni yllättyy vasta jälkikäteen.

Kolmen kysymyksen testi

Sovelluksen ja mobiilisivun välinen valinta ratkeaa kolmella kysymyksellä, jotka koskevat push-viestejä, verkotonta käyttöä ja puhelimen antureita. Vastaa niihin rehellisesti: yksikin kyllä riittää perusteluksi natiivisovellukselle, mutta pelkkä "olisi kiva" ei ole kyllä. Testi toimii, koska nämä kolme ovat ainoat asiat, joita mobiilisivu ei pysty tekemään luotettavasti — kaikki muu, mitä sovellukselta yleensä odotetaan, onnistuu myös verkossa halvemmalla ja ilman latauskitkaa. Kirjaa vastaukset ylös, koska ne ovat myöhemmin tarjouspyyntösi runko riippumatta siitä, kumman tien valitset. Alla kolme kysymystä tarkennuksineen.

  1. Tarvitsetko push-viestin puhelimen lukitusnäytölle? Ei siis uutiskirjettä eikä tekstiviestiä, vaan ilmoituksen, joka ilmestyy näytölle ilman että asiakas avaa mitään. Tämä on sovelluksen ainoa aidosti korvaamaton myyntikanava. Kysy itseltäsi, mitä lähettäisit ja kuinka usein. Jos vastaus on "kerran kuussa tarjouksen", sähköposti riittää.
  2. Pitääkö sen toimia ilman verkkoa? Kentällä liikkuva asentaja, mittauskirjaus kellarissa, tilauksen otto huonon kuuluvuuden alueella. Jos työ pysähtyy silloin kun verkko katkeaa, tarvitset sovelluksen, joka tallentaa paikallisesti ja synkronoi jälkikäteen.
  3. Tarvitsetko puhelimen antureita jatkuvasti? Viivakoodin tai QR-koodin skannaus kymmeniä kertoja päivässä, sijainnin seuranta taustalla, NFC-leimaus, kameran käyttö osana työnkulkua. Yksittäinen kuvan lähetys onnistuu mobiilisivultakin — kyse on siitä, onko anturi työn ydin vai satunnainen lisä.

Jos vastasit kolme kertaa ei, lopeta lukeminen tähän ja tee mobiilisivu. Säästät rahaa ja kuukausia. Jos vastasit kerran kyllä, jatka.

Mikä mobiilisivun ja sovelluksen välillä oikeasti eroaa?

AsiaMobiilisivuNatiivisovellus
Miten asiakas löytääGoogle-haku, linkki, QR-koodiSovelluskaupan haku tai sinun oma markkinointisi
Käyttöönoton kitkaKlikkausLataus, mahdollinen tunnusten luonti
PäivitysJulkaiset, kaikki näkevät hetiUusi versio kauppaan, tarkistus, käyttäjä päivittää
Push-viestitRajoitetusti, ei luotettavasti kaikilla laitteillaKyllä
OfflineOsittain, haurasKyllä
AnturitKamera ja sijainti rajoitetustiTäysi pääsy
AlustatYksi toteutus kaikilleiOS ja Android erikseen tai yhteisellä tekniikalla
Jatkuva ylläpitoSivuston ylläpitoKehittäjätili, käyttöjärjestelmäpäivitykset, kauppojen sääntömuutokset

Taulukon viimeinen rivi on se, joka unohtuu tarjousvaiheessa. Sovellus ei ole kertaluontoinen hankinta. Apple ja Google julkaisevat uuden käyttöjärjestelmän vuosittain ja muuttavat sääntöjään useammin. Sovellus, jota ei kosketa kahteen vuoteen, alkaa hajota itsestään ja voi pudota kaupasta. Verkkosivu ei tee näin.

Mistä tiedämme tämän?

Olemme julkaisseet App Storeen 21 iOS-sovellusta, ja ne näkyvät julkisesti kehittäjäsivullamme. Se ei ole tässä myyntiargumenttina vaan siksi, että julkaisuputken kitkan oppii vasta tekemällä sen monta kertaa: tarkistusprosessin hylkäykset, tietosuojaselosteen vaatimukset, tilausten säännöt, ikärajat, kuvakaappausten muotovaatimukset. Nämä eivät näy koodissa mutta ne näkyvät aikataulussa. Siksi sanomme suoraan myös silloin, kun sovellusta ei kannata tehdä — sen ylläpito on meidän vastuullamme yhtä lailla kuin sinun kustannuksesi.

Kolme tapausta, joissa sovellus on oikea vastaus

Natiivisovellus on oikea vastaus kolmessa tapauksessa, ja kaikissa niissä täyttyy vähintään yksi kolmen kysymyksen testin ehdoista. Ne ovat kassalla käytettävä kanta-asiakkuus, kenttätyön kirjaus verkottomissa olosuhteissa ja toistuva käyttö, jossa push-viesti on osa prosessia eikä markkinointia. Kaikkia kolmea yhdistää se, että sovellus ei ole ulkoasukysymys vaan poistaa konkreettisen esteen: latausajan jonossa, verkkokatkon kellarissa tai viiveen tiedossa, jonka myöhästyminen maksaa. Jos oma käyttötapauksesi ei muistuta yhtäkään näistä kolmesta, kannattaa lukea myös seuraava osio ennen päätöstä. Alla tapaukset yksitellen.

Kanta-asiakkuus, jota käytetään kassalla. Leimakortti tai pistejärjestelmä, jonka asiakas avaa jonossa. Tässä sovellus voittaa siksi, että se aukeaa yhdellä painalluksella ja toimii, vaikka liikkeen sisällä ei olisi kenttää. Kanta-asiakasjärjestelmämme on päivittäisessä käytössä helsinkiläisessä thairavintolassa, ja juuri kassajonon nopeus on se syy, miksi siitä tehtiin sovellus eikä sivua. Vaihtoehdot on eritelty sivulla kanta-asiakassovellus.

Kenttätyön kirjaus. Asentajat, huoltajat, siivousreitit. Työ tapahtuu paikoissa, joissa verkko pätkii, ja kirjaus pitää tehdä silloin kun se tehdään, ei illalla toimistolla muistin varassa.

Toistuva käyttö, jossa push on prosessin osa. Vuoronvaihdot, hälytykset, tilauksen tila reaaliaikaisesti. Ei markkinointiviestintä, vaan tieto, jonka viivästyminen maksaa.

Kolme tapausta, joissa sovellus on väärä vastaus

Sovellus on väärä vastaus kolmessa tapauksessa, ja ne toistuvat pienyritysten sovellushankkeissa lähes samanlaisina. Ne ovat: sovellus on oikeastaan verkkosivu kehyksissä, asiakas asioi kanssasi vain pari kertaa vuodessa, tai tavoitteena on näyttää modernilta. Ensimmäisessä maksat kahdesti samasta sisällöstä ja lisäät asennuskitkan väliin. Toisessa sovellus poistetaan puhelimesta tilanpuutteen takia, ja samalla menetät push-kanavan, jonka takia se rakennettiin. Kolmannessa tavoite on aito mutta ei kanna vuosittaista ylläpitokustannusta. Käy kolme kohtaa läpi ennen tarjouspyyntöä, koska jokainen niistä on halvempi huomata nyt kuin julkaisun jälkeen.

Sovellus on oikeastaan verkkosivu kehyksissä. Jos sovelluksen sisältö on samat sivut kuin verkossa, olet maksanut kaksi kertaa samasta asiasta ja lisännyt yhden asennuskitkan asiakkaan ja sisällön väliin. Sovelluskaupat myös suhtautuvat tällaisiin julkaisuihin nihkeästi.

Asiakas asioi kanssasi kahdesti vuodessa. Kukaan ei pidä puhelimessaan sovellusta, jota käytetään kaksi kertaa vuodessa. Se poistetaan tilanpuutteen takia, ja olet menettänyt myös push-kanavan.

Tavoite on näyttää modernilta. Tämä on aito ja yleinen syy, mutta se ei kanna ylläpitokustannusta. Sama vaikutelma syntyy nopeasta, siististä mobiilisivusta murto-osalla rahasta.

Milloin kumpaakaan EI kannata ostaa juuri nyt?

Kumpaakaan ei kannata ostaa juuri nyt kolmessa tilanteessa, joissa oikea vastaus on odottaa: määrittely ei ole valmis, nykyiset verkkosivut ovat rikki puhelimessa, tai kukaan yrityksessä ei omista lopputulosta julkaisun jälkeen. Jos et osaa kertoa yhdellä lauseella, mitä käyttäjä tekee sovelluksessa ensimmäisen kolmenkymmenen sekunnin aikana, määrittely ei ole valmis. Silloin projekti muuttuu kalliiksi keskustelufoorumiksi, jossa maksat kehitystunneista sillä aikaa kun mietit, mitä halusit.

Toinen odotustilanne: nykyiset verkkosivusi ovat hitaat tai eivät toimi puhelimessa. Korjaa se ensin. Mobiilisivun kunnostaminen on halvempaa, ja se kertoo sinulle datalla, mitä asiakkaat oikeasti tekevät puhelimella. Se data on paras mahdollinen määrittelydokumentti, jos päädyt myöhemmin sovellukseen. Sivustopuolen perusteet ovat sivulla verkkosivut yritykselle.

Kolmas: jos yrityksessäsi ei ole ketään, joka omistaa sovelluksen sisällön julkaisun jälkeen — kuka vastaa arvosteluihin, kuka päättää seuraavan version sisällön — sovellus jää seisomaan. Seisova sovellus kerää huonoja arvosteluita, ja ne näkyvät jokaiselle, joka etsii yritystäsi kaupasta.

Välimuoto: asennettava verkkosovellus

Mobiilisivun ja natiivisovelluksen välissä on kolmas vaihtoehto: asennettava verkkosovellus. Verkkosivun voi rakentaa niin, että sen saa lisättyä puhelimen kotinäytölle ja se toimii osittain ilman verkkoa. Tämä ratkaisee osan offline-tarpeesta ja antaa sovellusmaisen ulkoasun ilman kauppoja. Kaksi rajoitusta kannattaa tietää etukäteen: push-viestit eivät toimi yhtä luotettavasti kaikilla laitteilla ja käyttöjärjestelmäversioilla, eikä käyttäjä löydä tällaista ratkaisua sovelluskaupasta.

Käytännön sääntö: välimuoto on hyvä valinta silloin, kun käyttäjät ovat tunnettu ja rajattu joukko — oma henkilökunta, sopimusasiakkaat — joille voit lähettää linkin ja asennusohjeen. Kuluttajamarkkinointiin se on huono, koska asennus pitää selittää.

Näin päätät viikossa

  1. Kirjoita käyttötapaus yhdellä lauseella "Asiakas tekee X kohdassa Y ja säästää Z." Jos lause ei synny, mitään ei kannata tilata vielä.
  2. Aja kolmen kysymyksen testi Push, offline, anturit. Kirjaa vastaukset ylös, ne ovat myöhemmin tarjouspyyntösi runko.
  3. Katso analytiikasta mobiilikäyttö Kuinka moni käyttää sivujasi puhelimella nyt ja mitä he tekevät. Tämä kertoo, onko kysyntää olemassa vai keksitäänkö sitä.
  4. Pyydä hinta molemmille Sama käyttötapaus, kaksi toteutustapaa. Ero on usein moninkertainen, ja se tekee päätöksen helpoksi. Pohjan pyyntöön saat sivulta tarjouspyyntöpohja.
  5. Päätä ylläpito ennen toteutusta Kuka päivittää, millä budjetilla, kuinka usein. Jos tähän ei ole vastausta, valitse mobiilisivu.

Toteutuksen laajuus ja tekniset vaihtoehdot on kuvattu sivulla sovelluskehitys, ja hinnat löytyvät kokonaisuudessaan hinnastosta. Emme pyydä tarjouspyyntöä hinnan näkemiseksi.

Mitä "hyvä mobiilisivu" tarkoittaa käytännössä?

Hyvä mobiilisivu tarkoittaa neljää konkreettista asiaa: nopeutta mobiiliverkossa, tärkeimmän toiminnon sijoittamista peukalon ulottuville, lyhyttä lomaketta ja yhteystietoja tekstinä eikä kuvana. Kun sanomme, että mobiilisivu riittää, emme siis tarkoita työpöytäsivua, joka sattuu mahtumaan puhelimen näytölle. Ero hyvän ja huonon mobiilisivun välillä on suurempi kuin ero hyvän mobiilisivun ja sovelluksen välillä, ja juuri se ratkaisee useimmiten sen, tuottaako sivu yhteydenottoja. Tästä seuraa myös päätöksen kannalta olennainen asia: jos nämä neljä eivät ole kunnossa, sovellus ei korjaa mitään. Alla jokainen neljästä erikseen.

Neljä asiaa, joista se koostuu. Ensinnäkin nopeus: sivun pitää näyttää jotain hyödyllistä sekunneissa mobiiliverkossa, ei toimiston valokuidulla mitattuna. Toiseksi peukalon ulottuvuus: tärkein toiminto — soita, varaa, tilaa — on näytön alaosassa eikä ylhäällä valikon takana. Kolmanneksi lomakkeen lyhyys: jokainen kenttä pudottaa täyttäjiä, ja puhelimella se tuntuu moninkertaisesti. Neljänneksi se, että yhteystiedot ja aukioloajat ovat tekstinä eivätkä kuvassa, koska niitä haetaan puhelimella useammin kuin mitään muuta.

Jos nämä neljä ovat kunnossa, valtaosa niistä hyödyistä, joita sovellukselta odotetaan, on jo saavutettu. Jos ne eivät ole kunnossa, sovellus ei korjaa mitään — se vain siirtää saman ongelman paikkaan, johon asiakas pääsee vasta latauksen jälkeen.

Auki laskettu esimerkki: kanta-asiakasetu

Kanta-asiakasetu on hyvä esimerkki siitä, miten valinta lasketaan auki etukäteen. Sanotaan, että liikkeessä käy 400 asiakasta kuussa ja haluat rakentaa kanta-asiakasedun. Se voidaan toteuttaa kahdella tavalla: verkkopohjaisena leimakorttina, jonka asiakas avaa tiskillä QR-koodista, tai ladattavana sovelluksena, joka jää asiakkaan puhelimeen ja tuo mukanaan push-kanavan. Ero ei ole tekniikassa vaan siinä, kuinka moni asiakas lataa sovelluksen ja mitä tuo joukko tuottaa kuukaudessa. Alla molemmat vaihtoehdot sekä laskun rakenne, jolla vertailun voi tehdä omilla katteillasi ennen kuin tilaa mitään.

Verkkopohjainen leimakortti: asiakas skannaa QR-koodin tiskillä, sivu aukeaa selaimeen, leima kirjautuu. Ei latausta, toimii heti, mutta asiakas tarvitsee linkin joka kerta tai lisää sen kotinäytölle itse. Käyttöönotto on nopea ja kustannus pieni. Vertailu vaihtoehdoista on sivulla leimakortti.

Sovellus: asiakas lataa kerran, sen jälkeen kortti on aina taskussa ja voit lähettää push-viestin hiljaisena päivänä. Lataus on kertakitka, joka karsii osan asiakkaista pysyvästi — ja juuri tämä osuus kannattaa arvioida etukäteen. Jos oletat, että joka neljäs 400 asiakkaasta lataa, sinulla on sadan hengen push-lista. Kysy itseltäsi, mitä sadan hengen lista tuottaa kuukaudessa, ja vertaa sitä sovelluksen vuosikustannukseen. Emme kerro sinulle vastausta, koska se riippuu katteestasi. Laskun rakenne on kuitenkin aina tämä, ja sen voi tehdä ennen kuin tilaa mitään.

Huomaa myös kolmas vaihtoehto, joka jää usein miettimättä: aloita verkkopohjaisesta, mittaa puoli vuotta kuinka moni etua käyttää, ja tee sovellus vasta jos käyttäjämäärä perustelee sen. Tässä järjestyksessä maksat sovelluksesta vasta, kun tiedät sille olevan kysyntää.

Usein kysyttyä

Voiko sovelluksen tehdä kerralla sekä iPhonelle että Androidille?

Voi, yhteisellä tekniikalla suuri osa koodista on jaettua. Se ei kuitenkaan tarkoita, että työ olisi puolet halvempi: julkaisu, testaus ja kauppojen vaatimukset ovat kaksi erillistä prosessia kummallekin alustalle. Katso iOS-sovellus ja Android-sovellus.

Kuinka kauan App Store -julkaisu kestää?

Itse tarkistus on nykyään yleensä nopea, mutta ensimmäinen julkaisu venyy lähes aina hylkäyksistä: puuttuva tietosuojaseloste, epäselvä tilausehto, kuvakaappaukset väärässä koossa, käyttötarkoitus jota tarkistaja ei ymmärrä. Varaa ensimmäiseen julkaisuun viikkoja, älä päiviä, ja tee kaupan aineisto valmiiksi samaan aikaan kuin koodia.

Näkyykö sovellus Googlessa?

Sovelluksen sisältö ei näy hakukoneessa samalla tavalla kuin verkkosivu. Jos hakukonenäkyvyys on tavoite, tarvitset sivuston joka tapauksessa — sovellus ei korvaa sitä. Tämä on yksi yleisimmistä väärinkäsityksistä, ja se kannattaa tarkistaa ennen päätöstä.

Mitä sovellus maksaa ylläpitää vuodessa?

Kuluja tulee vähintään kehittäjätilistä, ja lisäksi vuosittaisista käyttöjärjestelmäpäivityksistä, jotka vaativat käytännössä aina jonkin verran korjaustyötä. Budjetoi ylläpito etukäteen prosenttiosuutena toteutuksesta, älä nollana. Tarkat luvut ovat hinnastossa.

Entä jos asiakas ei suostu lataamaan sovellusta?

Tämä on todennäköisin yksittäinen epäonnistumisen syy, ja siksi lataussyy kannattaa testata ennen rakentamista: kysy kymmeneltä asiakkaalta suoraan, latasivatko he. Jos vastaus on epäröivä, rakenna mobiilisivu ja katso käyttöä puoli vuotta ennen kuin päätät uudelleen.

Lue seuraavaksi

Lue myös: Verkkokaupan perustaminen: hinta, vaihtoehdot ja todellinen kululista · Tietosuojaseloste-malli pienyritykselle · Liiketoimintasuunnitelman pohja ja laskelmat · IT-konsultointi pienyritykselle · Tekoälykonsultointi pienyritykselle · Digitalisaatio pienyritykselle · Liikkeenjohdon konsultointi pienelle yritykselle · Google-yritysprofiili: tee itse ilmaiseksi tai anna meidän hoitaa se

Soita WhatsApp Demo