Know thy Context

In a designer utopia, the user is always performing one task at a time, i.e. performing a single use case in your product. Often times, the modern world consists of intertwined tasks and interruptions. This leads to a conclusion that understanding the use context is essential in order to carve great experiences.

Simultaneous tasks

Examples of what the user might do while she is using your mobile app product:

  • Use other apps
  • Have multiple tabs open
  • Talk with other people
  • Browse email
  • Browse the world wide web
  • Use other smartphone features
  • Run
  • Cycle
  • Eat
  • Listen to music
  • Watch Netflix
  • Do pushups

In a nutshell: 100% of the user’s attention is not targeted to your product – it is divided among other interesting tasks. You don’t have full attention, so make your designs as if you were designing for an ape: Intuitive enough to be used with as little amount of attention as possible.

Feelings

The user may or may not have experienced something from the list within 1 hour of usage of your app.

  • Run a marathon
  • Quit a marathon
  • Had a meal
  • Eaten too much
  • Slept 12 hours
  • Haven’t slept for 24 hours
  • Given birth
  • Attended a funeral

Emotions of a person are a cumulative result of a person’s past experiences. When experiencing your design, a user may already be frustrated by misfortunes experienced recently. On the other hand, she may be feeling like she is on top of the world.
But how to take this into account?
Learn the aspects of classical UI design. Read books, for example, Designing Interfaces: Patterns for Effective Interaction Design.
It’s all about compassion. Until we can deliver truly personal experiences, we should use polite but not too childish language in our user interfaces.
A frustrated person may also get angry with the experience if she has to wait for loading. You should avoid loading experiences or make them unnoticeable.
Take advantage of user personalisation on different platforms. For example, someone may prefer different font sizes on iOS. On the web, make things responsive, zoomable and bookmarkable.

Personas are the de facto way to put yourself in someone else’s shoes.

persona card

A persona is a way to model, summarize and communicate research about people who have been observed or researched in some way. A persona is depicted as a specific person but is not a real individual; rather, it is synthesized from observations of many people. Each persona represents a significant portion of people in the real world and enables the designer to focus on a manageable and memorable cast of characters, instead of focusing on thousands of individuals. Personas aid designers to create different designs for different kinds of people and to design for a specific somebody, rather than a generic everybody.

Get hands-on experience of the context

Acquire hands-on experience of the use context as much as possible. If you are designing an AR-based collision-detection system for an excavator, be sure you step into the control room and learn basic maneuvres with the actual excavator.
These kinds of experiences have many benefits, they:

  1. Help you gain empathy towards users
  2. Help you understand simultaneous tasks
  3. Make you go through the same emotions as the user
  4. Motivate you as a designer
  5. Give you unforgettable experiences while working (great!)

So now you are with real users – why not observe them at their work and hold a workshop on the same day? Get another designer to accompany you – alternate the roles of documenting and observing users during the day.
Go through the materials and extract the most important remarks. Make iterative designs

The Setting (Location, time of day and weather)

Alright, let’s come up with a totally imaginary situation and platform.
Imagine this context: 7 mountaineers are trying to reach the top of Kilimanjaro. A storm arises, the group is dispersed. John and Andy are with each other, but Andy has broken his ankle. Luckily John packs a weather-proof mountaineer smartwatch – there is an app installed that is supposed to have one mission: Work as a beacon for safety helicopters to save mountaineers in danger. This app will send a GPS signal for the rescue squad in the background and is only used in emergencies.
Now let’s make a quick 5-minute mockup in Sketch. Once you open the app on the watch, you will see this. The soothing green with text informing you that you are not in any danger (I know, red and green are a bad colour combination).
I am fine
Once you tap the green screen, the view will go red and the text will change – Now a rescue squad is on the way.
Rescue
Great… But wait, there is a snowstorm on Kilimanjaro, and the text vs. background contrast may not be enough in bad weather. Here’s how the landing view would look like in a bad storm:
simulated snowstorm
Indeed, we need to improve the text legibility.
Here’s the second iteration with larger text size and more contrast (black on white with green circle)
I am fine
Here’s the snowstorm simulated again:
simulated snowstorm
Now compare the legibility in the ”snowstorm” – We gained some contrast and legibility with our changes, great!
As the smartwatch is positioned on the mountaineer’s hand, he can always bring the watch closer to his eyes to gain extra legibility.
If I were to be rescued, I’d like to know that the rescue signal is still being sent (my battery hasn’t run out). I’d also like to know that the signal is being answered. Let’s improve the rescue mode too. (I’ve made the same legibility changes also to this screen).
Rescue
I’ve decided to add a GPS signal icon to symbolize the rescue signal being sent. Also, I’ve added a vibration feature to the app, so the person who is being saved gets a vibration on his wrist for 60 seconds (or so, this should be user-tested) and is aware that this rescue mode is on. It is reassuring for the user to feel the vibration and trust that the rescue squad is on their way. A soothing beacon…
But how does the user know that help is on its way? We need a way for the rescue squad to signal back to the watch.
Let’s split the rescue mode into two views: pending vs. on-its-way views. Let’s make these statuses as obvious as we can, so the mountaineer doesn’t have to think too much while their life is on the line.
We can make use of the circular red + text to signal these two UI states.

