Tässä artikkelissa
Paikallinen verkkotoimisto, kassajärjestelmätoimittajasi tai franchise-konsultti kysyy ennemmin tai myöhemmin saman kysymyksen: haluatko oman sovelluksen? Vastaus, jonka saat, on lähes aina tunnepitoinen — "ole siellä missä asiakkaasikin on" — ja lähes koskaan laskettu paperilla. Tämä artikkeli laskee sen, käyttäen lukuja, jotka sovellusala itse julkaisee.
Natiivisovellus kuulostaa loogiselta jatkolta verkkosivustollesi: asiakkaasi tilaa jo ruudulta, joten miksei myös puhelimen kuvakkeesta? Itse ajatus ei ole ongelma. Se, mitä tapahtuu seuraavaksi, on — ja tätä osaa harvoin mainitsee se, joka myy sinulle sovellusta.
Mobiilisovellusala on mitannut jo kymmenen vuotta täsmälleen sitä, mitä asennukselle tapahtuu: kuinka moni avaa sen, kuinka moni on vielä mukana kuukauden jälkeen, kuinka moni palaa kolmen kuukauden jälkeen. Nämä luvut ovat vankkoja, julkisia ja huomattavan yhdenmukaisia — eikä niitä ole lähes koskaan sovellettu yhteen ainoaan ravintolaan.
Tämä artikkeli tekee juuri niin, neljällä luvulla: mitä sovellus todella maksaa rakentaa ja pitää käynnissä, kuinka suuri osa omista asiakkaistasi asentaa sen realistisesti, kuinka moni heistä avaa sen vielä 30 ja 90 päivän jälkeen, ja — kysymys, joka todella ratkaisee — kuinka monta lisäkäyntiä tarvitaan ennen kuin se maksaa itsensä takaisin. Lopussa syötä omat lukusi laskuriin, joka käyttää täsmälleen samaa matematiikkaa kuin muu artikkeli.
Johtopäätös ei ole "ei koskaan" eikä "aina". Yhden toimipisteen itsenäiselle yritykselle vastaus on lähes aina ei — alla olevat luvut näyttävät tarkalleen miksi. Useamman toimipisteen ketjulle tai kotiinkuljetuspainotteiselle konseptille, jolla on aitoa toistuvaa tilausvolyymiä, sama laskelma voi kääntyä toisin. Ero ei ole kunnianhimossa, vaan mittakaavassa.
Kattavin opas Ravintolateknologia: 6 Askelta 7 Työkalusta 1 Järjestelmään Yksittäisestä kassasta yhteen integroituun järjestelmään: täydellinen opas teknologiavalintoihin, jotka todella kannattavat. Avaa opas1. Mitä sovelluksen rakentaminen maksaa — ja sen jatkuva maksaminen
Tarjous "yksinkertaisesta" tilaus- ja kanta-asiakassovelluksesta yhdelle toimipisteelle vaihtelee erikoistuneilla toimistoilla karkeasti 8 000–25 000 € välillä, riippuen siitä, kuinka paljon nykyistä järjestelmääsi täytyy rakentaa sisään. Kun mukaan lisätään varaukset, kuljetusten seuranta tai laajempi kanta-asiakasohjelma, hinta nousee nopeasti kohti 40 000–80 000 €:a — ja siihen lasku vasta alkaa. Vertaa tätä rehellisesti siihen, mitä sinulla jo on listalla ohjelmistotilauksia: sovellus on harvoin ensimmäinen kustannus, jonka haluat lisätä.
Rakennuskustannuksen päälle tulee kaksi toistuvaa kustannusta, joita mikään tarjous ei mainitse ensimmäisenä. Apple veloittaa noin 92 € vuodessa kehittäjätilistä, ilman jota mikään iOS-sovellus ei koskaan pääse julkaistuksi — jätä vuosi maksamatta, ja sovelluksesi katoaa App Storesta, käyttipä sitä kuinka moni asiakas tahansa jo. Google veloittaa kertaluontoisesti 23 € Play Console -tilistä. Pieni summa, mutta se on ensimmäinen monista: jokainen suurempi iOS- tai Android-päivitys pakottaa uuden tarkastuskierroksen, ja kaksi vuotta päivittämättä jäänyt sovellus lopulta hylätään tai katoaa yksinkertaisesti kaupasta löytymättömiin.
On kaksi halvempaa reittiä, ja molemmat ansaitsevat rehellisen maininnan ennen kuin jatkat lukemista. Progressiivinen web-sovellus (PWA) — "lisää aloitusnäytölle" suoraan nykyiseltä verkkosivustoltasi — maksaa murto-osan natiivisovelluksesta, koska mukana ei ole App Store -tarkastusta, kahta erillistä koodikantaa eikä vuosittaista Apple-laskua. Ja jos varaus- tai tilausjärjestelmä, jota jo käytät, tarjoaa sovelluksen sisäänrakennettuna ominaisuutena, sen rajakustannus on nolla: maksat siitä jo, käytätpä sitä tai et.
Lasketaan yhteen: 100 € vuodessa Applelle, 26 € kertaluontoisesti Googlelle — ennen kuin yhtään koodiriviä on kirjoitettu, eikä mitään takeita siitä, että yksikään asiakas koskaan avaa lopputulosta.
2. Kuinka moni asiakkaistasi todella asentaa sen
Kysy sovellustoimistolta asennusastetta, ja vastaus jää epämääräiseksi: "riippuu". Kysy kanta-asiakasalustoilta, jotka rakentavat itsenäisiä ravintolasovelluksia, niiden omia lukuja, ja vastaus tarkentuu — mutta se on luku, jolla on osoite. Kanta-asiakassovellusten toimittajat raportoivat tyypillisesti 10–20 % asennusasteen, ja tämä osuus mitataan heidän parhaista asiakkaistaan: ihmisistä, jotka ovat jo vakioasiakkaita. Se on sama ansa kuin itsepalvelukioskeissa: houkutteleva teknologia, joka kannattaa vain hyvin tietylle osalle asiakkaitasi.
Siinä on ongelma. Tuo 10–20 % ei ole osuus kaikista asiakkaistasi, se on osuus vakioasiakkaistasi — ja vakioasiakkaat itsessään ovat jo vähemmistö. Ravintola-alan tutkimukset asettavat johdonmukaisesti niiden asiakkaiden osuuden, jotka eivät koskaan palaa, noin 70–77 %:iin, ja liittävät noin 65–80 % liikevaihdosta palaaviin asiakkaisiin. Toisin sanoen: ryhmä, joka edes on ehdolla asentamaan sovelluksen, on itsessään vain viidesosa neljäsosaan koko asiakaskunnastasi.
Pinoa nämä kaksi lukua päällekkäin, ja osuus KOKO asiakaskunnastasi, joka asentaa sovelluksen, putoaa muutamaan prosenttiin — ei kymmeneen, saati kahteenkymmeneen. Tuhannesta asiakkaasta se on karkeasti kaksisataakaksikymmentä vakioasiakasta, joista noin joka seitsemäs asentaa sovelluksen: kolmekymmentäkolme ihmistä. Se on realistinen lähtökohta, ei tarjouksen optimistinen luku.
1 000 asiakkaalla, yllä olevilla osuuksilla. Jokainen palkki on edellisen vaiheen osuus.
Nämä ovat ohjeellisia lukuja, ei laki: paikka, jolla on aidosti uskollisia kotiinkuljetusasiakkaita, saavuttaa korkeamman vakioasiakasosuuden, turisteja paljon saava alemman. Kaava — jyrkkä suppilo asiakkaasta asennukseen ja aktiiviseen käyttöön — pätee lähes joka tutkimuksessa.
3. Kuka avaa sovelluksen vielä 30 ja 90 päivän jälkeen
Asennus ei ole käyttäjä. Mobiilisovellusala on mitannut tätä vuosia kohorttikäyrillä — kuinka moni nollapäivänä asentaneista palaa myöhemmin — ja kaava on huomattavan yhdenmukainen sovelluskategoriasta riippumatta. Business of Apps ja Adjust raportoivat vuodelle 2026 keskimääräisen päivän 1 säilyvyyden noin 25 %:iin: kaikista asentajista noin joka neljäs avaa sovelluksen koskaan toisen kerran.
Siitä eteenpäin pudotus kiihtyy. Samat lähteet asettavat keskimääräisen päivän 30 säilyvyyden 5–7 %:iin, ja siihen mennessä yli 90 % kaikista käyttäjistä on jo hylännyt sovelluksen. Päivään 90 mennessä — hetkeen, jolloin toisen käynnin alennuksen pitäisi todella alkaa kannattaa — säilyvyys useimmissa kategorioissa liikkuu 3–5 % välillä. Tämä ei ole yhden huolimattoman kehittäjän epäonni; se on keskiarvo tuhansista sovelluksista kymmenissä kategorioissa.
Käänna tämä edellisen luvun kolmeenkymmeneenkolmeen asennukseen, ja kolme kuukautta myöhemmin jäljellä on karkeasti yksi aktiivinen käyttäjä. Ei yksi kolmestakymmenestäkolmesta prosentista — yksi ihminen. Se on todellisuus ilmauksen "rakennamme sovelluksen, jotta asiakkaat palaavat" takana: todennäköisyys, että satunnainen asiakas avaa sen vielä päivänä 90, on lähellä yhtä tuhannesta.
4. Kuinka monta lisäkäyntiä tarvitaan, jotta kulut kuittautuvat
Sovellus maksaa itsensä takaisin vain, jos aktiivinen käyttäjä käy useammin kuin olisi käynyt ilman sitä — ei useammin kuin keskimäärin, vaan useammin kuin olisi joka tapauksessa tullut. Tätä eroa ei ole missään julkaistussa alan standardissa: mikään raportti ei kerro, kuinka monta lisäkäyntiä yksi sovelluksen käyttäjä todella tuottaa, koska se vaihtelee paikan, konseptin ja tarjonnan mukaan.
Sen, minkä tiedämme, voimme asettaa vastakkain. Ota rakennuskustannus, jaa se keskimääräisellä käyntikohtaisella kulutuksellasi, ja saat kokonaismäärän lisäkäyntejä, jotka sovelluksen täytyy tuottaa maksaakseen itsensä takaisin. Jaa se uudelleen 90 päivän jälkeen jäljellä olevien aktiivisten käyttäjien määrällä, ja käy selväksi, kuinka monta lisäkäyntiä kuukaudessa kunkin jäljellä olevan käyttäjän pitäisi tehdä — luku, joka tavalliselle paikalle osoittautuu täysin epärealistiseksi.
Keskikokoiselle itsenäiselle yritykselle takaisinmaksuaika venyy vuosikymmeniin. Ei siksi, että sovellus olisi arvoton, vaan siksi, että ihmisten määrä, jotka vielä käyttävät sitä päivään 90 mennessä, on liian pieni kantamaan tuhansien eurojen rakennuskustannusta — vaikka jokainen jäljellä oleva käyttäjä osoittautuisikin epätodennäköisen uskolliseksi.
Sama paikka, samat asennus- ja säilyvyysasteet, kolme tapaa saada sovellus.
PWA-palkki olettaa samat asennus- ja säilyvyysasteet kuin natiivisovellus — vain rakennuskustannus eroaa. Todellisuudessa kynnys napauttaa "lisää aloitusnäytölle" on matalampi kuin sovelluskaupasta lataaminen, joten tämä on pikemminkin alaraja sille, kuinka nopeasti PWA maksaa itsensä takaisin kuin yläraja.
Laske se omalle paikallesi
Yllä olevat luvut ovat keskiarvoja. Syötä oma asiakaskuntasi, kulutuksesi ja tarjouksesi — kaikki lasketaan paikallisesti selaimessasi.
—
"Lisäkäynnit kuukaudessa sovelluksen ansiosta" on ainoa oletus tässä ilman julkaistua lähdettä — syötä se mieluummin varovasti kuin toiveikkaasti. Kaikki lasketaan paikallisesti selaimessasi; mitään ei lähetetä tai tallenneta.
Milloin laskelma todella toimii
Yllä oleva laskelma on kirjoitettu paikalle, jollaista useimmat tämän artikkelin lukijat pyörittävät: yksi toimipiste, muutama tuhat asiakasta, tarjous kymmenien tuhansien eurojen luokkaa. Muuta tätä mittakaavaa, ja johtopäätös voi kääntyä — ei siksi, että säilyvyyskäyrä muuttuisi, vaan siksi, että rakennuskustannus ei kerry toimipistettä kohden, kun taas asiakaskunta kertyy.
Ota kotiinkuljetuspainotteinen konsepti, jolla on useita toimipisteitä ja yhteinen asiakaskunta noin 50 000 ihmistä, korkeampi tilaustiheys ja suurempi vakioasiakasosuus kuin keskimääräisellä ravintolalla — realistista yritykselle, joka kuljettaa säännöllisesti eikä vastaanota asiakkaita satunnaisesti. Sama sovellus, sama tarjous noin 55 000 €, mutta nyt jaettuna paljon suuremmalle aktiivisten käyttäjien joukolle.
Yhtä varovaisilla asennus- ja säilyvyysoletuksilla tuo sovellus maksaa itsensä takaisin noin 10 kuukaudessa — vuosikymmenten sijaan. Ero ei ole sovelluksessa, se on nimittäjässä: tässä mittakaavassa aktiivisia käyttäjiä jää tarpeeksi kantamaan rakennuskustannuksen; yhdellä itsenäisellä paikalla ei.
Mitä tehdä ennen allekirjoitusta
Tarjouksen allekirjoittaminen maksaa yhden nimikirjoituksen. Nämä kolme vaihetta maksavat tunnin, ja ne ratkaisevat, säästääkö vai maksaako se allekirjoitus.
Ennen kuin pyydät tarjousta
- Laske, kuinka moni asiakkaistasi on todella vakioasiakas — ihmisiä, jotka palaavat vähintään kuukausittain. Tämä luku, ei koko asiakaskuntasi, on se, mille sovellus todella rakennetaan.
- Kysy itseltäsi yksi asia: mitä sovellus tekee, mitä WhatsApp-postituslista, ilmainen kanta-asiakaskortti tai kirjanmerkki aloitusnäytöllä ei voi tehdä? Jos rehellinen vastaus on "ei mitään konkreettista", sovellus on kallis tapa tehdä sama asia.
- Avaa yllä oleva laskuri omilla luvuillasi ennen kuin puhut toimiston kanssa — silloin tiedät, minkä vastauksen tarjouksen täytyy sinulle antaa, ei toisin päin.
Jos silti rakennat
- Aloita PWA:sta, ei natiivisovelluksesta. Jos sitä todella käytetään puolen vuoden jälkeen, sinulla on näyttö ennen kymmenkertaisen investoinnin tekemistä.
- Laita sovellukseen ensimmäisestä päivästä lähtien konkreettinen etu, jota ei ole muualla — leimakortti, joka täyttyy vain siellä, ruoka-annos, joka näkyy ensin vain siellä. Ilman syytä pitää se auki, yllä oleva kohorttikäyrä toistuu täsmälleen.
- Varaa 15–20 % rakennuskustannuksesta vuodessa ylläpitoon ja kaupan päivityksiin — se ei ole lisä, se on hinta pysyä käytössä.
Halvempi reitti
- Tarkista ensin, tarjoaako varaus- tai tilausjärjestelmä, jota jo käytät — tai harkitset — sovelluksen jo ominaisuutena, muun automaation ohella, jota se jo antaa sinulle. Silloin rajakustannus on nolla.
- Vertaa tätä maksutonta reittiä rehellisesti tarjoukseen: samat push-ilmoitukset, sama kanta-asiakasintegraatio, ilman erillistä Apple-laskua.
- Lue, mitä tällainen sisäänrakennettu sovellus konkreettisesti tarjoaa oman sovelluksemme tuotesivulta — sama kysymys, ilman toimistoa välissä.
Ei ei, ei kyllä — laskelma
Lähes jokainen yrittäjä, joka lukee tämän artikkelin, tunnistaa tunteen, että sovellus kuuluu "moderniin paikkaan". Se tunne ei ole väärä — se ei vain ole rahoitusmalli. Yllä olevat neljä lukua näyttävät, mitä tapahtuu tarjouksen ja ensimmäisen vuositilinpäätöksen välillä: jyrkkä suppilo asiakkaasta asennukseen ja aktiiviseen käyttöön, ja rakennuskustannus, joka pitää jakaa liian harvalle jäljelle jääneelle käyttäjälle.
Keskikokoiselle itsenäiselle yritykselle vastaus on lähes aina: ei nyt, ei natiivina, ei tuohon hintaan. Se ei ole tuomio kunnianhimolle — se on se, mitä koko sovellusalan kohorttikäyrät ennustavat, sovellettuna yhteen ravintolaan massayleisön sijaan.
Se, mikä toimii, on sama vaisto — olla lähempänä asiakasta — ilman rakennuskustannusta, kaupan laskua ja vuosittaista päivitysvelvoitetta. Oma sovelluksemme on juuri tämä reitti: sama ominaisuus, osana järjestelmää, jota jo käytät, ilman toista laskua toimistolta.