Tämä artikkeli ohjeistaa AI Commerce -alustan käyttöönoton eri vaiheista partnerin näkökulmasta. Se ei määritä yhtä ainoaa toteutustapaa, vaan kokoaa vuosien aikana hioutuneita käytäntöjä kitkattomaan käyttöönottoon ja pitkäjänteiseen jatkopalveluun. Ohjeistus koskee partnereiden toteuttamia ratkaisuja, ei AI Commercen sisäistä toimitusmallia. AI Commercen virallinen suositus on, että partnerit vastaavat käyttöönotosta sekä toimivat asiakkaan ensisijaisena yhteyshenkilönä ja konsulttina. Tämä mahdollistaa kauppiaalle mallin, jossa maksetaan asiantuntijatyöstä ja kustomoidusta kehityksestä tarpeen mukaan – skaalautuen joustavasti liiketoiminnan mukana ja välttäen sekä yli- että aliresursoinnin. Käyttöönotto alkaa usein osittain jo myyntiprosessin aikana, jolloin asiakkaalle voidaan hahmotella esimerkkejä tietovirtamalleista ja mahdollisesta käyttöliittymän ulkoasusta.

Periaatteet ja roolit

• Partneri suunnittelee ja toteuttaa käyttöönoton, koordinoi aikataulut ja toimii asiakkaan ensisijaisena kontaktina.
• AI Commerce tarjoaa teknologian, ympäristöt ja tarvittaessa tukea (esim. valmiit rajapinnat ja komponentit), mutta varsinainen projektitoimitus on partnerivetoista.
• Kauppias vastaa liiketoimintavaatimuksista, tuote- ja sisältödatasta sekä päätöksenteosta – partneri ohjaa ja auttaa.

Käyttöönotto alkaa myynnissä

Myyntivaiheessa voidaan tehdä ensimmäiset hahmotelmat Miroon (kartoitukset, kaaviot, muistiinpanot) ja näyttää esimerkkiluonnoksia tietovirroista sekä käyttöliittymästä. Näiden materiaalien pohjalta käynnistyy varsinainen monivaiheinen etenemä.

Monivaiheinen etenemä

Vaihe 1: Alkukartoitus ja markkinakatsaus

• Nykytilan analyysi: asiakkaan data (esim. Google Analytics), asiakkaiden käyttäytyminen sivuilla, liikenteen lähteet, laskeutumissivut ja kaupankäynnin kannalta olennaiset KPI-mittarit.
• Kilpailija-analyysit: kilpailijoiden sivut inspiraation ja ideoiden lähteenä tulevan käyttöliittymän suunnitteluun.
• Työskentelytapa: asiakas on aktiivisesti mukana, mutta varsinainen tutkimustyö tehdään paljolti taustalla asiakkaan aikaa kunnioittaen. Pyydä vain välttämättömät lähtötiedot, jotta prosessi on asiakkaalle kevyt mutta tuottoisa.

Vaihe 2: UI/UX-suunnittelu (Miro → Figma)

• Lähtöaineisto: Miroon tehdyt kartoitukset ja sketsit (esim. mustavalkoiset ”tikku-ukko” -hahmotelmat) siirretään Figman käyttöliittymäsuunnitteluun.
• Komponenttikirjasto: hyödynnä AI Commercen laajaa komponenttikirjastoa. Rakennetaan ”Lego-linna” valmiista palikoista asiakkaan näköiseksi kokonaisuudeksi; vain puuttuvat palikat luodaan uutena.
• Kustannustehokkuus: valtaosa koodista on jo olemassa eri tenanteissa; yhdistelmistä syntyy asiakkaalle uniikki toteutus. Tyypillisesti vain pieni prosentti komponenteista rakennetaan alusta.
• Resurssikehys: sovi asiakkaan kanssa esim. 20–40 tuntia UI-suunnitteluun; mahdolliset ylitykset laskutetaan erikseen (esim. kevennetysti). Tämä tuo joustoa asiakkaalle ja ennakoitavuutta partnerille.
• Suunnittelun lukitus: suunnittele UI ”valmiiksi”, hyväksytä asiakkaalla ja tarvittaessa käyttäjätestaa ennen kehitykseen siirtymistä.