Here are all three final versions

Rescue app opened
Rescue Pending
Rescue request received
I am fine
rescue pending
being rescued

…And the possible state transitions.

state transitions
The rescue operator would need a client to handle rescue events, but let’s not design this. It would be likely a web/desktop application and the operator would use a phone on his daily work.

What we have learned

Design is affected by simultaneous tasks and user’s emotions. In order to put yourself in the end user’s shoes, you should get first-hand experience with the context by defining personas and putting yourself into user’s shoes. Design changes based on the setting (Location, time of day, weather).
In our example, we ended up making changes to the original design idea based on understanding the use context.

  • Typography
  • Interactions
  • Animation
  • Colours
  • Haptic feedback

This was just a 30-minute example – more complex scenarios lead to more complex changes. What you need to do is iterate on the designs, and make end-user tests. Norman & Nielsen suggests that you only need to have 5 end-users to get saturated on end-user testing. Lean UX is a set of principles that rely on iterating the designs. Don’t forget to pivot if you need to!
To be continued – This was part 2 of a number of posts on the topic: ”How to Prosper on Every Platform”.
Be sure to read part 1: Design Essentials: How to Prosper on Every Platform – Know thy Platform (Part 1)

Avatar

Esa Juhana Lahikainen

Piditkö lukemastasi? Jaa se myös muille.

In service design we talk about touchpoints, where, when, and how customers come into contact or interact with a service. A touchpoint can be many things:

  • An artefact: a letter, a chocolate on a pillow
  • Customer service: how support or sales staff treat and guide your customer, how they greet customers
  • A full digital service or a website and everything that goes with it

Companies want all the service touchpoints to communicate company and brand values consistently and to provide excellent service to their customers. A service exists only to provide value to customers.
Touchpoints should be designed to deliver a successful service. The term orchestration is often used to describe all the actions as successful service delivery means that you are planning and designing processes, ways of working, touchpoints that work both internally and are economical (back end, support) as well as touchpoints that serve and delight the customer (the front end).
I’d like to share some insight into a study where we were testing a multi-touchpoint B-to-B, B-to-C service scenario with customers. In just one hour with a customer, we were able to get many kinds of feedback. Often studies are either explorative, looking into a theme or exploring a hypothesis. We are observing and interviewing to find the needs, wants, fears, pain points before a service is developed or improvement actions are started or then focusing on a single touchpoint and how to make that work better for the customer. Looking at the whole customer journey or some longer parts of it is less common, so, getting to do this multi-touchpoint study was a great learning experience!
Touchpoints that were in the focus of the study:
Advertising: different methods for drawing attention and advertising in web marketplaces
Environment: Our customer was introducing a change. Moving the service from their offices to a partner company’s facilities, they wanted to understand: Will the new environment promote trust? Will they lose brand value?
Customer service: What should be said and at what points in the process, what can be left to later? Tone: how to be helpful, how to induce trust? Timing: How long will getting the service take?
Artefacts: What information should the web service have and in what order? What is the minimum set of information that needs to be on paper?
Back-end and support processes and how these responsibilities should be shared with partnering businesses in this new way of working?
In addition to this, we were able to:

  • Map out the customers’ earlier experiences.
  • Test the value proposition of the service.
  • Clarify the roles of the two service producing companies and organizations.
  • Clarify communications, what should be said in online, on paper or by the customer service staff.

In order to be able to test all this, we had

  1. A quick interview including testing of our concept adverts.
  2. A scenario involving the real environment and our customer service staff. (we had two different customer roles, so, two scenarios were tested on separate days)
  3. Quick feedback interview of all the process steps, about the environment and customer service.


