Är ni ett företag med anställda som arbetar ute på fältet? Då är Salesforce Field Service sannolikt en produkt som kan stödja er verksamhet. Men när Field Service implementeras kommer ofta en annan fråga på köpet.
Vilken mobil upplevelse ska fältarbetarna faktiskt använda?
Många utgår från att svaret är Field Service Mobile. Det är trots allt appen som är byggd specifikt för Field Service. Men är det verkligen det självklara valet?
Mitt svar är nej.
Field Service Mobile kan vara helt rätt lösning, men valet bör grundas i verksamhetens behov och inte enbart i att man har köpt Salesforce Field Service. Det handlar om att väga fördelarna med en specialiserad app mot de begränsningar och den extra komplexitet som den kan innebära över tid.
Jag heter Felix Bigert Mohr och jag har under mina 7 år som Salesforce-konsult jobbat med flertalet Field Service-kunder där jag ställts inför de utmaningar och beslut som jag adresserar i denna text. Och jag hoppas att de insikter och erfarenheter jag samlat på mig under åren kan hjälpa er med ert beslut, eller åtminstone väcka tankar och idéer som ni kan dra nytta av när ni implementerar Field Service.
Arbeta offline: En dealbreaker?
Den tydligaste skillnaden mellan Field Service Mobile och Salesforce Lightning Mobile är offline-funktionaliteten.
Om fältarbetarna behöver kunna arbeta utan uppkoppling är Field Service Mobile ett naturligt alternativ. Appen är byggd för just det och har dessutom funktionalitet som Lightning Mobile saknar som standardfunktionalitet, till exempel integrerad karta samt specialiserade komponenter för arbetsplaner och produkter.
Men offline är också en av appens största begränsningar.
Eftersom den är byggd för att fungera offline har man inte samma tillgång till data i realtid. Automation och valideringar fungerar därför inte på samma sätt som i Salesforce Lightning. Field Service Mobile Flow har inte samma funktionalitet som vanliga Screen Flows, även om Data Capture Flow löser en del av begränsningarna.
Det får konsekvenser utöver själva användarupplevelsen. Automatiserade processer kan bli mer komplexa att bygga, testa och felsöka. Det kan också påverka hur enkelt lösningen går att anpassa när verksamhetens behov förändras.
Offline kan alltså vara ett starkt argument för Field Service Mobile men det bör grundas i ett faktiskt verksamhetsbehov, inte ett antagande.
UX: Specialiserad app eller gemensam Salesforce-upplevelse?
En annan viktig fråga är användarupplevelsen.
Field Service Mobile är byggd för fältarbetare och kan därför ge en mer fokuserad upplevelse. Om användarna huvudsakligen arbetar med arbetsordrar och bokningar kan det finnas stora fördelar med ett gränssnitt som är anpassat just för deras arbetsuppgifter.
Lightning Mobile ger i stället möjlighet att skapa en mobil upplevelse som i större utsträckning följer samma struktur som Salesforce på desktop.
Med Lightning kan man bland annat arbeta med Record Pages där knappar, fält, flikar och listor kan göras dynamiska. Det ger större möjligheter att styra vad olika användare ser och när de ser det.
Field Service Mobile är mer begränsad i detta avseende och bygger i största grad på Page Layouts. Det kan också bli svårare att förstå hur viss information visas i appen när man behöver ta hänsyn till List Views, Compact Layouts och Related Lists.
För en Salesforce-admin kan Lightning därför vara tydligare och enklare att förvalta.
Samtidigt ska man inte underskatta värdet av en specialiserad mobilupplevelse. Om en tekniker huvudsakligen behöver hantera arbetsordrar, bokningar, tidrapportering, använda produkter och servicerapporter kan ett fokuserat gränssnitt vara enklare och mer effektivt.
Frågan blir därför inte bara vilken app som har flest möjligheter, utan vilken upplevelse som bäst stödjer användarnas dagliga arbetsuppgifter.
Funktionalitet: Hur komplexa är processerna?
Funktionalitet är ett brett begrepp i det här sammanhanget. Det handlar bland annat om guidade skärmflöden, övrig automation, valideringar och verksamhetsspecifika Field Service-processer.
Här blir behovsanalysen extra viktig.
Om processerna är relativt enkla, innehåller få undantag och variationer samt har ett begränsat behov av avancerade valideringar kan Field Service Mobile och Data Capture Flows vara fullt tillräckliga.
Det kan också vara en fördel om samma processer kan användas av både fält- och kontorsarbetare. Då minskar behovet att bygga och förvalta separata lösningar.
Men situationen förändras när verksamheten är mer komplex.
Vad händer om olika typer av arbete kräver olika processer? Vad händer när nya tjänster lanseras, verksamheter förvärvas eller processerna behöver förändras och förfinas över tid?
Då behöver man vara medveten om att ett val av Field Service Mobile kan innebära begränsningar i hur processerna kan byggas, eller att samma process behöver hanteras på olika sätt beroende på vilken användarupplevelse den ska fungera i.
I mer komplexa scenarier kan man därför hamna i en situation där man behöver göra avvägningar mellan funktionalitet kontra stabilitet, prestanda och skalbarhet. I värsta fall kan en begränsning i Field Service Mobile göra en process betydligt svårare att implementera eller förvalta än den hade behövt vara.
En lösning som fungerar bra dag 1 kan bli betydligt mer utmanande över tid.
Den verkliga kostnaden kommer efter lansering
När man jämför Field Service Mobile och Lightning Mobile är det lätt att fokusera på kostnaden för själva implementeringen.
Men den stora frågan är ofta vad som händer efter Go-live.
I en organisation där olika typer av användare behöver utföra samma arbetsuppgifter, där processer kontinuerligt utvecklas och där Salesforce är en central plattform för verksamheten, kan en specialiserad Field Service-app innebära ytterligare förvaltningskostnader.
Det handlar inte bara om utveckling.
Det handlar om UX, testning, felsökning, utbildning, dokumentation och anpassningar när verksamheten förändras. Om samma process behöver hanteras på olika sätt i olika gränssnitt ökar också komplexiteten i den långsiktiga förvaltningen.
Det är därför viktigt att inte bara jämföra kostnaden för de två alternativen när man implementerar Field Service.
Den stora kostnaden kan vara den komplexitet som följer med lösningen över tid.
Det betyder inte att Lightning Mobile alltid är billigare. Field Service Mobile kan vara helt rätt investering om den löser ett konkret behov och ger en bättre användarupplevelse.
Men den extra komplexiteten behöver vara motiverad av faktiska behov.
Så hur väljer man rätt?
Om offline är en verksamhetskritisk nödvändighet är Field Service Mobile ett naturligt alternativ att utvärdera.
Om offline däremot inte är ett krav skulle jag framför allt utgå från tre områden:
UX: Hur ska användarnas arbetsdag se ut?
Behöver de en fokuserad upplevelse för Field Service, eller behöver de röra sig mellan flera delar av Salesforce?
Funktionalitet: Hur komplexa är processerna?
Hur mycket automation och hur många valideringar behövs? Hur många variationer och undantag finns? Och hur förväntas behoven förändras framåt?
Förvaltning och skalbarhet: Vad kostar lösningen över tid?
Kan samma processer och komponenter återanvändas? Behöver två parallella användarupplevelser förvaltas? Och hur enkelt är det att göra förändringar när verksamheten växer?
De här frågorna är ofta viktigare än vilken app som från början ser mest anpassad ut för Field Service.
Ett enkelt beslutsramverk
Innan ni bestämmer er kan följande frågor hjälpa till att strukturera diskussionen:
- Är offline en faktisk och verksamhetskritisk nödvändighet?
- Kommer fältarbetarna huvudsakligen att arbeta med arbetsordrar och bokningar?
- Kan användarna utföra alla sina arbetssteg i Field Service Mobile?
- Hur komplexa är våra automatiserade processer och valideringar?
- Hur många variationer och undantag finns i våra processer?
- Förväntar vi oss att processerna kommer att förändras mycket över tid?
- Behöver samma processer fungera för både fält- och kontorsarbetare?
- Är vi beredda att förvalta två olika användarupplevelser för samma process?
- Vilka konsekvenser får vårt val för utveckling, testning, felsökning och utbildning?
- Vilken lösning ger oss den funktionalitet vi behöver med så lite onödig komplexitet som möjligt?
Det finns sällan ett universellt rätt svar. Det viktiga är att kunna motivera varför den valda lösningen passar just den egna verksamheten, både idag och om flera år.
Gör ett medvetet arkitekturval
Att välja Field Service Mobile bara för att ni köpt Field Service kan vara lika fel som att välja Lightning Mobile av princip.
På Stretch ser vi därför till att börja med verksamhetens behov. Genom workshops går vi igenom befintliga och framtida processer, bryter ner behoven och utvärderar vilken mobil upplevelse som bäst stödjer dem.
Field Service Mobile bör vara ett medvetet arkitekturval, inte ett standardval.
För en organisation som vill växa med Salesforce som motor är målet inte att bygga den mest specialiserade lösningen, utan att lösa verksamhetens behov med så lite onödig komplexitet som möjligt och samtidigt skapa en lösning som är skalbar, effektiv och hållbar över tid.
Vi på Stretch Customer arbetar dagligen med flera kunder inom olika branscher som alla nyttjar Salesforce Field Service på olika sätt. Kontakta oss gärna om din organisation behöver teknisk eller strategisk hjälp för att utveckla eller implementera er lösning.
Felix Bigert Mohr, Stretch Customer
FÖRKLARINGAR:
Salesforce Lightning: Det gränssnitt som är byggt för desktop men som även används för Salesforce standard mobilapp.
Salesforce Flows: Automationsverktyg som finns i olika varianter för olika ändamål, t.ex. som olika typer av skärmflöden (för guidad data-input av användare) där Field Service Mobile Flow och Data Capture Flow är specifikt anpassade för FSL appen med begränsad funktionalitet jämfört med vanliga Screen Flows.