Mitä tehdä, jos asiakkaan etu on ristiriidassa oman liiketoiminnan kanssa?

💰 Mitä tehdä, jos asiakkaan etu on suorassa ristiriidassa oman liiketoiminnan kanssa? 

Arvoista on helppo puhua silloin kun liiketoiminta porskuttaa hyvin.

Mutta kun toisessa vaakakupissa alkaa painaa rahan menetys, vasta silloin arvot pannaan testiin.

Kerron tapauksesta, johon sekoittuu harmitusta (tai no, v-sanaa) sekä samanaikaisesti ylpeyttä omista konsulteistamme.

Juttu meni näin.

Meiltä oli kaksi konsulttia asiakkaan projektissa.

Kyseistä järjestelmää oli tehty vuosi.

Rahaa oli palanut useampi sata tuhatta euroa.

Asiakas käytti myös toista järjestelmää, jonka kehitys ostettiin yksityisen tarjoajan kautta.

Järjestelmissä oli osittaisia päällekkäisyyksiä.

Yksityisen tarjoajan sovellus toimi simppelimpien parametrien pohjalta.

Asiakkaan oma sovellus taas oli sofistikoituneempi ja perustui laajaan, käyttäjiltä kerättyyn dataan.

Asiakas halusi nostaa ulkoisen toimittajan järjestelmän käyttöastetta, jotta lisenssimaksulle saataisiin enemmän vastinetta.

Se taas vaati oman sovelluksen tiukempaa integroimista ulkoisen tarjoajan järjestelmään.

Integraatio annettiin meidän konsulttiemme suunniteltavaksi.

He alkoivat pohtia kokonaisuutta.

Integraatio sinänsä onnistuisi verrattain helposti.

Mutta jatkossa admin-käyttäjät joutuisivat tekemään töitä kahdessa järjestelmässä.

Samaan aikaan oman järjestelmän toiminnallisuuksista 2/3-osaa muuttuisi turhaksi.

Lisäksi ylläpidon määrä suhteessa omasta järjestelmästä saatuihin hyötyihin olisi epäsuhtainen.

Arvioituaan tilannetta konsulteista tuntui järjettömältä tehdä integraatio vain siksi että oma järjestelmä voitaisiin säilyttää.

Jompaa kumpaa sovellusta täytyisi laajentaa toisen toiminnallisuuksilla, ja vain yksi sovellus kannattaisi säästää.

He tiedostivat, että asian esiin nostaminen asiakkaan kanssa voisi johtaa heidän töidensä katoamiseen ja Compilen asiakkuuden menetykseen.

Toisaalta olisi asiakkaan liiketoiminnan kannalta järjetöntä raahata perässä turhaa painolastia.

Joten konsultit päättivät ottaa asian puheeksi.

Asiakas kuunteli tarkkaan ja aloitti keskustelut organisaatiossa.

Pitkän pohdinnan sekä ulkoiselta tarjoajalta saamansa hyvän tarjouksen jälkeen asiakas päätyi kuoppaamaan oman järjestelmänsä kehitystyön.

Molemmat konsultit irtisanottiin.

Heitä ja meitä muita compilelaisia tietysti harmitti.

Mutta olimme myös ylpeitä konsulttiemme periaatteellisuudesta.

Asiakas oli hyvillään ja kiitollinen siitä, että konsultit uskalsivat nostaa asian puheeksi, ja että asiakas sai liiketoimintaansa järkevöitettyä.

Uskon, että asiakkaan edun laittaminen oman välittömän hyödyn edelle rakentaa pitkässä juoksussa vahvempia asiakassuhteita – ja on myös parempaa liiketoimintaa.

Mitä sanot, oliko konsulttien veto naiivia hölmöyttä vai esimerkillistä toimintaa?

Seuraa meitä Linkedinissä niin tiedät aina, mitkä ovat ohjelmistokehityksen toimivimmat käytännöt juuri nyt.

eNPS-mittaus perustuu Fred Reichheldin kehittämään Net Promoter Score -mittariin, jolla alunperin tutkittiin yritysten asiakaskokemusta ja asiakastyytyväisyyttä. Myöhemmin sitä on alettu käyttää myös työntekijätyytyväisyyden tutkimiseen (e niin kuin employee + NPS).

Näin mittaus tehdään.

Kysymme työntekijöiltämme kerran kertaa vuodessa, että “kuinka todennäköisesti suosittelisit työpaikkaasi ystäville tai tutuille asteikolla 0-10?”. Sen jälkeen pyydämme tarkennusta avoimella kysymyksellä: ”mistä syystä annoit tämän tuloksen?”.

Niitä, jotka antavat luvuksi 9 tai 10, kutsutaan suosittelijoiksi. Niitä, jotka antavat luvuksi 0-6, kutsutaan kriitikoiksi.

eNPS-tulos lasketaan vähentämällä suosittelijoiden suhteellisesta prosenttiosuudesta kriitikoiden suhteellinen prosenttiosuus. Muut vastaukset saavat arvon 0.

Mittarin tulokset voivat olla mitä vain -100 ja +100 väliltä. Yli nollan nousevat tulokset ovat tyydyttäviä. +10 ja +30 välillä olevia tuloksia pidetään hyvänä, ja yli +50 olevia tuloksia pidetään erinomaisena.