When the study had been done, I decided to stick the results onto a wall that resembled a mix of a service blueprint and a customer experience map with real-life artefacts (the fake adverts, and test versions of the different forms and photos from the environment). The swim lanes had different customer roles, notes for customer service staff, notes for both business 1 and business 2. And everything was moving in time:

  1. Discovery and decision making phase: How customers had discovered similar services earlier and how they compared offers, what was important in decision making.
  2. Service steps: What we discovered about the environment, customer service during the scenarios.
  3. Decision-making phase: Would you buy this service? Feedback about how it all felt, about timing etc.

All this required careful planning and the ability to ease the participants (both customer and the service staff) into the scenarios and acting.
The response that we received from our customer was “Great that we tested on such a concrete level.” “We received tools to take this solution into production, for example, a list of highlights for the Customer service staff, to make the customer feel at ease and informed in the different stages of the process.” “Good work! I’m really satisfied.”
For me as a designer, this was an exercise in careful planning and testing of the study setup before we started. It also proved that you can achieve a lot in just one hour with a customer. When one of the customers started to make a bargain at the counter, we knew that he was really into the situation and not faking it.  People were able to throw themselves into the scenarios.
Making it real paid off.

Minna Vänskä

Minna Vänskä

Minna on kokenut kansainvälisten, monialaista yhteistyötä vaativien konseptointi- ja kehitysprojektien vetäjä, kuluttajatutkimuksen ja viestinnän asiantuntija. Goforella hänen vastuullaan ovat asiakastutkimukset, käyttökokemuksen suunnittelu, konseptointi- ja palvelumuotoiluprojektit. Minnan sydäntä lähellä on asiakkaiden ja henkilökunnan osallistaminen uusien palveluiden kehittämistyöhön, työpajojen järjestäminen sekä palvelumuotoilumetodien soveltaminen asiakastutkimuksessa.

Piditkö lukemastasi? Jaa se myös muille.

