Dyb integration med telefonen: et reelt argument for en app.
Løsningen må gerne kræve net og åben skærm.
Lidt offline: klares typisk uden en app.
Hele arbejdsgangen offline: her er en app svær at komme udenom.
Baggrundsdrift: det kræver reelt en installeret app.
Brugen er bevist.
Brugen er sandsynlig, men uprøvet.
Om brugerne vil bruge den, er ikke undersøgt.
Der er sat tal på værdien.
Problemet er tydeligt, effekten er umålt.
Business casen hviler på synlighed. Det er tyndt.
Noget eksisterende kan måske udvides.
Egne systemer og markedet er ikke afsøgt.
Eksisterende muligheder rækker ikke.
0 af 16 besvaret
Besvar alle spørgsmål for at se jeres pejling.
Jeres pejling
En iOS-/Android-app er det relevante format
Format: iOS-/Android-app
Jeres svar rummer et teknisk krav, som kun en installeret app kan bære: løsningen skal så tæt på telefonens styresystem og udstyr, at kun en app hentet i App Store og Google Play klarer det stabilt på både iPhone og Android. Formatet er dermed givet af teknikken. Om projektet er klar til udvikling, er et andet spørgsmål: det svarer projektmodenheden nedenfor på, og den ændrer ikke formatet.
Antagelser bag pejlingen
At det tekniske krav er reelt og ikke kan omgås med en enklere arbejdsgang. Det er værd at efterprøve, før det får lov at koste.
Det ville ændre svaret
Viser kravet sig at kunne klares i browseren, eller kan arbejdsgangen forenkles, bliver en webapp eller et selvbetjeningsmodul den billigere vej.
Det ville et afklaringsmøde svare på
Den mindste udgave af appen, teknologivalget efter behovet (fx Flutter eller native), og hvad drift og appbutikker realistisk kræver.
Jeres pejling
En iOS-/Android-app kan bære relationen
Format: app som relationskanal
Der er intet hårdt teknisk krav om en app, men kombinationen er stærk: hyppig brug, egne data og historik, bevist efterspørgsel og en klar grund til at vende tilbage. Her kan appen selv være kanalen til brugerne. Daglig brug giver ikke i sig selv en relationsapp: udfaldet afhænger også af brugssituationen, personaliseringen, beskederne og den dokumenterede efterspørgsel, og her står I stærkt.
Antagelser bag pejlingen
At brugerne reelt installerer og beholder appen. For medarbejdere kan enhed og arbejdsgang styres; for kunder skal efterspørgslen holde i virkeligheden.
Det ville ændre svaret
Falder brugen, eller viser installationen sig at være en barriere, er en webapp med PWA-funktioner det billigere sted at holde kontakten ved lige.
Det ville et afklaringsmøde svare på
Den mindste udgave, målene for tilbagevendende brug, og hvornår en PWA ville kunne det samme.
Jeres pejling
En kundeportal eller webapp er det relevante format
Format: kundeportal eller webapp
Brugeren skal kunne flere ting samme sted: funktioner, historik, dokumenter, måske roller og godkendelser. Det er dét, en portal eller webapp er til. Den nås via et link og et login, uden installation, og kan vokse funktion for funktion. Start med de funktioner, der fjerner flest henvendelser, frem for at bygge hele universet på én gang.
Antagelser bag pejlingen
At de flere behov er reelle og ikke kan dækkes af én enkelt opgave. Portalens omfang bør bevises funktion for funktion.
Det ville ændre svaret
Viser behovet sig reelt at være ét ærinde, er et indlejret selvbetjeningsmodul billigere og hurtigere. Kommer der et teknisk app-krav og hyppig brug, kan en app komme i spil.
Det ville et afklaringsmøde svare på
Hvilke funktioner der fjerner flest henvendelser først, hvilket adgangsniveau brugerne skal have, og hvordan portalen kobles på jeres systemer.
Jeres pejling
Et indlejret selvbetjeningsmodul er det relevante format
Format: selvbetjeningsmodul
Brugeren skal klare én afgrænset opgave: et opslag, en bestilling eller en sammenhængende proces med få trin. Det bor bedst som et selvbetjeningsmodul direkte på jeres hjemmeside, ofte helt uden login, via et ordrenummer eller et personligt link. En app ville lægge en installation i vejen, og en fuld portal er mere, end den enkelte bruger har brug for. Vil I dybere i netop det valg, så prøv vores beregner "Selvbetjening eller kundeportal?".
Antagelser bag pejlingen
At opgaven kan afgrænses til ét ærinde, og at brugeren kan identificeres let nok, fx med et ordrenummer eller et tidsbegrænset personligt link.
Det ville ændre svaret
Vokser behovet til flere funktioner og historik, rykker pejlingen mod en portal. Kommer der et teknisk app-krav, kan en app komme i spil.
Det ville et afklaringsmøde svare på
Hvor i arbejdsgangen jeres særlige regler og systemer kommer i spil, hvilket adgangsniveau der er nok, og hvad den mindste udgave koster.
Jeres pejling
En responsiv hjemmeside eller bedre information rækker
Format: hjemmeside
Jeres svar viser hverken et teknisk app-krav, en dyb løsning eller en tilbagevendende relation, der kræver mere end god information og enkle handlinger på hjemmesiden. Det er et fuldgyldigt resultat, og I fik det uden at bruge en krone på et projekt: den billigste løsning, der virker, er den rigtige.
Antagelser bag pejlingen
At jeres svar dækker den konkrete opgave. Består den reelt af flere opgaver, kan hver del have sit eget svar.
Det ville ændre svaret
Skal brugeren bestille, betale eller følge noget selv, rykker pejlingen mod et selvbetjeningsmodul; vokser behovet for egne data og flere funktioner, rykker den mod en portal.
Det ville et afklaringsmøde svare på
Om opgaven overhovedet kræver ny software, eller om den løses bedst i de kanaler, I allerede har.
Hvorfor denne pejling?
Løsningen kræver dyb integration med telefonen. Det er det reelle argument for en app.
Løsningen skal arbejde i baggrunden, selv når den er lukket.
Hele arbejdsgangen skal fungere offline og synkronisere bagefter.
Brugeren skal kunne flere ting samme sted. Det taler for en portal.
Opgaven er én sammenhængende proces og kan afgrænses.
Ét opslag rækker. Et lille modul på hjemmesiden kan bære det.
Behovet handler om information, og det er hjemmesidens job.
Løsningen skal bruges flere gange om dagen.
Løsningen bruges sjældent, så den skal kunne åbnes via et link.
Behovet opstår ude i arbejdet, hvor telefonen er værktøjet.
Behovet opstår primært ved et skrivebord.
Kamera, GPS og QR kan i dag ofte klares i en webapp.
Brugerne skal kunne se egne sager og historik. Det virker også i en webapp.
Engangsbrug giver ikke brugeren en grund til at installere noget.
Leveringsform
App via appbutikkerne
Det tekniske app-krav afgør leveringen: appen hentes i App Store og Google Play. Teknologien, fx Flutter eller en app bygget særskilt til hver platform, vælges efter behovet.
App via appbutikkerne
Appen er selv kanalen: den hentes i App Store og Google Play, og teknologien vælges efter behovet.
App via appbutikkerne
Appen er selv kanalen: den hentes i App Store og Google Play, og teknologien vælges efter behovet.
App via appbutikkerne
Appen er selv kanalen: den hentes i App Store og Google Play, og teknologien vælges efter behovet.
Web med PWA-funktioner
Den enkle offline-funktion peger på en PWA: webløsningen kan installeres på hjemmeskærmen og huske det vigtigste uden net, uden appbutikker.
Web med PWA-funktioner
De vigtige beskeder peger på en PWA: web push virker i moderne browsere, når webløsningen ligger på hjemmeskærmen, uden appbutikker.
Web med PWA-funktioner
Gentagen mobil brug ude i arbejdet peger på en PWA: hurtig adgang fra hjemmeskærmen skaber konkret værdi i hverdagen.
Mobiloptimeret web
Et link rækker her. PWA-funktioner er ikke nødvendige, og løsningen kan opdateres centralt som resten af hjemmesiden.
Anbefalet byggevej
Brug eller udvid det, I har
Kernefunktionen findes allerede i et af jeres systemer, måske endda som app. Slå den til, sæt den ordentligt op, og mål effekten, før nogen bygger nyt.
Tjek standardmarkedet først
Undersøg jeres egne systemer og standardmarkedet, før I bygger. Meget findes som færdige funktioner, der kan konfigureres eller indlejres direkte.
Standardprodukt eller indlejret standardløsning
Processen er tæt på standard. En færdig løsning med en let kobling til jeres data er den billigste vej; skræddersyet udvikling er svær at retfærdiggøre her.
Skræddersyet kan være relevant
Særlige regler, flere integrationer eller flere aktører: det er dér, en skræddersyet løsning tjener sig hjem. De frivillige spørgsmål under pejlingen gør billedet skarpere.
Brug hjemmesiden, I har
Der er ingen byggevej at anbefale, for pejlingen siger, at der ikke skal bygges noget nyt. Skriv informationen tydeligt frem dér, hvor folk leder efter den, og gør de få handlinger, der er, lette at klare på en telefon. Vokser behovet til noget, brugeren selv skal gennemføre, kommer værktøjet her med et andet svar.
Projektmodenhed
Dokumentér behov og værdi først
Formatet ovenfor står ved magt, men hverken brugen eller værdien er dokumenteret endnu. Find en ansvarlig, sæt en KPI, og test behovet med dem, der skal bruge løsningen, før nogen bygger.
Test med prototype eller pilot
Problemet er tydeligt, men brug eller effekt er ikke dokumenteret endnu. En klikbar prototype eller en afgrænset pilot efterprøver det billigt, før I forpligter jer.
Klar til løsningsafklaring
Brugen og værdien er dokumenteret. Næste skridt er en løsningsbeskrivelse og en rigtig business case.
Leverancens kompleksitet
Høj
Løsningen rummer tunge elementer, fx offline-synkronisering, dyb enhedsintegration, flere systemintegrationer eller offentlig lancering. Det ændrer ikke anbefalingen, men det skal med i budgettet fra dag ét.
Mellem
Løsningen har enkelte tunge elementer, fx en integration eller offline-krav. Overkommeligt, men planlæg det fra start i stedet for at opdage det undervejs.
Lav
Ingen af de tunge elementer er i spil indtil videre. Svar eventuelt på de frivillige spørgsmål, så pejlingen står skarpere.
Flere målgrupper får sjældent én løsning. Dem, der arbejder ude, og dem, der sidder ved skrivebordet, har sandsynligvis brug for hver sin grænseflade: fx en mobil app eller PWA til arbejdet i marken og en webadministration til kontoret.
App-teknologien ser nødvendig ud, men løsningen bruges så sjældent, at installationen bliver en barriere. Undersøg, om processen eller teknikkravet kan forenkles, eller om få faste brugere med telefoner, I selv administrerer, dækker behovet.
I svarede, at beskeder er en kerne i løsningen. Web push virker også i moderne browsere og installerede webapps, så beskeder alene kræver ikke en app fra en appbutik.
Er pejlingen genkendelig? Så ser vi gerne på behovet sammen med jer. En svag business case fjerner ikke et reelt teknisk behov, den betyder bare, at brug og værdi skal efterprøves, før nogen bygger. Og siger værktøjet, at I ikke skal have en app, er det et helt brugbart svar, også når det betyder mindre arbejde til os.
Pejlingen bygger alene på jeres svar her og erstatter ikke en konkret vurdering. Den er et udgangspunkt for en samtale, ikke en dom.
Pejlingen siger, hvilken FORM der passer til opgaven, ikke hvad den koster. Prisen afhænger af, hvad der skal bygges bag skærmen, og det finder vi ud af sammen, før noget sættes i gang.
Kunne I bruge pejlingen?
Hvad gik galt?
Tak for din feedback.
Ofte stillede spørgsmål
Hvornår opstår spørgsmålet om en app?
De fleste møder det udefra. Konkurrenten har fået en app, bestyrelsen spørger, hvorfor I ikke har en, eller et bureau har vist et flot app-design. Så står I med en konkret opgave og et pres for at vælge format, før nogen har set på, hvor behovet opstår, og hvem der skal bruge løsningen.
Vores erfaring er ligetil: mange app-ønsker er webapps i forklædning, og en del er slet ikke software-behov endnu. En installeret app er den dyreste vej, både i udvikling og i drift med appbutikker, versioner og test på enheder. Spørgsmålene her bygger på de kriterier, der går igen i international rådgivning om web kontra app, holdt op mod vores egne projekter.
Hvad er forskellen på en mobil app, en mobil webapp og en PWA?
En mobil webapp åbnes via et link og klarer i dag login, egne data, kamera, GPS, betaling og upload. En PWA (progressiv webapp) er en webapp, der oven i det kan installeres på hjemmeskærmen med eget ikon, vise beskeder via web push og fungere delvist offline, uden at skulle igennem appbutikkerne. Den opdateres centralt som en hjemmeside, og den er ofte det rigtige førstetrin, når brugsbehovet er mobilt, men det tekniske app-krav mangler. En installeret mobil app hentes i appbutikkerne og er stærkest, når løsningen skal tæt på telefonen: Bluetooth, NFC, tilkoblet udstyr, konstant lokation, tunge offline-arbejdsgange eller drift i baggrunden.
Derfor gælder fire regler i værktøjet: push alene giver aldrig en app, kamera og GPS alene giver aldrig en app, login og personalisering alene giver aldrig en app, og branding alene giver aldrig en app. Skal appen bygges, vælges teknologien bagefter, ud fra behovet.
Kan en webapp bruge kamera og GPS?
Ja, i de fleste tilfælde. Moderne browsere giver adgang til kamera, billeder, lokation, betaling og biometrisk login, mens løsningen er åben. Det, weben stadig ikke bærer stabilt på tværs af iPhone og Android, er den dybe integration: Bluetooth, NFC, tilkoblet udstyr, konstant lokation og arbejde i baggrunden. Det er dér, den installerede app har sin berettigelse.
Hvad koster en mobil app i forhold til en webapp?
En installeret app er dyrere hele vejen: udvikling til to platforme, lancering og godkendelse i appbutikker, versioner, test på enheder og løbende vedligehold. En webapp opdateres centralt og når brugerne via et link. Derfor beder værktøjet om et forretningsgrundlag, før det peger på en app, og sætter en pejling på leverancens kompleksitet. Konkrete tal hører til på et afklaringsmøde, hvor vi regner på jeres opgave frem for at gætte ud fra en prisliste, der ikke passer til jer.
Flutter eller native?
Det er et teknologivalg, der først træffes, når behovet er afklaret. Flutter kan dække både iPhone og Android med én kodebase og er ofte det rigtige for SMV-løsninger; vi vælger native, altså en app bygget særskilt til hver platform, når platformens yderste muligheder skal i spil. Værktøjet her svarer på det vigtigere spørgsmål før det: om der overhovedet skal bygges en app.
Kan vi ikke bare kræve, at medarbejderne installerer den?
Jo, men det gør ikke appen brugt. En påtvunget app, der ikke erstatter eller forbedrer en konkret, tilbagevendende arbejdsgang, ender ubrugt på telefonen. Beviset er det samme som for kunder: hyppig brug af opgaven i dag, eller en test der viser, at løsningen faktisk hjælper i arbejdet.
Betroet af
Skal vi tage det første skridt?
Et afklaringsmøde, hvor vi hører udfordringen og siger ærligt, om et forprojekt er værd at gå videre med.
Svar fra en af os senest næste arbejdsdag.
En uforpligtende gennemgang af jeres situation.
Afklaring af, hvilke muligheder der er relevante for jer.
En konkret plan, hvis I vælger at gå videre.
Klik for at kommentere
Hjælp os med at gøre siden klarere
Klik på det afsnit, der ikke gav mening — eller hvor du manglede noget.
