Supportprocess och Change requests

Om du har funderingar på hur vår supportprocess ser ut har du möjlighet att läsa om det här. Vi beskriver även vad ni ska tänka på innan ni rapporterar in ett fel till oss och vilken input vi behöver om ni vill skicka in en Change request. Tänk på att ju mer underlag ni ger oss ju mer hjälper ni oss att snabbt kunna lösa felet eller prioritera förändringen ni vill göra.

Vi älskar feedback! Självklart vill vi att ni ger oss det, via formuläret.

Fel i appen/Mina sidor

Upplever ni ett fel i appen eller på Mina Sidor? Visas ett oavsiktligt eller oväntat resultat?

Säkerställ först att ni i Bridge identifierat var felet är om möjligt och inkludera det i rapporten. Det gör det lättare för oss att prioritera. Om det till exempel rör sig om ett datafel i ert API ska det tas vidare till era utvecklare.

När ni har uteslutit att felet är på er sida ska ni rapportera en bugg genom att mejla support@getbright.se.

Se till att inkludera så mycket information som möjligt.

Exempel på bra information vid felrapportering är:

Vilken/vilka användare berör felet? (namn/kundnummer).
Vilket datum började felet att uppstå?
Vilket versionsnummer har användaren? (versionsnummer hittar ni längst ner på “Min profil” i appen).
Vilken enhet har användaren? (Android, iOS, läsplatta etc).
Bifoga skärmbild eller inspelning om möjligt.

Fel på smartstyrning för elbilar

Användaren kan antingen ladda sin bil via en laddbox eller direkt via integration till bilen. För fel som rapporteras för våra smarta integrationer mot olika hårdvara så är det oftast lite knepigare att identifiera var felet ligger. Därför är det bra om ni tagit in så mycket information som möjligt från användaren som upplever felet.

Enode tillhandahåller en Status-sida som kan vara bra att titta på först för att se att det inte existerar ett känt underliggande problem.

Nedan följer ett antal frågor som kan vara bra att ha svar på för enklare felsökning.

När problem uppstår vid användande av en elbilsintegration:

Inga andra smarta tjänster ska vara aktiverade av användaren för bilen. Be därför användaren säkerställa att det inte finns det någon annan tjänst kopplad till bilen, exempelvis Tibber/Gridio. Säkerställ också att användaren inte heller har några andra schemalagda tjänster aktiverad i bilen eller på laddboxen.

Namn på användaren.
Kundnummer.
Är det ett återkommande problem?
På vilken adress laddade användaren?
Exakt position på var användaren laddar (Long/lat eller länk till Google Maps, eller dylikt).
Vilken bil är det som laddas? (Märke, modell och årsmodell).
Vilken laddbox var det som användes? (Märke, modell och kapacitet).
När var Smartladdning påslaget i appen (om det ändrades nyligen).
Vilka var inställningarna för smartladdningen?
Vilken tidpunkt var bilen inkopplad? (Dag och tid).
Vad var önskad slutgiltig laddnivå satt till i bilen? Kallas även för “Target State of charge”. Observera att bilarna kan särskilja mellan satt laddnivå på AC-laddning (laddning hemma) och DC-laddning (snabbladdning).
Mellan vilka timmar laddade bilen?
Finns det någon lastbalanserare installerad hos användaren som kan påverka laddningen?
Några andra avvikelser som uppmärksammats?
Bifoga skärmbild och/eller inspelningar om möjligt.

När problem uppstår vid användandet av en laddbox-integration:

Namn på användaren.
Kundnummer.
Är det ett återkommande problem?
På vilken adress laddade användaren?
Vilken bil är det som laddas? (Märke, modell och årsmodell).
Vilken laddbox var det som användes? (Märke, modell och kapacitet).
När var Smartladdning påslaget i appen (om det ändrades nyligen).
Vilka var inställningarna för smartladdningen?
Vilken tidpunkt var bilen inkopplad? (Dag och tid).
Vad var önskad slutgiltig laddnivå satt till i bilen? Kallas för “Target State of charge”. Observera att bilarna kan särskilja mellan satt laddnivå på AC-laddning (laddning hemma) och DC-laddning (snabbladdning).
Mellan vilka timmar laddade bilen?
Finns det någon lastbalanserare installerad hos användaren som kan påverka laddningen?
Några andra avvikelser som uppmärksammats?
Bifoga skärmbilder och/eller inspelning om möjligt.