Tieto on nykyisin julkisella sektorilla tallennettuna hajanaisesti moneen eri paikkaan ja laaja tiedon yhteiskäyttö on vähäistä. Ihmisten kokonaisvaltaista hyvinvointia edistetään vähemmän kuin olisi mahdollista. Jotta yhteiskunta voisi kehittyä hyvinvointia lisääväksi ekosysteemiksi, tarvitaan oikeanlaisten valintojen tekemistä. Päätöksenteon helpottaminen edellyttää oikeiden tietojen käyttämistä ja mahdollisimman avointa tietoympäristöä.
Nykyinen julkisen hallinnon organisaatiokeskeinen toimintatapa ei auta parhaalla mahdollisella tavalla ihmistä eri elämäntapahtumissa, vaan sitoo hyödynnettävän tiedon organisaation eri rekistereihin ja tietovarantoihin. Päätöksentekoon tarvittava tieto ei ole helposti saatavissa eikä yhteiskäytettävissä eri organisaatioiden välillä. Lainsäädäntö myös asettaa paljon rajoitteita tiedon vapaalle yhteiskäytölle. Tiedon laaja avoimuus ja liikkuvuus sekä ihmisen omien tietojen hallinta on vielä tänä päivänä monen esteen takana.
Organisaatiokohtaisiin siiloihin kätkeytyy paljon yhteiskäyttöisesti hyödynnettävää tietoa. Nykymallissa asiakas on piilossa organisaatiorakenteiden takana ja viranomaisprosesseissa asiakas on toiminnan kohde eikä aktiivinen tekijä. Onneksi tähän on tulossa muutosta muun muassa maakunta- ja sote-uudistuksen muodossa. Uudistuksen tausta-ajatuksena on visio, jossa asukkaan palvelutarve on toiminnan kehittämisen keskiössä.
Maakuntauudistus on yksi itsenäisen Suomen suurimmista hallinnon reformeista. Sosiaali- ja terveydenhuolto uudistuu rakenteellisesti, palveluiden järjestäminen ja rahoitus muuttuvat. Uudet maakunnat ottavat vastuulleen paljon tehtäviä kunnilta ja valtion aluehallinnolta. Kun hallintorakenteita muutetaan, voidaan edesauttaa täysin uudenlaisen ajattelun läpivientiä.
Gofore toteutti yhdessä asiantuntijatyöryhmän kanssa valtiovarainministeriölle maakuntien viitearkkitehtuurin [1], jossa kuvataan kokonaisarkkitehtuurimenetelmällä maakuntien tulevaa toimintaa ja tietoympäristöä. Maakuntien viitearkkitehtuuri jäsentää uusien maakuntien toimintarakennetta ja -ympäristöä, jotta perustettavat maakunnat ja niiden kanssa toimivat tahot saisivat yhteiskäyttöisen pohjan tarkempaa suunnitteluaan varten. Viitearkkitehtuuri on muodostettu asiakkaan palvelutarpeen lähtökohdista, ja se toimii apuna siirryttäessä organisaatiolähtöisestä ajattelusta asiakaskeskeiseen toimintatapaan.
Jotta tästä päästään askel pidemmälle ja voidaan tavoitella aidosti ihmiskeskeistä toimintatapaa, tietoa tulee tarkastella laajemmin eri näkökulmista. Valtiovarainministeriön koordinoimassa maakuntatieto-ohjelmassa [2] Gofore on mukana toteuttamassa maakuntatietoarkkitehtuuria.
Maakuntatietoarkkitehtuurissa tietoa, tiedon hallintaa ja tietojohtamista tarkastellaan luonnollisesti maakunnan eli palvelunjärjestäjän näkökulmasta, mutta myös palveluntuottajan, valtionhallinnon ja asiakkaan näkökulmista. Tietoa tarkastellaan näkökulmakohtaisesti seurannan, ohjauksen ja johtamisen tasoilla. Näiden avulla muodostetaan laaja näkemys kansallisesta, alueellisesta ja yksilöllistä toiminnan tietotarpeista maakuntien aloittaessa toimintansa. Tämän lisäksi tuotetaan pidemmän aikavälin toimenpide-ehdotuksia, mitä täytyisi muuttaa, jotta siirtymä ihmiskeskeiseen toimintatapaan olisi mahdollinen. Projektin tulokset julkistetaan ensi vuoden aikana.
Edellä mainituissa projekteissa on keskeistä ymmärtää nykytilan toimintatavat, ja mitä muutoksia tarvitaan, kun tiedon hallinnassa ollaan siirtymässä kohti ihmiskeskeistä ajattelua. Maakuntien viitearkkitehtuuri antaa referenssin, jonka perusteella maakunta voi jäsentää omaa toimintaansa. Maakuntatietoarkkitehtuuri katsoo laajemmin ympäröivää yhteiskuntaa tiedon näkökulmasta ja nostaa ihmisen muutoksen keskiöön.
Gofore on ollut mukana myös toteuttamassa Väestörekisterikeskuksen tuottamaa yhteentoimivuusalustaa, jota hyödynnetään tiedon yhteiskäytön mahdollistamiseksi [3].
Matka organisaatiokeskeisestä toimintatavasta asiakaslähtöisen ajattelun kautta ihmiskeskeiseen on pitkä ja edellyttää laajaa yhteiskunnallista dialogia, jonka suuntaviivoja on jo määritelty muun muassa tietopoliittisessa selonteossa [4]. Nyt muutoksen hetkellä voidaan tehdä oikeat valinnat niin toiminnan kehittämisessä kuin tietoarkkitehtuurissa. Tätä kautta voimme saavuttaa myös parempia palveluita, jotka tulevat ihmisen luo oikeaan aikaan. Ja kuten kollegani Pasi Lehtimäki sen osuvasti blogissaan [5] kuvaa: ”Palvelut muodostavat ketjuja ja ketjut palvelukokonaisuuksia, joiden tavoitteena elämän eri osa-alueiden kokonaisvaltainen hyvinvoinnin lisääminen yksilötasolla.
Arkkitehtuurityö voidaan nähdä sijoituksena, joka mahdollistaa, että voimme tulevaisuudessa päästä eroon siiloutuneista tiedoista. Viranomaisilla ja muualla julkisessa hallinnossa hajallaan oleva tieto olisi yhteiskäytettävissä myös muualla. Tämä mahdollistaa, että palvelut olisivat oikeasti asiakaskeskeisiä. Tämän murroksen jälkeen palvelut olisivat pidemmällä aikavälillä myös aidosti ihmiskeskeisiä.
 