Vaihe 3: Implementointi (Svelte, Frontend‑as‑a‑Service tai oma ympäristö)

• Resurssit: partnerin omat tai alihankitut kehittäjät siirtävät Figman ratkaisut tuotantokoodiksi.
• Ympäristö: AI Commerce pystyttää tarvittaessa ympäristön ja toimittaa pääsyt. Taustalle valitaan sopiva pohja (template), joka vastaa suunnittelua – nopeampi kuin tyhjästä aloittaminen.
• Teknologia: toteutus Svelte-pohjaiseen AI Commerce Frontend‑as‑a‑Service -ympäristöön tai partnerin omaan ympäristöön.
• Työskentelytapa: kustomoi olemassa olevista teknisistä komponenteista – tämä on nopeampaa kuin alusta rakentaminen.
• Dokumentaatio: AI Commercella on erillisiä teknisiä dokumentaatioita; tässä artikkelissa ei syvennytä niihin.
• Demo: kun käyttöliittymä on valmis demo-ympäristössä (esim. ”asiakas.icommerce.cloud”) ja asiakas hyväksyy sen, voidaan siirtyä kohti go-liveä.

Vaihe 4: Rinnakkaiset työt – rajapinnat ja integraatiot

• Kattavuus: asiakkailla on usein integraatioita eri järjestelmiin. Ne tehdään partnerin toimesta tai hyödynnetään AI Commercen olemassa olevia rajapintoja.
• Hinnoittelu: valmiiden AI Commerce -rajapintojen käyttö on yleensä kevyemmin hinnoiteltu (pieni konfigurointikorvaus). Oman rajapinnan rakentamisessa hinnoittelu on vapaa, mutta kustannukset ja riskit kasvavat helposti.
• Uudelleenkäyttö: jos olette jo toteuttaneet integraation tiettyyn toiminnanohjausjärjestelmään ja tarpeet ovat samankaltaiset, uudelleenkäyttö pienentää riskiä ja nopeuttaa toteutusta.
• Suunnittelu Mirossa: kartoita tietovirtamallit: mitä asiakas haluaa, mitä dokumentaatiota rajapinnan tarjoajalta on saatavilla ja miten rajapinnan tulee toimia. Laadi yhteenveto ennen rakentamista.
• Lukitus ennen kehitystä: rajapintojen logiikka tulee lyödä lukkoon ennen toteutusta, koska rajapintoja voi kustomoida käytännössä rajattomasti ja yksittäinen muutos voi edellyttää laajaa refaktorointia.

Rakennusanalogia API-projektiin: WC:n siirto

Pieni liiketoimintamuutos voi olla teknisesti iso. Jos vaatimuksia muutetaan kesken toteutuksen, vaikutus voi ulottua useaan sanomaan ja koko arkkitehtuuriin – aivan kuten valmiiksi viimeistellyssä huoneistossa WC:n siirtäminen toiseen nurkkaan vaatii pintojen avaamista, lattialämmityksen rikkomista ja putkien siirtoa. Siksi suunnittele ensin tarkasti ja toteuta vasta sitten.

Vaihe 5: Sisältö ja tuotedata

• Vastuut: korosta asiakkaalle selkeästi, että tuotesisällöt ja verkkosivujen tekstisisällöt ovat asiakkaan vastuulla. Niiden täysi ulkoistaminen partnerille on usein ylilupaus.
• Laajuus: tuotetiedon rikastaminen on suuri kokonaisuus. AI Commerce tarjoaa työkaluja ja mahdollisuuksia, mutta vaatii silti asiakkaalta osaamista ja panostusta.
• Starttaa ajoissa: aloita tuotedatan siirrot ja rikastaminen mahdollisimman varhain.
• Migraatiot: partneri voi auttaa esimerkiksi CSV-ajoilla siirtämään tuotteita, asiakkuuksia ja tilauksia uuteen järjestelmään – tämä on usein erikseen laskutettava ja tärkeä kokonaisuus.
• CMS-käyttö: asiakasta voidaan opastaa Builder.io:ssa tai muussa CMS:ssä tietosisältösivujen (ei UI-komponenttien) ylläpitoon.
• Ammattiviestintä: koko sisällön tuottamista ei suositella partnerille; se on oma viestintäprojekti.
• Viiveiden yleisin syy: go-live myöhästyy tyypillisimmin keskeneräisen tuotedatan tai sisältösivujen vuoksi – harvoin partnerin tai alustan työn odottamisesta.

