Entwicklung einer Strategie für mobiles Marketing im Tourismus

In kei­ner Pro­gno­se für tou­ris­ti­sches Mar­ke­ting fehlt der­zeit das Wort Mobi­le. Dabei sind mobi­le Web­an­wen­dun­gen für den Tou­ris­mus viel­leicht sogar rele­van­ter, als ande­re Web­maß­nah­men. War­um? Ganz ein­fach: zum einen ist man im Urlaub an einem frem­den Ort, zum ande­ren benö­tigt man gera­de dort mehr Infor­ma­tio­nen als üblich. Nicht zu ver­ges­sen: über den gesam­ten tou­ris­ti­schen Pro­zess ist “Mobi­le” ein­setz­bar, manch­mal sogar an wich­tigs­ter Stel­le.

Tnooz stellt eine Über­sicht zur Ent­wick­lung einer Stra­te­gie für mobi­les Mar­ke­ting im Tou­ris­mus vor, die ich hier noch­mals gekürzt über­set­ze.

Schritt 1) Der Anwendungsfall

Es genügt nicht, eige­ne Zie­le zu defi­nie­ren. Sie kön­nen eine Rich­tung vor­ge­ben, sind aber nicht ent­schei­dend. Ent­schei­dend für den Erfolg der mobi­len Anwen­dung, ist der Anwen­dungs­fall des Kun­den. An wel­cher Stel­le sei­ner tou­ris­ti­schen Ent­schei­dun­gen kann die Anwen­dung dem Kun­den

  1. Zeit oder Geld spa­ren
  2. den Auf­ent­halt ver­bes­sern, oder
  3. die Nut­zung eines Ange­bo­tes erleich­tern?

Dabei müs­sen das Nut­zer­er­leb­nis und der Nut­zen zusam­men pas­sen. Eine Anwen­dung, die 5min spart und 3min in der Anwen­dung benö­tigt, passt z.B. nicht.
Erst wenn ver­schie­de­ne Anwen­dungs­fäl­le skiz­ziert sind, kön­nen die­se mit den Zie­len der Orga­ni­sa­ti­on abge­gli­chen wer­den. M.a.W.: die Zie­le des Kun­den sol­len mit den Zie­len der Orga­ni­sa­ti­on in Über­ein­stim­mung gebracht wer­den, wobei der Nut­zen des Kun­den die Ent­schei­dung bestimmt.

Um das zu errei­chen, soll­te man fol­gen­de Punk­te zu Beginn klä­ren:

  1. Wel­che Rol­le spielt Mobi­le wäh­rend des Urlaubs­le­bens­zy­klus? Wie unter­stützt oder erwei­tert Mobi­le die ande­ren Mar­ke­ting­ka­nä­le? In wel­chen Kon­tex­ten wird Mobi­le genutzt?
  2. Wo wird für den Kun­den der größ­te Nut­zen erzielt? Wor­auf wird fokus­siert?
  3. Kön­nen in der bestehen­den Kom­mu­ni­ka­ti­on Lücken gefüllt wer­den? Ein­fach den­ken: Erin­ne­rung an einen Spa­ter­min, Anzei­ge von Ver­spä­tun­gen etc.
  4. Wel­che Ver­hal­tens­än­de­run­gen sol­len erzielt wer­den? Z.B. Crossel­ling, Trans­ak­ti­ons­kos­ten durch Kun­den­selbst­be­die­nung sen­ken oder Pro­zess­ver­bes­se­rung.
  5. Geht es um kom­ple­xe Situa­tio­nen oder schnel­le Ent­schei­dun­gen?

Nicht zuletzt muss die Anwen­dung zur Mar­ke pas­sen. Wel­che Mar­ken­wer­te sol­len kom­mu­ni­ziert wer­den? (Anm.: Für mich die ers­te Fra­ge.)

Schritt 2) Entscheidung für die mobilen Endgeräte

Es gibt unzäh­li­ge End­ge­rä­te und alle sind unter­schied­lich. Des­to wich­ti­ger ist die Prio­ri­sie­rung. Hier sind eini­ge Para­me­ter zur Unter­schei­dung:

Hard­ware diver­si­ty:
Dif­fe­ren­ces in screen para­me­ters (size, color dep­th, ori­en­ta­ti­on, aspect ratio
Memory/memory size
Pro­ces­sing power
Input mode (key­board, touch screen, etc.)
Pre­sence of addi­tio­nal hard­ware (came­ra, acce­le­ro­me­ter, gyro­scope)
Con­nec­tivi­ty opti­ons (Blue­tooth, IR, GPRS, etc.)
Soft­ware diver­si­ty:
Plat­forms: dif­fe­ren­ces in platform/OS (Apple iOS, Goog­le Andro­id, Nokia (Sym­bi­an, Mee­go) RIM (Black­ber­ry OS, QNX) HP WebOS, Micro­soft Win­dows Pho­ne, Mobi­le Linux, etc.)
API stan­dards (MIDP 1.0, MIDP 2.0, etc.), optio­nal APIs, pro­prie­ta­ry APIs
Varia­ti­ons in access to hard­ware (e.g., full-screen sup­port, access to local sto­ra­ge)
Mul­ti­me­dia sup­port (e.g., video codecs such as H.264, Flash or WebM)
User pre­fe­ren­ces: lan­guage, style, etc., or acces­si­bi­li­ty requi­re­ments

Hardware:

  1. Bild­schirm: Auf­lö­sung, Anzahl der Far­ben, Aus­rich­tung
  2. Spei­cher­grö­ße
  3. Pro­zes­sor­ge­schwin­dig­keit
  4. Ein­ga­be­mög­lich­kei­ten
  5. Zusatz­ge­rä­te: GPS, Kame­ra, Sen­so­ren
  6. Netz­werk­op­tio­nen: W-Lan, GPRS, 3G, Blue­tooth

Soft­ware:

  1. Platt­for­men: Apple iOS, Goog­le Andro­id, Nokia (Sym­bi­an, Mee­go) RIM (Black­ber­ry OS, QNX) HP WebOS, Micro­soft Win­dows Pho­ne, Mobi­le Linux, etc.
  2. Schnitt­stel­len: MIDP 1.0, MIDP 2.0, etc., optio­na­le APIs, exklu­si­ve APIs
  3. Mög­lich­kei­ten, die Gerä­te­hard- und soft­ware auch zu nut­zen (Zugriff auf Spei­cher)
  4. Mul­ti­me­dia- Unter­stüt­zung (Flash, Video­co­decs)
  5. Nut­zer­prä­fe­ren­zen (Spra­che, Style)

Der ers­te Schritt zur Aus­wahl der Gerä­te ist die Bestim­mung der Nut­zer. So unter­schei­det sich die Nut­zung ver­schie­de­ner Plat­for­men nach Kon­ti­nent enorm. In Euro­pa sind Sym­bi­an, iOS und Andro­id vor­ne.

Schritt 3) Technologische Optionen

1. Anwen­dung vs. mobi­le Web

Die Wahl hängt natür­lich von den Anwen­dungs­fäl­len ab. Das mobi­le Web kann nur funk­tio­nie­ren, wenn man online ist, Sei­ten wer­den aber in vie­len Brow­sern dar­ge­stellt. Anwen­dun­gen hin­ge­gen nutz­ten die Gerä­te­hard­ware, funk­tio­nie­ren auch off­line — aber eben nur auf dem jewei­li­gen Gerät.

2. Cross­platt­form vs. Gerä­te­ent­wick­lung

Tnooz bie­tet hier eine Über­sicht zu den Vor- und Nach­tei­len, deren Über­set­zung ich mir spa­re, da sie zum einen für Pro­gram­mie­rer rele­vant ist und zum ande­ren unvoll­stän­dig.

Grund­sätz­lich bie­ten Cross­platt­form- Ent­wick­ler­werk­zeu­ge nur ein­ge­schränk­te Mög­lich­kei­ten, sind schnell über­di­men­sio­niert und teu­er, aller­dings kann gleich­zei­tig für iOS und Andro­id ent­wi­ckelt wer­den.

Bei der kon­kre­ten Gerä­te­ent­wick­lung ist es ent­spre­chend genau umge­kehrt. Die Erfah­rung lehrt der­zeit, daß Cross­platt­form nur bei recht ein­fa­chen Anwen­dun­gen Sinn macht. Ob die­se in den jewei­li­gen Appsto­res kon­kur­renz­fä­hig sind, hängt vom Wett­be­werb ab, muss aber in den meis­ten Fäl­len bezwei­felt wer­den.

Schritt 4) Entwicklung

1. Es ist ein Pro­dukt, kein Pro­jekt

Bei Erfolg kom­men vie­le Anwen­der gleich­zei­tig und in Echt­zeit — da kann eini­ges schief gehen. Umso wich­ti­ger ist es, Ent­wick­lungs­schrit­te von Beginn an zu pla­nen. Es bie­tet sich an, typi­sche Ele­men­te einer Pro­dukt­ent­wick­lung ein­zu­set­zen, aber auch die Aktua­li­sie­run­gen zu pla­nen. Zur Erin­ne­rung: spä­te­re  Erwei­te­run­gen sind sofort für alle Nut­zer live und bei Anwen­dun­gen sind Feh­ler deut­lich schlech­ter, weil lang­wie­rig, aus­zu­bes­sern, als bei Web­sei­ten. Typi­sche Schrit­te sind:

  1. Releaseter­mi­ne pla­nen (Ver­si­on 1.0, 2.o etc.)
  2. die zugrund­lie­gen­de mobi­le Archi­tek­tur sau­ber auf­set­zen
  3. Erwar­tungs­me­tho­den ordent­lich ein­set­zen (Zeit/Bud­get-Erwar­tun­gen)
  4. Meß­kri­te­ri­en zu Beginn bestim­men