[1] Maakuntien viitearkkitehtuuri,
https://alueuudistus.fi/digitalisaatio/arkkitehtuuri  
[2] Maakuntien tiedolla johtamista ja sitä tukevan tiedonhallinnan kehittämistä koordinoiva ohjelma eli maakuntatieto-ohjelma, https://vm.fi/hanke?tunnus=VM129:00/2017
[3] Yhteentoimivuusalusta, https://yhteentoimiva.suomi.fi/fi/
[4] Tietopoliittinen selonteko,
https://vm.fi/tietopoliittinen-selonteko
[5] Pasi Lehtimäki, blogi 20.3.2018,
https://gofore.com/kunnat-uuden-edessa/

Avatar

Janne Pehkonen

Janne on kokenut julkisen sektorin kokonaisarkkitehti, joka uskoo ihmiskeskeiseen hyvinvointiyhteiskuntaan. Hän on suunnittelemassa tulevaisuuden Suomea, jossa asiakaskeskeisen ajattelun paradigman muutoksen ja digitaalisen transformaation kautta ihminen nostetaan keskiöön.

Piditkö lukemastasi? Jaa se myös muille.

I thought it would be a good way to start my first few weeks as a robot expert at Gofore by sharing some very basic info about the robots I am mostly working with here.

What robots?

RPA (Robotic Process Automation, ”ohjelmistorobotiikka” in Finnish) is quite a new phenomenon in business process automation. Basically, RPA is a software robot which uses the computer by itself so it’s not a physical robot. The software robot will follow defined business process logic and usually emulates human interactions to execute the process. RPA often uses the graphical user interfaces of the information systems as humans do especially if there are no APIs available. This means that the RPA sits on top of the existing infrastructure and thus is not an intrusive technology.
RPA robots can be categorized into two groups: attended and unattended robots. Attended robots work in human workstations together with human employees. Attended robots can be started by humans or get triggered by events. They can run in the background or ask for human input if needed during the execution of the process. Attended robots can be useful, for example, in the service desk or other customer-facing operations.
Unattended robots work on their own at either physical or virtual cloud workstations without any human intervention. They usually execute high transaction volume processes by automated schedules. Unattended robots can, for example, process accounting tasks during the night so they are finished by the morning when employees come to work. Even though unattended robots work on their own in the background, they can be monitored, audited and managed by human ”robot supervisors”. Skynet is not yet here…

What can RPA do?

Basically, almost anything that humans can do at a workstation. However, robots are still bit dumb so they can’t do something that requires complex human interpretation or thinking. On the other hand, by combining AI with the RPA, robots can do more complex human thinking requiring processes but practical implementations of these are still a bit rare. If the process has inputs in a digital, preferably structured, form and the process can be depicted with e.g. flowchart with unambiguous rules, it is most likely quite easy to automate with RPA.
Typically a companies’ RPA journey starts by automating support function processes:

  • Finance (e.g. reconciliation, purchase to pay, reporting)
  • HR (e.g. onboarding, payroll)
  • IT (e.g. monitoring, user management)
  • Sales and operations (e.g updating inventory, creating invoices)

With RPA, it is possible to use your imagination and do all kinds of fun stuff like making a robot play piano while filling in online forms: https://twitter.com/UiPath/status/1025155664421838849

RPA, chatbots and AI

You can automate a lot of processes with only RPA. However, by combining RPA with chatbots and AI you can do a lot more cool things. For example, RPA could gather data from legacy systems for AI to produce a prediction about maintenance needs for industrial machines. After that, RPA could set those machines to get a maintenance visit at an appropriate time. Finally, a chatbot could inform humans about the upcoming maintenance. RPA, chatbots and AI are interconnected like illustrated in the picture below:
AI, chatbots and RPA
Another example of combining RPA and chatbot is a bot which will buy train tickets for you: https://www.linkedin.com/feed/update/urn:li:activity:6430749212501168128

RPA vs traditional software development

Developing human mimicking RPA robots might not seem so sexy for traditional software developers but both methods have their pros and cons in process automation. During the last couple years, there has been a bit of hype about RPA and automating everything with it but it should be seen as just one tool for process automation and compared to other available methods case by case.
RPA pros:

  • Relatively easy and quick to implement and realize the benefits. With RPA, it’s possible to automate some business processes in just a couple of days or weeks compared to usually a much longer traditional software development time. For example, I have developed an RPA robot in four days which automated a quite tedious financial reconciliation process.
  • Quite low-cost thanks to the quick implementation times and potential quick returns on investment
  • Basics of developing RPA robots is quite easy to learn also for non-software developers
  • Doesn’t disrupt existing infrastructure and systems
  • It’s possible to do UI automation if APIs are not available and access basically every needed system and legacy systems

