Tegn ordreflyten før dere bygger en profesjonell WooCommerce-butikk

En profesjonell WooCommerce-butikk er ikke bare en produktkatalog med betalingsløsning. Den er en ordremotor som skal flytte riktige data mellom kunden, lageret, betalingen, frakten, økonomisystemet og kundeservice.

Mange problemer oppstår fordi disse delene planlegges hver for seg. Produktansvarlig bestemmer varianter, markedsavdelingen utformer produktsidene, økonomiavdelingen velger regnskapssystem og utviklerne kobler sammen løsningene. Først når butikken tas i bruk, oppdager virksomheten at systemene har ulike varenummer, ordrestatusene betyr forskjellige ting, eller refusjoner må håndteres manuelt.

En bedre tilnærming er å tegne hele ordreflyten før dere bygger eller videreutvikler butikken. Da blir det tydelig hvilke data, regler og avvik WooCommerce faktisk må håndtere.

Start med én konkret ordre

Ikke begynn med en lang liste over funksjoner. Velg en vanlig ordre og følg den fra produktet opprettes til kjøpet er ferdig bokført og eventuelt returnert.

En typisk ordreflyt kan beskrives slik:

1. Et produkt opprettes eller oppdateres i systemet som eier produktdataene.
2. Pris, lagerstatus og annen nødvendig informasjon blir tilgjengelig i nettbutikken.
3. Kunden finner produktet og velger riktig variant.
4. Kunden legger varen i handlekurven og går til checkout.
5. Betaling autoriseres eller gjennomføres.
6. Ordren sendes til lager, fraktløsning og økonomisystem.
7. Varen plukkes, pakkes og sendes.
8. Kunden mottar leveringsinformasjon.
9. Betalingen fullføres og ordren bokføres etter avtalte regler.
10. En eventuell retur, kansellering eller refusjon behandles.

Beskriv deretter hva som kan gå galt i hvert trinn. Hva skjer hvis lageret avviser ordren, betalingsbekreftelsen kommer sent, eller økonomisystemet er utilgjengelig? Den profesjonelle ordreflyten kjennetegnes ikke bare av at normaltilfellet virker. Den må også ha kontrollerte avviksløp.

Produktstrukturen må støtte hele verdikjeden

Produktstrukturen avgjør mer enn hvordan produktsiden ser ut. Den påvirker lagerstyring, søk, filtrering, annonsering, ordrebehandling, returer og rapportering.

Avklar først hva som er et eget produkt, hva som er en variant, og hva som bare er tilleggsinformasjon. En skjorte kan for eksempel ha størrelse og farge som varianter dersom hver kombinasjon har eget varenummer og lagerbeholdning. Materiale, passform og vaskeanvisning kan være produktdata uten å skape nye varianter.

For mange varianter gjør både administrasjon og produktsider tyngre. For få varianter kan gjøre lagerstyring og ordrebehandling upresis. Bruk den faktiske vareflyten som kriterium, ikke bare ønsket om en bestemt visning i nettbutikken.

Avklar eierskap til sentrale produktdata

• Varenummer: Hvilket system oppretter og eier den unike identifikatoren?
• Produktnavn: Skal navnet komme fra et forretningssystem eller redigeres for nettbutikken?
• Pris: Hvor beregnes ordinær pris, kampanjepris, kundespesifikk pris og merverdiavgift?
• Lager: Er beholdningen fysisk, disponibel eller beregnet etter reserverte varer?
• Kategorier: Er de laget for kundens navigasjon, intern rapportering eller begge deler?
• Fraktdata: Hvor vedlikeholdes vekt, mål, farlig gods og andre opplysninger transportøren trenger?

Unngå at flere systemer kan overskrive de samme feltene uten klare regler. Hvis både WooCommerce og et eksternt system kan endre lagerbeholdningen, må dere vite hvilken verdi som gjelder ved konflikt.

Checkout skal samle inn det ordren trenger

Checkout bør være så enkel som mulig, men ikke enklere enn ordreprosessen tillater. Hvert felt må ha en definert funksjon. Hvis ingen bruker kundens stillingstittel i levering, fakturering eller kundebehandling, bør den normalt ikke etterspørres.

Skill mellom informasjon kunden må oppgi, informasjon systemet kan utlede, og informasjon som kan samles inn senere. Postnummer kan for eksempel brukes til å finne sted, mens konto og passord ofte kan opprettes etter at kjøpet er gjennomført.

For bedriftskunder kan checkout kreve organisasjonsnummer, referanse, innkjøpsnummer eller fakturamerking. Disse feltene må ikke bare vises i nettbutikken. De må følge ordren helt frem til systemet og dokumentet som faktisk bruker dem.

Definer reglene bak valgene

Leverings- og betalingsvalg bør styres av eksplisitte regler. Hvilke metoder gjelder for bestemte land, postnumre, varetyper, vektklasser eller kundegrupper? Kan en ordre med både lagervarer og bestillingsvarer deles? Hva skjer dersom kunden velger hentested og dette blir fullt før ordren behandles?

