Digitális látogatói kalauz vagy saját alkalmazás? Költségek és szempontok az észszerű választáshoz

Először azt kell meghatározni, hogy milyen problémát oldjon meg a digitális látogatói kalauz. A látogatók nem értik a kiállítási tárgyak hátterét? Hiányoznak a nyelvi változatok, a hanganyagok vagy egy családi útvonal? A tartalmak gyorsan elavulnak? Vagy az intézmény a látogatás után is szeretné tartani a kapcsolatot? Ezek az igények mind eltérő termékkört határoznak meg.

Önmagában attól, hogy van egy ikon az alkalmazásboltban, egyik probléma sem oldódik meg. Ez olyan, mintha egy szép vitrint rendelnénk, mielőtt eldöntenénk, mi kerüljön bele. Először érdemes leírni a felhasználási helyzeteket, a tartalmakat és a csapat munkafolyamatát, és csak ezután kiválasztani az eszközt.

A helyesen feltett kérdés tehát így hangzik: „Mi a legegyszerűbb módja annak, hogy a látogató a megfelelő helyen a megfelelő történetet kapja, és a csapatunk később tovább tudja fejleszteni azt?” A saját alkalmazás az egyik lehetséges válasz, de nem szabad automatikusan ezt választani.

Az első lehetőség egy egyszerű, QR-kóddal megnyitható weboldal. Néhány nyilvános leíráshoz jól használható, de az útvonalak, nyelvek, felvételek és munkatársak számának növekedésével gyorsan felmerül az igény egy tartalomkezelő felületre, analitikára és egységes navigációra.

A második út egy közösen használt platform. Az intézmény kész látogatói alkalmazást, nyilvános oldalakat és adminisztrációs felületet használ, miközben megőrzi saját profilját, tartalmait, kiállításait, útvonalait és jelzéseit. A több helyszín számára fejlesztett funkciókat nem kell minden intézménynek külön, a nulláról megrendelnie.

A harmadik lehetőség egy saját mobilalkalmazás a szükséges háttérrendszerrel együtt. A „saját” nem csupán eltérő gombszínt jelent. Általában magában foglalja a felhasználói élmény megtervezését, az iOS- és Android-alkalmazást, a szervert vagy felhőszolgáltatásokat, a tartalomkezelő felületet, az analitikát, a teszteket, a közzétételt és a későbbi frissítéseket.

• Egyszerű weboldal: kis terjedelem és kevés szerkesztési folyamat.
• Közösen használt platform: kész funkciók, saját tartalmak és gyors indulás.
• Saját alkalmazás: teljes ellenőrzés, de teljes felelősség is a termékért.

Egy alkalmazásnak nincs egységes ára, mert ez az elnevezés néhány képernyős katalógust és felhasználói fiókokkal, fizetéssel, térképpel, offline móddal és munkatársi felülettel rendelkező teljes rendszert egyaránt jelenthet. Támpontot adhatnak a Clutch ügyfelek által bemutatott projektekre vonatkozó adatai: a vizsgált munkák többsége 10 000 és 49 999 dollár közé esett, az átlagos költség azonban körülbelül 90 780 dollár, az átlagos projektidő pedig mintegy 11 hónap volt.

A GoodFirms 167 alkalmazásfejlesztő cég körében végzett kutatása egy egyszerű alkalmazás esetében körülbelül 24 830-59 150 dollárt, egy összetettebb megoldásnál pedig 59 508-137 150 dollárt jelzett. A Clutch és a GoodFirms adatai az alkalmazásfejlesztés általános piacát írják le. Nem jelentenek árajánlatot egy múzeumi kalauzra, és nem szabad őket mechanikusan egy adott intézménynek szóló ajánlatra átszámítani.

Az ajánlatok összehasonlításához határozzon meg egy közös, feltételezett terjedelmet: 10 állomás, két nyelv, egy útvonal és három év használat. Minden kivitelező ugyanarra a terjedelemre adjon árat, és jelezze, mi marad az intézmény feladata.