RPA cons:

  • Changes in existing infrastructure and systems can disrupt RPA robots. If the robot uses the UI of the systems and it changes considerably, the robot may need a reconfiguration
  • Robots need to be managed in case of changes in the processes or IT systems. When scaling up to dozens or hundreds of robots all doing different tasks, managing them needs resources
  • Traditionally developed e.g. integration between two systems is technically more effective than RPA
  • Risk of taking quick wins with RPA and forgetting longer term more traditional system developments

Some RPA technologies:

  • UiPath (current market leader)
  • Blue Prism (main competitor of UiPath)
  • Workfusion (offers a free version for enterprises)
  • Robotframework RPA (Finnish open source solution)

At Gofore we are technology agnostic so we can evaluate your specific automation project and recommend the best technology available for your requirements.

Wow robots seem cool, I want to learn more?!

  • Leave a comment for me – I am happy to help, for example, I could arrange RPA training.
  • Start studying free courses about RPA developer and general business skills online: https://www.uipath.com/rpa/academy
  • Download free community edition of UiPath and try e.g. automate some boring manual task you need to do: https://www.uipath.com/developers/community-edition
  • If you are more of a software developer person you could also try Robotframework RPA

 

Aapo Tanskanen

Aapo Tanskanen

Aapo on erikoistunut vapauttamaan ihmiset tylsistä tietotyön tehtävistä yhdistelemällä uusien teknologioiden mahdollisuuksia. Hänen ydinosaamistaan on chatbotit, data-analytiikka, ohjelmistorobotiikka ja tiedolla johtaminen. Aapo on ollut mullistamassa jokapäiväistä työelämää kehittämällä esimerkiksi juttelevia chatbotteja ja puheella toimivia virtuaaliassistentteja työtuntien kirjaukseen ja junalippujen ostamisen automatisointiin.

Piditkö lukemastasi? Jaa se myös muille.

Service Desk herättää usein mielikuvan rivistä luurit päässä istuvia työntekijöitä vastaamassa jatkuvaan puheluiden virtaan. Puhelun alkaessa avataan asiakasta koskeva ohje auki ja yritetään vaikuttaa siltä, että tunnetaan tämä asiakas ja heidän kanssaan sovitut asiat hyvin. Asiakas tuskin tapaa koskaan kasvotusten henkilöä, jolle hän ilmoittaa jopa bisneskriittisistä sovellushäiriöistä. Toimimaton Service Desk on pahimmillaan kuluerä, joka ei tuota asiakkaalle mitään lisäarvoa.
Onko oma näkemykseni Service Deskeistä siis kielteisesti värittynyt? Ei tietenkään. Viimeiset kuusi vuotta Service Desk -työtä tehneenä tiedän täsmälleen, miten arvokasta työtä siellä tehdään. En kuitenkaan usko Service Deskin arvon olevan yleisesti tunnettu tai tunnustettu organisaatioiden sisällä.

Ihmiset tikettien takana

Service Desk on usein asiakkaan ensisijainen ja tärkein yhteydenottokanava – ja useimmiten heille myös se kaikista kasvottomin. Oltuaan yhteydessä Service Deskiin asiakkaan pitää voida luottaa siihen, että hänen asiansa on parhaissa mahdollisissa käsissä. Hänen tulee tietenkin tuntea nuo kädet ja niihin liittyvät kasvot. Siksi pidän tärkeänä, että asiakkaan häiriöitä ja pyyntöjä ratkovat asiantuntijat tulevat myös nimeltä ja kasvoiltaan asiakkaalle tutuiksi. Säännöllisissä yhteisissä tapaamissa muodostuukin nopeasti omia sisäpiirin vitsejä tai vaihdetaan laskettelureissujen kuulumiset tärkeän asiasisällön ohella.
Onko sillä mitään merkitystä, tapaako asiakas koskaan Service Deskissä istuvia ihmisiä? Se parantaa asiakkaan palvelukokemusta ja asiakassuhteen luotettavuutta. Service Deskin työntekijä on sitoutuneempi tuottamaan parempaa palvelua tutulle kuin tuntemattomalle.

Osataanko Service Deskissä mitään?