Test også valideringen. Feilmeldingen må forklare hva kunden skal rette, og informasjonen kunden allerede har fylt ut, bør bevares. En teknisk feil etter at kunden har forsøkt å betale, må ikke lokke kunden til å opprette flere identiske ordre.

Ordrestatus er forretningslogikk

Standardstatusene i WooCommerce kan være et godt utgangspunkt, men de beskriver ikke nødvendigvis hele arbeidsprosessen. En ordre kan være betalt uten å være sendt, sendt uten å være bokført eller delvis refundert uten å være avsluttet.

Lag en enkel statusmodell som viser hva hver status betyr, hvem som kan endre den, og hvilke handlinger endringen utløser. Unngå statuser som bare gir mening for utviklerne.

For hver status bør dere avklare:

• Om lager skal reserveres eller reduseres.
• Om betaling skal autoriseres, trekkes, kanselleres eller refunderes.
• Om kunden skal motta en melding.
• Om ordren skal sendes til lager eller økonomisystem.
• Om ansatte fortsatt kan endre ordrelinjer og adresse.
• Hvordan delvis levering og delvis retur håndteres.

Bruk ordrestatus til å beskrive hvor ordren befinner seg, ikke som en skjult knapp for tilfeldige integrasjonshandlinger. Hvis en integrasjon feiler, bør det finnes en egen feilmelding og mulighet for nytt forsøk uten at ansatte må flytte ordren frem og tilbake mellom statuser.

Integrasjoner må tåle forsinkelser og duplikater

Integrasjoner bør ikke bygges med en forventning om at alle systemer alltid svarer umiddelbart. Nettverk feiler, tjenester har vedlikehold, og data kan komme i en annen rekkefølge enn forventet.

Hver overføring bør derfor ha en unik identifikator, tydelig logg og kontrollert mekanisme for nye forsøk. Mottakersystemet bør kunne gjenkjenne at samme ordre allerede er behandlet. Ellers kan et nytt forsøk opprette doble forsendelser, bilag eller reservasjoner.

Dokumenter retningen på dataene

Lag en oversikt som viser avsender, mottaker, tidspunkt og ansvar for hver dataflyt. Eksempler er produkt fra forretningssystem til WooCommerce, ordre fra WooCommerce til lager, sporingsnummer tilbake til WooCommerce og refusjon fra betalingsløsning til økonomisystem.

Ta også stilling til manuelle endringer. Hvis kundeservice korrigerer en adresse i WooCommerce etter at ordren er sendt til lageret, blir endringen da overført? Hvis ikke, må grensesnittet varsle tydelig om at adressen må endres et annet sted.

Ytelse må måles i de viktige overgangene

En rask forside hjelper lite dersom variantvalg, handlekurv eller checkout er treg. Prioriter målinger av handlingene som påvirker kjøpet: produktsøk, filtrering, åpning av produktside, oppdatering av handlekurv, beregning av frakt og innsending av ordre.

Integrasjoner bør normalt ikke gjøre checkout avhengig av flere langsomme eksterne svar. Vurder hvilke oppslag som må skje mens kunden venter, hvilke data som kan mellomlagres, og hvilke oppgaver som kan utføres etter at ordren er mottatt.

Store produktkataloger krever dessuten disiplin i bruk av attributter, produktspørringer og filtre. En funksjon som fungerer fint med et lite sortiment, kan bli tung når antallet produkter, varianter og prisregler øker. Test derfor med realistiske datamengder og samtidige ordreprosesser, ikke bare noen få eksempelprodukter.

Gjør ordreflyten mulig å drifte

Når butikken er lansert, trenger virksomheten mer enn teknisk overvåking. Den må kunne oppdage at ordre står fast, betalinger mangler, lageroverføringer feiler eller sporingsnumre ikke kommer tilbake.

Lag en daglig kontroll som kan utføres av drift eller kundeservice:

• Se etter ordre som har stått uvanlig lenge i samme status.
• Kontroller betalinger uten tilhørende ferdig ordre.
• Finn ordre som ikke er overført til lager eller økonomisystem.
• Følg opp mislykkede integrasjonshendelser.
• Kontroller negative lagertall og uventede lageravvik.
• Se etter uvanlig mange avbrutte kjøp eller tekniske checkout-feil.

Definer hvem som eier hvert avvik, hvor raskt det skal vurderes, og hva som kan rettes uten utvikler. Kundeservice bør for eksempel kunne sende ordrebekreftelsen på nytt, men ikke nødvendigvis starte en ukontrollert synkronisering av hele produktregisteret.

Leveransen bør være et operativt ordrekart

Resultatet av planleggingen bør være et ordrekart som både forretningen og utviklerne forstår. Det trenger ikke være komplisert. For hvert trinn beskriver dere ansvarlig system, nødvendige data, statusendring, kundekommunikasjon, mulige feil og rutinen ved avvik.

Bruk kartet når dere vurderer nye betalingsmetoder, fraktavtaler, produktgrupper og integrasjoner. Spør ikke bare om funksjonen kan installeres. Undersøk hvordan den påvirker lager, betaling, ordrestatus, retur, ytelse og daglig drift.

Da blir WooCommerce en styrbar del av virksomheten i stedet for en samling funksjoner som tilfeldigvis møtes i checkout.