Allekirjoitettu sopimus on myynnille onnistuminen. Asiakkaalle se on lupaus siitä, että sovittu työ alkaa. Minua kiinnostaa erityisesti näiden kahden tapahtuman väli. Tietääkö seuraava ihminen, mitä pitää tehdä, vai odottaako asiakas sillä aikaa, kun me kokoamme tietoja?
Olemme rakentaneet tätä vaihetta ResaHostin asiakkuuksille Resapissa. Halusimme yhdistää tarjouksen hyväksymisen työn aloittamiseen niin, että sovitut aloitustehtävät syntyvät hallitusti. Myyjän muistaminen ei voi olla ainoa tapa saada työ liikkeelle.
Elokuussa 2026 teimme tähän muokattavan projektipohjan. Sen nimeksi tuli Asiakkuuden avaus. Pohjaan koottiin hosting-palvelun aloituksen tehtävät, ja se liitettiin allekirjoituksen jälkeiseen työnkulkuun. Työtä hoitavien pitää pystyä ylläpitämään pohjaa samassa paikassa, josta he muutenkin hallitsevat projektipohjia.
Tämä viimeinen kohta kuulostaa pieneltä, mutta oli meille olennainen. Jos automaation ohjaus löytyy eri paikasta kuin käyttäjä odottaa, muutoksia aletaan pyytää kehittäjältä. Silloin tavallinen palvelun parantaminen muuttuu ohjelmistotyöksi. Haluan, että tiimi pystyy kehittämään sovittua työjärjestystä itse.
Tehtävien syntyminen on kuitenkin vasta aloitus. Jokaisesta tehtävästä pitää ymmärtää, mitä valmiina oleminen tarkoittaa. Palvelun siirtämiseen liittyvä tehtävä ei valmistu sillä, että siitä on lähetetty viesti. Joku tarvitsee asiakkaalta tietoja, joku tekee muutoksen ja joku varmistaa lopputuloksen. Näiden vastuiden pitää sopia yhteen.
Asiakkaan kannalta olennaista on myös se, mitä häneltä odotetaan. Jos tarvitsemme tunnuksia tai päätöksen, siitä pitää kertoa ymmärrettävästi. Sisäinen tehtävälista ei auta asiakasta, jos kukaan ei sano hänelle, mikä on seuraava vaihe. Työn aloitus on yhtä paljon viestintää kuin tehtävien hallintaa.
Toimitusjohtajana katson tätä myös kannattavuuden kautta. Myynnissä sovittu palvelu määrittää, mitä tiimi toimittaa. Jos sopimuksen sisältö jää tulkinnanvaraiseksi, epäselvyys tulee vastaan työn aikana. Silloin aikaa kuluu selvittämiseen ja odotukset voivat erota molempiin suuntiin. Hyvä aloitus auttaa havaitsemaan eron ajoissa.
Meille oli tärkeää pitää toteutus palvelukohtaisena. ResaHostin aloitustehtävät eivät automaattisesti kuulu jokaiseen Resacon asiakkuuteen. Hostingin siirto ja markkinointiyhteistyön aloitus tarvitsevat erilaisia työvaiheita. Yhteinen järjestelmä saa tukea näitä eroja, kunhan sen käyttö pysyy ymmärrettävänä.
Tämän takia en aloittaisi automaation suunnittelua piirtämällä mahdollisimman pitkää työnkulkua. Ottaisin yhden palvelun ja kuvaisin sen tavallisen aloituksen. Mitä on jo sovittu? Mitä asiakkaalta puuttuu? Kuka ottaa seuraavan askeleen? Vasta kun vastaukset ovat selvät, niitä kannattaa siirtää ohjelmiston hoidettaviksi.
Resapin oma käyttö tekee näistä tilanteista näkyviä. Samalla pitää muistaa tuotteen vaihe: syyskuussa 2026 julkista julkaisua valmistellaan marraskuulle. Tässä kuvaamani työ on tehty oman palvelumme käytännön tarpeeseen. Se antaa kokemusta, jonka varaan laajempaa tuotetta rakennetaan.
Allekirjoituksen jälkeen asiakkaalle pitäisi tulla olo, että asiat etenevät. Meidän tehtävämme on järjestää työ niin, että tuolle tunteelle on myös katetta.
Tämä oli yksi niistä syistä, joiden vuoksi aloimme rakentaa Resappia oman liiketoimintamme arjessa.