Service Desk on murroksessa: aiemmin yrityksen huonoimmin palkattujen, tilapäisten työntekijöiden sijaan siellä onkin palvelun asiantuntijoita. Se, mitä ennen kiivaasti ulkoistettiin halvempiin maihin, ollaankin tuomassa vauhdilla takaisin Eurooppaan. Näin siksi, että automaation ja tekoälyn myötä Service Deskin rooli muuttuu toistuvista taskeista enemmän palvelunhallinnalliseen suuntaan.
Goforella olemme tuoneet kovimmat asiantuntijat osaksi Service Centeriämme. Asiakkaidemme häiriöilmoitukset ja palvelupyynnöt ottaa vastaan omasta tiimistämme löytyvät järjestelmäasiantuntijat. He muodostavat Service Centerimme ensimmäisen tason tuen, joka parhaan kykynsä mukaan pyrkii ratkaisemaan asiakkaiden häiriötilanteet ja pyynnöt nopeasti. Ensimmäisen tason tukemme on siitä poikkeuksellinen, että tavoitteenamme on eskaloida mahdollisimman vähän tikettejä eteenpäin. Useissa Service Deskeissä ensimmäinen taso ainoastaan eskaloi eteenpäin eikä pääse juurikaan itse ratkaisemaan asiakkaan ongelmia.
Jokaista Service Centerimme piirissä olevaa asiakasta kohden on olemassa myös toisen tason tuki, joka muodostuu sovelluksen tai palvelun alun perin pystyttäneistä sovelluskehittäjistä tai järjestelmäasiantuntijoista. Asiakkaan pyyntö eskaloituu heille, mikäli se vaatii spesifimpää järjestelmän tuntemista. Meillä on siis aina jokaista asiakasta varten henkilö valmiudessa reagoimaan asiakkaan häiriötilanteisiin luvatun palveluajan mukaisesti ja sovittuja palvelutasoja noudattaen.
Jokaista asiakastamme palvelee myös palvelunhallinnan ammattilainen, joka on mukana ylläpidon suunnittelussa parhaimmillaan jo projektin alkumetreiltä lähtien ja jonka tavoitteena on varmistaa palvelumme laatu.

Hissimusiikkia vai nopeaa toimintaa?

Tiedätkö sen tunteen, kun palvelunumeroon soittaessasi kuuntelet muutaman minuutin sitä ihanan särisevää hissimusiikkia ja aina välillä nauhoite kertoo palveluneuvojien olevan edelleen varattuja? Service Centerimme asiakkaana ei tarvitse kyllästyä jatkuvaan puhelimessa roikkumiseen. Viime viikolla kävimme läpi tämän vuoden puheluiden saldon: niitä oli kaksi ja niistäkin toinen oli Service Centeristä asiakkaan suuntaan soitettu. Perinteinen puhelin on jo menneen talven lumia Service Desk -toiminnassa. Chatbotit tekevät vauhdikkaasti tuloaan. Tosin niiden osalta maailma ei vielä ole valmis. Useammin kuin kerran olen törmännyt palveluntarjoajan chattiin, joka lupaa palata asiaani viikon sisällä. Me emme ole valjastaneet chatbottia asiakkaitamme varten, sillä häiriöitä meille ilmoitetaan varsin vähän ja usein niiden ratkaiseminen vaatii koodimuutosta, jolloin chat ei antaisi juurikaan lisäarvoa asiakkaallemme.
Tiedostamme, että ylläpidossa toimiminen on vastuullista työtä, jolla voi pahimmillaan tai parhaimmillaan olla suuri merkitys sekä asiakkaallemme että viattomille sivullisille. Apunamme oleva Seppo-botti varoittaa, mikäli asiakkaalle luvattu SLA uhkaa ylittyä. Olemmekin palvelleet asiakkaitamme joka kuukausi palvelutasovaatimusten mukaisesti – jopa ylittäen vaatimukset ja odotukset! Viimeisen 4 vuoden ajalta SLA-onnistumisemme on kaikkien asiakkaiden osalta seuraavanlainen:

  • häiriöiden reagointiaika: 100 %
  • häiriöiden ratkaisuaika: 100 %
  • palvelupyyntöjen reagointiaika: 100 %

Service Centerimme tärkeänä jäsenenä Seppokaan ei ole kasvoton.

Asiakas ei ole aina oikeassa

