O aplicație pentru o firmă de servicii (curățenie, service auto, instalații, un cabinet) trebuie să facă bine trei lucruri legate între ele: clientul își alege singur ora, primește mesajul potrivit la momentul potrivit și plătește fără să caute bani prin buzunare. Restul e opțional. Pentru fiecare dintre cele trei există reguli de la Apple, Google și UE pe care e bine să le știi înainte să desenezi primul ecran.
Programările: ore reale, nu un formular
Cea mai mare diferență față de un formular de contact: clientul vede doar orele libere, din același calendar pe care îl vede angajatul. Nu „ne trimiteți o cerere și revenim”, ci „joi la 10:00, confirmat”.
Pentru asta, aplicația trebuie să știe câteva lucruri despre fiecare serviciu: cât durează, cine îl poate face și, dacă echipa merge la client, cât timp îi trebuie între două adrese. Apoi clientul trebuie să poată anula sau muta programarea singur, dintr-un link, fără să sune. Am scris pe larg despre ce face prima versiune a unei astfel de aplicații în articolul despre aplicația de programări.
Notificările: cerute după prima programare
Aici sunt două reguli de știut.
Pe Android 13 și mai nou, o aplicație instalată de la zero are notificările oprite. Trebuie să ceară permisiunea, iar Google recomandă să o ceri în context, după o acțiune a omului, nu la prima deschidere. Exemplul lor e chiar o comandă: omul trimite comanda, apoi îl întrebi dacă vrea să fie anunțat.
Pe iPhone, regulile App Store spun că notificările nu pot fi obligatorii ca aplicația să funcționeze. Iar pentru promoții ai nevoie de acordul explicit al omului, cerut în aplicație, și de o cale de a renunța.
Practic, întrebarea vine după prima programare: „Vrei să te anunțăm cu o zi înainte și când echipa e pe drum?” Atunci are sens pentru om. Notificările care merită trimise sunt puține: confirmarea, reminderul cu o zi înainte, „suntem pe drum”, orice schimbare de oră. Pentru cine refuză, aceleași mesaje pot pleca pe SMS sau pe mail.
Plățile: în aplicație, dar nu prin sistemul Apple
Mulți cred că orice plată dintr-o aplicație de iPhone trebuie să treacă prin achizițiile în aplicație ale Apple. Pentru servicii, nu. Regula 3.1.3(e) spune că, dacă aplicația vinde bunuri fizice sau servicii consumate în afara aplicației, trebuie să folosești alte metode decât achizițiile în aplicație, de exemplu Apple Pay sau plata cu cardul.
A doua regulă vine din UE. Directiva europeană privind serviciile de plată (PSD2) cere autentificarea strictă a clientului când acesta inițiază o plată electronică: două elemente independente din trei categorii, ceva ce știe (un PIN), ceva ce are (telefonul) și ceva ce este (amprenta). Procesatorul de plăți se ocupă de verificare, dar fluxul aplicației trebuie să-i lase loc: clientul iese un moment spre banca lui și se întoarce exact unde era.
Ce variante de plată alegi depinde de firmă: avans la programare (bun pentru serviciile unde lipsa clientului te costă), plată la final sau o combinație. Fiecare schimbă costul de dezvoltare, așa că o stabilim înainte de ofertă.
Cum se leagă cele trei
- Clientul alege serviciul și o oră liberă.
- Primește confirmarea și întrebarea despre notificări.
- Cu o zi înainte, reminderul. În ziua respectivă, „suntem pe drum”.
- Plătește avansul sau totalul, cu autentificarea băncii lui.
- Programarea apare în istoric, cu un buton „Programează din nou”.
Partea pe care nu o vede clientul, calendarul echipei și panoul de administrare, se construiește odată cu aplicația, nu după. Vezi ce intră într-un astfel de proiect pe pagina de servicii App Dev.
Surse
- Notification runtime permission, Android Developerspermisiunea POST_NOTIFICATIONS din Android 13, notificări oprite la instalare, cererea în context
- App Review Guidelines, Apple Developerregula 3.1.3(e) pentru servicii consumate în afara aplicației și regula 4.5.4 pentru notificări
- Directiva (UE) 2015/2366 (PSD2), EUR-Lexart. 4 pct. 30 (definiția autentificării stricte) și art. 97 (când se aplică)
Verificat: surse Xenia Pușcașu · editare Nora Vlăsceanu · SEO Mihnea Tăbăcaru






