En ny nettside eller nettbutikk bør gjøre det lettere å bli kunde og enklere for bedriften å levere. Før dere velger plattform, bør dere derfor følge en kunde fra første spørsmål til kjøp, levering og oppfølging. Det viser hvilke deler som allerede fungerer, hvor dere mister tid, og hva som faktisk trenger å bygges.
Hos Færder Marketing vil vi bruke denne gjennomgangen til å vurdere om dere bør forbedre dagens løsning, koble sammen eksisterende verktøy eller utvikle noe nytt. WordPress, Astro, Lovable og egen kode kan ha ulike roller. Valget bør komme etter at oppgaven er tydelig.
Følg én konkret kunde gjennom bedriften
Velg en vanlig kundetype og ett typisk kjøp. Skriv ned hva kunden trenger å vite, hva kunden gjør, og hva som skjer internt etter hver handling. Ta med menneskene som faktisk svarer på henvendelser, behandler bestillinger og hjelper kundene etterpå.
- Finne dere: Hvilket spørsmål eller behov leder kunden inn?
- Velge: Hvilken informasjon gjør tilbudet forståelig og relevant?
- Ta kontakt eller kjøpe: Hvilke opplysninger trenger dere, og hva får kunden bekreftet?
- Levere: Hvem tar over, og hvilke systemer bruker de?
- Fakturere og følge opp: Hvordan håndteres betaling, spørsmål, returer og nye behov?
Marker steder der noen må kopiere informasjon, lete etter status eller spørre kunden om noe dere allerede har fått. De punktene er kandidater for forbedring. Ikke alle trenger automatisering; noen løses med en tydeligere rutine og en ansvarlig person.
Et eksempel: Fra riktig produkt til en bestilling som kan leveres
Tenk deg en bedrift som selger produkter med flere størrelser og tilvalg. Dette er et fiktivt eksempel. Kundene er usikre på hva som passer, og de ansatte må ofte ringe for å avklare bestillingen. En ny visuell profil alene løser neppe den oppgaven.
En bedre løsning kan være en veiviser som forklarer valgene og gir en tydelig oppsummering. Men produktvalget må også kunne overføres riktig til ordren. Lageret må vite hva som skal plukkes, kundeservice må se samme informasjon, og en endring eller retur må kunne håndteres.
Her kan egen kode være nyttig i selve veiledningen, mens et etablert handelssystem håndterer bestilling og betaling. Hvis behovet kan løses godt med eksisterende funksjoner, bør det vurderes først. Hver ny kobling tilfører både muligheter og noe som må vedlikeholdes.
Vi kan også bygge reglene bak handelen selv når virksomheten trenger større frihet. Tenk for eksempel på en seng med ulik fasthet på hver side, stoff, ben og gavl. I dette tenkte eksemplet lagrer kunden oppsettet, får hjelp av en ansatt og bestiller levering og montering. Da må systemet forstå både kundens valg, delene med egne varenummer og hva lageret eller leverandøren faktisk skal levere.
Astro kan være en del av en skreddersydd nettbutikk
Et mulig oppsett er Astro for produkt-, kategori- og innholdssider, React for konfigurator og handlekurv, og egne serverfunksjoner for produktregler, priser og ordre. Astro støtter både interaktive komponenter og sider som bygges ved besøk. Dette er beskrevet i dokumentasjonen for dynamiske sider.
Det avgjørende er hvem som bestemmer datamodellen og forretningsreglene. En ny frontend koblet til et eksisterende handelssystem gir fortsatt det systemet en sentral rolle. Vil vi forme også handelslogikken selv, må den utvikles, testes og vedlikeholdes som en egen del av leveransen. Astro er ett mulig rammeverk for kundesidene; et system som hovedsakelig består av innloggede arbeidsflater kan ha andre behov.
Databasen og administrasjonen må passe arbeidshverdagen
PostgreSQL er et mulig valg for produkter, kunder og ordre. Supabase tilbyr PostgreSQL sammen med blant annet innlogging og fillagring. Vi kan vurdere en slik administrert tjeneste eller egen drift ut fra kompetanse, kapasitet og krav. Se Astros veiledning om Supabase. En database alene gir ikke en ferdig nettbutikk.
Planlegg hvordan ansatte skal redigere produkter, behandle delvise leveringer og følge opp kunder uten å endre kode. Avtal også hvilket system som bestemmer pris og lager når nettbutikken er koblet til andre systemer. Å kunne eksportere databasen er nyttig, men flytting kan kreve arbeid med innlogging, filer og integrasjoner i tillegg.
Velg hva dere skal beholde, kjøpe og bygge
Del løsningen i oppgaver før dere sammenligner plattformer. Dere trenger kanskje et sted å publisere innhold, et sted å registrere kunder og et sted å håndtere ordre. Disse delene kan ligge i ett system eller flere. Færre systemer gir ikke alltid mindre arbeid, og flere systemer gir ikke automatisk mer fleksibilitet.
Bruk disse vurderingene som utgangspunkt:
- WordPress: aktuelt når redigering av sider og artikler er sentralt, og nødvendige funksjoner kan dekkes av et håndterbart oppsett. Undersøk utvidelser, drift og redaktørenes faktiske arbeidsflyt.
- Astro med et passende innholdssystem: aktuelt når vi vil forme nettsidens struktur, innhold og interaktive deler mer direkte. Redigering, integrasjoner og vedlikehold må planlegges.
- Lovable og andre AI-verktøy: aktuelle i arbeidet med å konkretisere og utvikle funksjoner. Vurder den ferdige løsningens kode, databehandling og drift, uansett hvordan den ble laget.
- Et etablert nettbutikksystem: aktuelt når standard handel dekker behovet godt. Kontroller produktvarianter, priser, betaling, frakt, returer og koblinger til eksisterende drift.
- Egenutviklede funksjoner: aktuelle der bedriftens særpreg eller arbeidsmåte gir et konkret behov standardverktøyene ikke løser godt nok.
Dette er vurderinger, ikke en rangering. En god løsning kan kombinere flere av delene. Et velfungerende WordPress-nettsted kan for eksempel få en avgrenset ny funksjon uten at hele nettstedet må erstattes.
En nettbutikk må tåle mer enn et vellykket prøvekjøp
Avklar hvilket system som bestemmer produktinformasjon, pris, lagerbeholdning og ordrestatus. Hvis den samme opplysningen kan endres flere steder, trenger dere en regel for hvilken versjon som gjelder. Ellers kan en tilsynelatende enkel integrasjon skape mye manuelt oppryddingsarbeid.
Test også en avvist betaling, en utsolgt vare, en delvis retur og en midlertidig feil i koblingen til regnskapet. En bestilling må kunne spores videre selv om én tjeneste er utilgjengelig. Avtal hvordan ansatte oppdager og retter feil, og hvordan kunden får en forståelig beskjed.
Start gjerne med én komplett kjøpsreise i et testmiljø: konfigurere produktet, kontrollere pris og levering, betale i testmodus og behandle ordren i administrasjonen. Ta også med lagerreservasjon, gjentatte betalingsmeldinger og refusjon. Det gir et bedre beslutningsgrunnlag før hele katalogen og flere funksjoner bygges ut.
La betaling og andre kritiske standardfunksjoner håndteres av løsninger som er egnet til oppgaven. Verdien av egenutvikling ligger ofte i veiledningen, produktvalget eller arbeidsflyten rundt handelen. Den trenger ikke ligge i å skrive alle delene selv.
For butikker med sammensatte produkter og egne arbeidsprosesser går vi nærmere inn på skreddersydd nettbutikk med Astro, egen handelslogikk og database. Der viser vi også hva som må planlegges for administrasjon, betaling og drift.
Regn på kostnaden over tid
Be om et anslag for både oppstart og videre drift over for eksempel tre år. Skill mellom utvikling, løpende tjenester, vedlikehold, forventede endringer og bedriftens egen arbeidstid. Ta med kostnader som avhenger av antall brukere, ordre, lagring eller faktisk bruk av AI-funksjoner.
Vurder også hva dere forventer å få igjen. Mindre dobbeltregistrering, færre ufullstendige forespørsler og bedre oversikt kan ha verdi. Beskriv hvordan dere vil undersøke dette etter lansering. Forventet tidsbesparelse er en antakelse frem til den er målt i den faktiske arbeidsflyten.
Gjør eierskap og overtakelse til en del av bestillingen
Be om at tilbudet forklarer eierskap og bruksrett til kode, design og innhold. Avklar hvem som kontrollerer domene og tjenestekontoer, hvilke lisenser som må videreføres, og hvordan dere kan hente ut data. En eksport bør inneholde det dere trenger for å bruke opplysningene videre, ikke bare en fil med uklare felter.
Spør hvordan en annen leverandør kan ta over. Det krever dokumentasjon, nødvendige tilganger og en forståelig måte å bygge og publisere løsningen på. Tilgang til et kodearkiv alene viser ikke at driften er overførbar.
Planlegg overgangen fra det dere har
Kartlegg nyttige sider, adresser, innhold og integrasjoner før dere bytter. Bevar viktige URL-er der det er mulig. Adresser som endres, trenger relevante omdirigeringer og kontroll av lenker. Google beskriver forberedelsene i veiledningen for nettstedflytting.
Avtal også hvem som kontrollerer skjemaer, ordre, måling og kundemeldinger etter lansering. Bestem hvordan dere kan gå tilbake hvis en kritisk funksjon svikter. Ved større endringer kan det være fornuftig å innføre én avgrenset del først og lære av den før resten bygges om.
Et godt grunnlag for første samtale
Samle kundetypen dere vil hjelpe, én vanlig kundereise, dagens systemer, de største hindringene og hvem som skal bruke løsningen internt. Legg til budsjett, tidsramme og hva som må fungere fra første dag. Da blir det mulig å gi et begrunnet forslag til både omfang og teknologi.
Bruk gjerne de seks avklaringene før en ny nettside til arbeidet med selve nettstedet. Les også hvorfor vi bygger mer med Astro og AI og hva dere bør få kontrollert om sikkerhet. Når dere vil diskutere det konkrete behovet, kan dere sende oss en forespørsel.
