CM SystemsEt felt-system bliver ofte vurderet fra kontoret: Kan vi se status? Kan vi få rapporten? Det er vigtige spørgsmål, men løsningen lykkes kun, hvis den også passer til teknikeren. På stedet er der begrænset tid, varierende forbindelse, kundedialog og praktiske forhold. Den gode første version hjælper med den konkrete opgave frem for at prøve at blive et komplet administrationssystem.
1. Beskriv en rigtig arbejdsdag
Begynd ikke med skærmbilleder. Følg i stedet en konkret medarbejder fra første opgave til dagen slutter. Hvordan får hun besked om dagens besøg? Hvad skal hun kunne se før ankomst? Hvad sker der, hvis kunden ændrer opgaven? Hvilken dokumentation skal være klar, før hun kører videre? Og hvad gør kontoret med resultatet?
Denne gennemgang afslører ofte, at den vigtigste funktion er enkel: at se den rigtige opgave med adresse, kontaktperson, tidligere noter og aftalt arbejde. Først når grundlaget er rigtigt, giver fotos, tjeklister, materialeregistrering eller signatur værdi. Hvis medarbejderen stadig skal ringe til kontoret for at finde den rigtige sag, har systemet ikke løst kerneproblemet.
2. Gør opgaven forståelig
En tekniker bør hurtigt kunne svare på: Hvad skal jeg gøre? Hvor er jeg? Hvem kan jeg kontakte? Hvad er gjort før? Hvad skal dokumenteres? Brug et tydeligt sagskort frem for en lang liste af ukategoriserede oplysninger. Vis kun det, der er relevant for rollen og opgaven, men sørg for at vigtige advarsler eller aftaler ikke gemmer sig i et vedhæftet dokument.
Opgavestatus skal også være praktisk. “På vej”, “påbegyndt”, “afventer kunde”, “kræver materiale” og “afsluttet” kan skabe et fælles sprog mellem felt og kontor. Definitionerne skal være tydelige. En opgave er ikke afsluttet, blot fordi teknikeren har forladt adressen, hvis den stadig mangler rapport, kundegodkendelse eller et tilbud.
3. Planlæg for dårlig forbindelse
Feltarbejde foregår ikke altid med stabilt net. Kældre, produktionsmiljøer og landlige områder kan gøre forbindelsen usikker. I behøver ikke nødvendigvis bygge en fuld offline-løsning fra første dag, men I skal beslutte, hvad der må ske, hvis forbindelsen forsvinder. Kan teknikeren se allerede hentede opgaver? Gemmes en note lokalt, indtil den kan sendes? Får brugeren en tydelig besked, hvis noget ikke er synkroniseret?
Det værste er en app, der ser ud til at have gemt arbejdet, men senere mister det. Derfor skal synkronisering være synlig. Medarbejderen skal kunne se, om rapporten er sendt, afventer net eller kræver handling. Test dette på rigtige telefoner og i de miljøer, hvor løsningen skal bruges.
4. Brug telefonens styrker fornuftigt
Kamera, placering, notifikationer og hurtig adgang til kontaktoplysninger kan gøre en mobil løsning meget bedre end en webside på en lille skærm. Men hver funktion skal understøtte arbejdet. Billeder skal knyttes til den rigtige sag og gerne kunne få en kort beskrivelse. Notifikationer skal kun bruges, når de hjælper brugeren med at handle. Tilladelser til kamera eller lokation skal forklares klart.
Overvej også, hvad der ikke skal være i første version. Live-sporing, chat, avanceret planlægning og lagerstyring kan være relevante senere, men gør sjældent en enkel rapporteringsopgave bedre fra dag ét. Den mest professionelle løsning er ofte den, medarbejderen kan lære på få minutter og bruge konsekvent.
5. Lad roller styre det rigtige overblik
Teknikeren, servicelederen og kontoret har ikke samme behov. Teknikeren skal se egne opgaver og kunne registrere arbejde. En leder kan skulle fordele sager og se flaskehalse. Kontoret skal kunne følge op, sende dokumentation og klargøre fakturering. Når roller blandes sammen, bliver systemet enten uoverskueligt eller usikkert.
Adgang skal derfor testes som funktionalitet. Kan en tekniker kun se de kunder og dokumenter, rollen giver adgang til? Kan en leder overtage en opgave? Kan en fratrådt medarbejder fjernes? Det er ikke en detalje efter lancering; det er en del af den løsning, kunden køber.
6. Aflever en færdig første version
Vælg én opgavetype og aftal, hvad “færdig” betyder. Det kan være, at teknikeren kan modtage, udføre og afslutte en serviceopgave, og at kontoret kan se resultatet med det samme. Brug den version i virkeligheden, indsamle feedback og udvid derefter. Guiden om fra portal til app kan hjælpe med de tekniske beslutninger før udvikling.