2. Fle­xi­ble Ent­wick­lung

Die mobi­le Welt ist schnell. Metho­den der agi­len Soft­ware­ent­wick­lung (z.B. SCRUM) sind ange­ra­ten, um Ver­än­de­run­gen

  • im Nut­zer­ver­ha­ten
  • neu­en Tech­no­lo­gi­en und Platt­for­men
  • oder Ver­än­de­run­gen im Markt

per­ma­nent und von vorn­her­ein berück­sich­ti­gen zu kön­nen.

Schritt 5) Analysieren und Anpassen

Eine fle­xi­ble Stra­te­gie erfor­dert Anpas­sun­gen, die­se wie­der­um soll­ten anhand von Meß­kri­te­ri­en vor­ge­nom­men wer­den, die auch gemes­sen wer­den kön­nen. Ein­fa­che Bei­spie­le sind:

  1. Wie vie­len Nut­zer haben die App gela­den / die mobi­le Sei­te auf­ge­ru­fen?
  2. Wie oft wur­de sich ein­ge­loggt?
  3. Wie ist die Con­ver­si­on?
  4. Hat sich die Ziel­grup­pe ver­än­dert?
  5. Wo, wann und wie sind wel­che Funk­tio­nen am belieb­tes­ten?
  6. Wur­den die Umsatz­zie­le erreicht?
  7. Hat sich die Kun­den­zu­frie­den­heit ver­än­dert?

Das Ori­gi­nal stammt von Ness Soft­ware Pro­duct Labs und kann hier als White­pa­per gela­den wer­den.

Zum gleichen Thema

2 Kommentare bei „Entwicklung einer Strategie für mobiles Marketing im Tourismus“

  1. GoApp hat 10 Basis­re­geln, die hier gut rein­pas­sen:

    http://www.wuv.de/nachrichten/digital/die_10_app_regeln_von_rainer_huether

    1. Ziel­grup­pe röng­ten: Wen will ich anspre­chen, wel­che Erfah­rung hat mei­ne Ziel­grup­pe mit Apps, wel­cher Mehr­wert könn­te die poten­zi­el­len Nut­zer inter­es­sie­ren? Hüt­her emp­fiehlt einen Blick in die Stu­die „Mobi­le Effects” (http://www.wuv.de/nachrichten/digital/studie_ipad_nutzer_zahlen_eher_fuer_journalistische_inhalte) von Tomor­row Focus Media.
    2. Kon­kur­renz­ana­ly­se aus­beu­ten: Mit­be­wer­ber-Apps als Min­dest­ent­wick­lungs­stand, Blick nach USA, iTu­nes-Store + Rezen­sio­nen dort kon­ti­nu­ier­lich scree­nen
    3. Ziel­de­fi­ni­ti­on akzep­tie­ren: Kla­res Erwar­tungs­ma­nage­ment (was soll App Unter­neh­men brin­gen? Mar­ke­ting­s­in­ves­ti­ti­on oder Refi­nan­zie­rung über Pay-Modell? Down­load­zie­le fest­le­gen)
    4. Kon­zept zemen­tie­ren: soli­des, defi­ni­ti­ves Kon­zept; und sehr wich­tig: rea­lis­ti­sches Upload- und Ver­öf­fent­li­chungs­ti­ming (Apple prüft und hat Recht abzu­leh­nen: 20 Tage ein­pla­nen, wer auf Num­mer Sicher gehen will)
    5. Keep it super­simp­le: Begrenz­te Flä­che, des­halb: statt Über­frach­tung lie­ber wei­te­re App; pro­fes­sio­nel­le Gra­fi­ken; ganz wich­tig: das Icon (hier muss erkenn­bar sein, das ist mei­ne Mar­ke!)
    6. Usa­bi­li­ty kopie­ren: zen­tra­le Über­le­gung: What would Apple do? Nicht Neu­es durch­set­zen wol­len, Lern­be­reit­schaft der Nut­zer ist ganz gering!
    7. No crashs ris­kie­ren: Apps mehr­fach tes­ten und ehr­li­che Aus­sa­gen im App-Store, wenn Anwen­dung nicht auf frü­he­ren Gerä­ten läuft
    8. Aktua­li­tät garan­tie­ren: App kon­ti­nu­ier­lich upgraden, Anre­gun­gen aus Rezen­sio­nen auf­neh­men
    9. Mar­ke­ting for­cie­ren: Blog-und Soci­al Media-Mar­ke­ting, Pres­se­ar­beit, Online und redak­tio­nel­le Ein­bin­dung
    10. Dran blei­ben: wenn App ver­al­tet, raus aus Store damit und neue ent­wi­ckeln

  2. […] Idea” haben und Ihr Hosen­ta­schen­hel­fer mehr kann als Goog­le (Maps), dann gibt’s drü­ben bei KMTO ein paar gute Tipps zum Vor­ge­hen bei der stra­te­gi­schen Kon­zep­ti­on. […]

Schreibe einen Kommentar