Bugg-prioritering

Vi genomför kontinuerliga buggprioriteringsmöten där vi prioriterar buggar i enlighet med detta diagram:

Prio 1: Kräver en omgående release (hotfix) och incidenthantering triggas om felet uppstått i produktion.
Prio 2: Ska prioriteras in till teamen.
Prio 3: Blir prioriterat när vi gör om funktionen.
Prio 4: Stängs som “Kommer inte att fixa”.

Vi genomför också en veckovis backlog-review där Produkt- och Supportteamet går igenom existerande buggar och diskuterar progress och rättningar som är påväg.

Återkoppling buggar

När en lösning på er rapporterade bugg är ute i produktion, återkopplar vi det till den person som har anmält buggen via mejl. Tänk därför på att skicka in mejlet från er support eller liknande. Större generella lösningar för alla våra kunder rapporteras på sidan med release notes.

Change request

Om ni vill göra någon typ av förändring i appen eller plattformen så ska ni använda vårt Change request-formulär som ni hittar här.

Formuläret guidar er igenom vilken information vi behöver från er, baserat på vad det är ni vill göra.

Notera att en Change request-förfrågan inte innebär ett direkt åtagande från Bright. När vi tagit in informationen från er kommer vi att se över den och återkoppla till er. Vi behöver ha minst två veckor på oss att gå igenom en Change request-förfrågan. Om det är en Breaking change hos er som kräver ändring hos oss, behöver vi minst 10 veckors framförhållning.

Vikten av att fylla i formuläret utförligt

Baserat på vilken typ av önskemål ni har så ställer vi olika frågor i formuläret. Era svar ger oss en bra bild över förutsättningarna och ett ordentligt underlag för prioritering. Det är därför viktigt att ni ger oss så mycket information som möjligt, inklusive all tillgänglig dokumentation som finns för att vi ska kunna uppskatta storleken på förfrågan och vad förutsättningarna faktiskt är. Om vi behöver kompletterande information, kommer er kundansvarig återkoppla till er med vad vi behöver, men detta undviker vi gärna om möjligt.

Är förfrågan något som hela plattformen har nytta av kommer vi först och främst att titta på om den passar vår övergripande produktvision, strategi och roadmap. Ju mer data som finns som kan backa upp värdet av genomförandet desto bättre. Om det dessutom finns användarundersökningar eller någon annan data som påvisar ett stort behov, så ökar chanserna för att det blir prioriterat.

Vi tillhandahåller en White label/SaaS-produkt och utrymmet för unika lösningar för er plattform är minimalt. Om vi anser att det är något vi kan hjälpa till med så återkommer vi med en tidsuppskattning för godkännande innan vi tar det vidare in till vår fortsatta planering.

Förklaringar till Change request-formuläret

“Change request” – En Change request är ett förslag av förändring av en produkt på något sätt. Antingen genom att addera ny funktionalitet som inte existerar, eller genom en förändring av befintlig funktionalitet/beteende.
“Breaking change” – En breaking change ska ni välja när ni på något sätt planerar att göra en förändring på er sida i exempelvis ert API som innebär att någonting kommer sluta fungera som förväntat och som gör att Bright behöver genomföra förändringar på sin sida.
Existerande funktionalitet på eller av – Detta alternativ ska ni välja om ni vill slå på eller slå av en befintlig funktion.
Innehållsförändring – Ange detta alternativ när vi vill förändra innehåll på något sätt. Exempel på det är förändring av copy (text), skicka ut en push-notis, eller ändra en bild.
“Compliance” – Ange detta alternativ om förändringen som behöver göras grundar sig i ett lagkrav eller compliance-efterlevnad på något sätt.
Feedback/Insikt – Välj detta alternativ om ni vill dela med er av feedback som inkommit på något sätt. Vi tar tacksamt emot all typ av feedback!

Återkoppling på Change request

Återkoppling på Change request eller feedback sker via er kundansvarig.