• QR-kódos weboldal: ellenőrizze a weboldal elkészítésének, tárhelyének és frissítéseinek költségét, valamint azt, hogyan szerkesztheti önállóan a tartalmakat.
• Előfizetéses platform: számoljon a bevezetéssel és a teljes időszak előfizetési díjával, a csomag korlátaival és az esetleges további díjakkal.
• Saját alkalmazás: vegye figyelembe a tervezést, az alkalmazás és az adminisztrációs felület fejlesztését, a közzétételt, az infrastruktúrát, a frissítéseket és a támogatást.

Minden változatnál adja hozzá a tartalmak és fordítások elkészítését, a jelzések gyártását, a csapat munkaidejét, valamint szolgáltatóváltás esetén az adatok exportálásának és átvitelének költségét. Válassza külön az egyszeri és az ismétlődő kiadásokat, és ellenőrizze, mely tételeket tartalmazza már az ár. Csak ilyen számítással hasonlítható össze a megoldások hároméves használata.

Az alkalmazás a közzététel napján nem válik befejezett kiállítási tárggyá. Az Apple és a Google változtatja a rendszereit, az alkalmazásboltok követelményeit, az adatvédelmi szabályokat és az eszközök képességeit. Frissíteni kell a programkönyvtárakat, javítani a hibákat, felügyelni a biztonságot, tesztelni az új verziókat, és reagálni arra, ha egy külső szolgáltatás működése megváltozik.

A GoodFirms szerint a karbantartás és támogatás éves átlagos költsége a fejlesztési költség körülbelül 25%-a, az új funkciók fejlesztése és a szoftver skálázása nélkül. Ez az alkalmazáspiac kutatásából származó általános támpont, nem egy múzeumi kalauz karbantartási díja. A támogatás terjedelmét és árát konkrét ajánlatban kell megerősíteni.

Ehhez járulnak a felhőszolgáltatások, a biztonsági mentések, a felügyelet, az elemzőeszközök, az üzenetküldés, a médiafájlok tárolása és a felhasználói támogatás. Kis forgalomnál az infrastruktúra költsége alacsony lehet, de a használattól függ. A Firebase és a hasonló szolgáltatások éppen azért biztosítanak kalkulátorokat, mert egyetlen rögzített összeg nem ír le minden esetet.

Az alkalmazásbolti fiókok önmagukban csak kis részét teszik ki a számlának: az Apple Developer Program szokásos díja évi 99 amerikai dollár, a Google Play-regisztráció pedig egyszeri 25 amerikai dollár. Az Apple jelzi, hogy az árak régiónként eltérhetnek. Több munkát igényel a verziók előkészítése, a tesztelés, a közzététel kezelése és a követelményeknek való folyamatos megfelelés.

• frissítések és az iOS, illetve az Android új verzióinak tesztelése
• biztonság, biztonsági mentések és hibafelügyelet
• tárhely, multimédia, üzenetek és más, használat alapján számlázott szolgáltatások
• alkalmazásboltok, felhasználási feltételek, adatvédelem és felhasználói bejelentések kezelése
• az adminisztrációs felület és új funkciók fejlesztése

Az intézmény lehet a látogató szombat délutánjának legfontosabb helyszíne, de ritkán az egyetlen intézmény, amelyet az év során felkeres. Az alkalmazás megkeresésére, telepítésére, az engedélyek elfogadására és a fiók létrehozására vonatkozó kérés általában akkor érkezik, amikor az ember már a pénztárnál vagy az első kiállítási tárgynál áll.

A saját alkalmazásnak ezért egyértelmű indokot kell adnia a telepítésre: egy többször használt funkciót, különleges látogatási módot, előre megvásárolt hozzáférést vagy olyan élményt, amely weboldalon nem biztosítható. A leírások és hanganyagok puszta jelenléte nem feltétlenül elegendő. Ha minden felkeresett hely külön alkalmazást követelne meg, a telefon képernyője hamar egy egész megye címereinek katalógusára hasonlítana.

A közös platform csökkenti ezt a küszöböt. A felhasználó egy korábbi látogatásról már ismerheti az alkalmazást, a nyilvános tartalmat pedig telepítés nélkül is megnyithatja. Az intézménynek továbbra is megmarad a saját felülete és márkája, de nem azt kéri a látogatótól, hogy a kapcsolatot egy újabb program letöltésével kezdje.