Vaihe 6: Hyväksyntä ja go-live -valmistelu

• Hyväksyntä: kun demo on hyväksytty, viimeistele tarkistuslistat ja go-live -valmistelut. Näistä on erillinen artikkeli, joka avaa tarkistusvaiheet.

Vaihe 7: Julkaisu (”go-live”)

• Ajoitus: toteuta yöaikaan, hiljaisena ajankohtana tai viikonloppuna liiketoimintahaitan minimoimiseksi.
• Uudelleenohjaukset ja tarkistukset: varmista, että uudelleenohjaukset toimivat. Tee pistotarkistuksia, jotta aiemmin kertynyt arvo ei katoa.
• Tilauskannan synkronointi: tarvittaessa siirrä ja synkronoi tilauskanta niin, että tilausnumerot jatkuvat loogisesti vanhasta järjestelmästä.
• Roolit: AI Commerce on tekninen kumppani go-livessä; partneri ei ole yksin.

Vaihe 8: Hypercare ja jatkuva kehitys

• Hypercare: varaa vähintään viikko livetyksen jälkeen. Ajoita rauhalliseen aikaan, jotta partnerilla on kapasiteettia hoitaa esiin nousevat asiat.
• Vastuu: go-liven jälkeinen kiirepiikki liittyy useimmiten partnerin ratkottaviin asioihin. Kauppiaalle lisäkuorma on tyypillisesti vähäisempi.
• Ylläpito kevenee: hypercaren jälkeen siirrytään normaaliin ylläpitoon ja jatkuvaan kehitykseen.
• Arvo asiakkaalle: myy ja konsultoi ratkaisuja, jotka parantavat myyntiä tai tehostavat prosesseja. Esimerkkejä:
  • AI Commercen julkaisemien ominaisuuksien käyttöönotto (esim. uusi konversioseuranta, uusi hakumoottori).
  • Tekoälykäännösten käyttöönotto: auttaminen API-avainten (esim. OpenAI) asennuksessa ja prosessin läpiviennissä.
  • Käyttöliittymän jatkokehitys: pienkorjaukset ja uudet toiminnot tarpeen mukaan.
• Myynnin peruskaava: keskity ajureihin – liikenne, konversio ja keskiostos. Myynti ≈ liikenne × konversio × keskiostos.
• Tehokkuus: asiakkaalle jokainen uusi ominaisuus on investointi. Tarjoa automaatioita ja apua prosessien tehostamiseksi.
• Pitkä kumppanuus: arvoa tuotetaan kahdella osa-alueella – myynnin kasvattaminen ja prosessien tehostaminen.

Työkalut ja termit

• Miro: kartoitukset, kaaviot, tietovirtamallit.
• Figma: käyttöliittymän suunnittelu komponenttikirjastolla.
• Svelte & Frontend‑as‑a‑Service: AI Commercen toteutusympäristö tai partnerin oma ympäristö.
• Google Analytics: nykyliikenteen ja käyttäytymisen analysointi.
• Builder.io tai muu CMS: tietosisältösivujen hallinta.

Laskutus ja sopiminen

• Tämä artikkeli antaa suosituksia toimiviksi todetuista malleista, mutta ei ota kantaa yksittäisen projektin laskutusmalliin.
• UI-suunnitteluun kannattaa sopia selkeä tuntikehys (esim. 20–40 h) ja määritellä, miten ylitykset laskutetaan.
• Integraatioiden ja migraatioiden osalta määrittele laajuus ja veloitus erikseen.

Yhteenvetona

Partnerivetoisen toimitusmallin ydin on suunnitella huolellisesti (Miro → Figma), koodata tehokkaasti valmiita komponentteja hyödyntäen, lukita integraatiologiikka ennen toteutusta, aloittaa sisällöt varhain ja viedä ratkaisu tuotantoon hallitusti. Go-liven jälkeen panosta hypercareen, jatkuvaan kehitykseen ja asiakkaalle mitattavaa arvoa tuottaviin toimenpiteisiin.