Emme keskity pelkästään tuen tuottamiseen, vaan myös tapaan, jolla palvelemme asiakasta. Jokainen asiakaspalvelija tietää, että asiakas ei ole aina oikeassa, mutta asiakkaan tunne ei silti ole koskaan väärä.

”Asiakas ei ole aina oikeassa,

mutta asiakkaan tunne ei ole koskaan väärä.”

 
Mikäli asiakas kokee, että emme palvele heitä riittävän nopeasti, vaikka toimisimmekin sovittujen palvelutasojen mukaisesti, emme voi vain sivuuttaa asiakkaan kokemusta. Teemme parhaamme parantaaksemme asiakkaan tunnetta. Kunnia-asiamme on ylläpitää asiakassuhdetta ja parantaa asiakastyytyväisyyttä.
Meillä on voimakas tahtotila tarjota asiakkaillemme parasta mahdollista palvelua. Sen toteuttaminen alkaa joka aamu yksinkertaisella, mutta sitäkin tehokkaammalla harjoituksella: hymyllä. Asiakaskin voi sen havaita, kun tapaamme kasvotusten.

Jenna Salo

Jenna Salo

Jenna toimii Continous Services Leadina ja palvelupäällikkönä. Jennan jokapäiväisen työn lähtökohtana on tarjota asiakkailleen mielenrauha. Työkulttuuri on myös lähellä hänen sydäntään. Vapaa-ajallaan Jenna on kahden chihuahuan nöyrä palvelija, ja jenkkiautot ja kellohameet saavat hänet takuulla innostumaan.

Linkedin profileTwitter profile

Piditkö lukemastasi? Jaa se myös muille.

AWS Re:Invent 2018, day 5

Today was the last day of the conference and it’s starting to show. People are heading home, so sessions are not that crowded and last session ends around noon / 1pm. People wearing conference badges are thinning out and replaced with more regular tourists.
I managed to get into a very good chalk talk about Cloudformation given by Check Meyer and Ryan Lohan. So a big thanks to them! We had a good discussion about tooling, feature requests and so on. This is also something that many people might overlook. AWS prioritizes features and their implementation on the basis of feedback received from customers. You do not have to be APN partner, done certifications, or anything like that. As Amazon/AWS themselves say, they try to be the most customer-centric company there is. The most important thing is that instead of silently contemplating on a feature or bug you should make yourself heard. Join AWS Developers slack. Use Twitter, AWS forums, email their evangelists or talk to their employees at any event. If the barrier is still too big you can email me or my colleagues and we can bring your case to AWS. Make yourself heard!
Re:Invent 2018

Finally, some tips & tricks in case you find yourself in Re:Invent 2019!

First, don’t be too greedy. There are tons of good sessions but the thing is – the sessions are recorded and can be watched at a later time Youtube. Chalk talks, workshops and hackathons are not. You get to talk to product-teams or their representatives in those. I can highly recommend attending those and if there are competing sessions at the same time try to prioritize chalk-talks and workshops higher than breakout sessions.
Second, as I’ve mentioned in the first post, Las Vegas is designed to remove your money from you. There will be coffee/soda/water provided by Re:Invent as well as some snacks. The expo area is excellent if you want to eat something. There is usually food being served. Hotels are expensive and if you need to buy something there are multiple Walgreens (shops) on the Strip.
Third, keynotes by Andy Jassy and Werner Vogels are great. However, you should consider passing the keynotes if there are some other interesting happening at the same time. For example hackathons or gamedays. Keynotes are usually recorded and any announcements made are also published on Twitter, blogs and so on.
Fourth, when booking your schedule try to cluster up the sessions/workshops/etc you are attending. Moving from one venue to another takes time. Cluster your sessions on certain venues. For example, The Mirage and Venetian are very close to each other. Moving between them is much easier than moving from Mira/Venetian to Aria/Vdara. On the other hand, Aria/Vdara/MGM are situated relatively close to each other.
Fifth, pick your parties. There are TONS of different parties hosted by AWS partners. You cannot visit all so choose early.
Sixth, talk to people. That might not be the easiest thing to do especially for us Finnish whose culture is not extroverted. ”Hey, my name is Aki. What do you with AWS?” and the conversation takes on.
Now it’s time to sign-off and get some rest before starting the long trip back home. Quoting Werner now it’s time to ”Go build”.
Re:Invent
Jeff Bar, Abby Fuller and Simon Elisha before Twitch live

Aki Ristkari

Aki Ristkari

Piditkö lukemastasi? Jaa se myös muille.