A közös platform legnagyobb értéke nem az, hogy minden hely egyformán néz ki. A lényeg azoknak a funkcióknak az újrafelhasználása, amelyeket nem érdemes külön-külön fejleszteni: bejelentkezés, nyelvi támogatás, hanganyagok, QR-kódok, útvonalak, akadálymentesség, analitika, értesítések és munkatársi alkalmazás. E funkciók elérhetősége a választott megoldástól és csomagtól függ, ezért konkrét ajánlatban kell ellenőrizni őket. Az intézmény elsősorban a saját tartalmaiba és a látogatás menetébe fektet be.

Amikor a rendszert egy új telefonverzióhoz igazítják, vagy javítják az akadálymentességét, abból minden intézmény profitál. A termék költsége sok ügyfél között oszlik meg ahelyett, hogy minden intézménynél külön számlaként jelentkezne. A modell a közös kiállítási infrastruktúrához hasonlít: a keret lehet szabványos, de a kép továbbra is a sajátunk marad.

A platform hálózati hatást is teremt. A felhasználó, aki egy skanzenben ismerte meg, később ugyanazt a profilt és kezelési módot használhatja egy botanikus kertben, várban vagy városi útvonalon. Az egyes intézmények számára ez alacsonyabb belépési küszöböt, a látogató számára kiszámíthatóbb élményt jelent.

A korlát a teljesen szokatlan funkciók tervezésében rendelkezésre álló kisebb szabadság. Cserébe a csapatnak nem kell saját kiadási ciklust, infrastruktúrát és minden új eszközzel való kompatibilitást kezelnie. Ez a kompromisszum sok kis és közepes méretű helyszín számára egyszerűen gazdaságosabb.

A legbiztonságosabb döntés a tényleges használaton alapul, nem egy tárgyalótermi bemutatón. A Live Story lehetővé teszi egy nyilvános profil, néhány vagy egy tucatnyi fontos állomás és egy útvonal elindítását külön informatikai projekt megkezdése nélkül. A Community vagy Lite csomag valódi próbaüzemként szolgálhat.

Néhány hét vagy hónap után az intézmény már többet tud: mely kódokat olvassák be, hallgatják-e az emberek a hanganyagokat, milyen nyelveket választanak, hol szakítják meg az útvonalat, és miről kérdezik a munkatársakat. Az is ellenőrizhető, hogy a csapatnak van-e ideje és megfelelő anyaga a tartalmak rendszeres fejlesztéséhez. Ez fontos, mert források és szerkesztői döntések nélkül még a legjobb alkalmazás sem ír jó történetet az intézmény helyett.

Ha a kész funkciók megoldják a problémát, nagyobb csomagra lehet váltani, és további útvonalakkal, hozzáféréssel, csoportokkal vagy kommunikációval bővíteni a szolgáltatást. Ha a próbaüzem valóban egyedi igényt tár fel, a teszt adatai sokkal megalapozottabb kiindulópontot adnak egy saját alkalmazás megrendeléséhez.

A saját alkalmazás nem rossz ötlet. A legjobb megoldás lehet egy olyan nagy intézmény vagy hálózat számára, amelynek egyedi folyamatai, erős márkája, sok visszatérő felhasználója és a terméket éveken át fejleszteni képes csapata van. Szükség lehet rá speciális eszközök, összetett AR-funkciók, szokatlan beltéri helymeghatározási igények vagy a platform által nem támogatott integrációk esetén.

Feltétel azonban, hogy a költségvetés ne csak az indulást fedezze. Szükség van egy intézményi termékfelelősre, a tartalomkészítés és jóváhagyás folyamatára, az adatokkal kapcsolatos felelősség meghatározására, támogatási tervre és a későbbi verziók finanszírozására. Ezek nélkül a saját alkalmazás hamar felújítás miatt bezárt digitális teremmé válhat.

Ha az igények többsége leírásokra, hanganyagokra, nyelvekre, QR-kódokra, útvonalakra, kvízekre, hozzáférésre és a látogatás utáni kapcsolattartásra vonatkozik, egy közösen használt platform általában gyorsabban és olcsóbban teszi elérhetővé a célt. A választásnak ráadásul nem kell véglegesnek lennie. A Live Story próbaüzeme megerősítheti egy nagyobb csomag létjogosultságát, vagy érveket szolgáltathat egy külön termék fejlesztése mellett.