Lag en datakontrakt før WooCommerce-butikken vokser

Kategori: WooCommerce

En profesjonell nettbutikk får sjelden problemer fordi den mangler funksjoner. Problemene oppstår oftere når ingen har bestemt hvilket system som eier produktnavn, priser, lagerstatus, kundedata og ordrestatus. Da blir feil rettet manuelt, integrasjoner overskriver hverandre, og små endringer i checkout får uventede følger andre steder.

Før dere bygger videre, bør dere derfor lage en datakontrakt for nettbutikken. Det er en konkret beskrivelse av hvilke data som finnes, hvor de opprettes, hvilket system som får endre dem, og hva som skal skje når noe går galt. Dokumentet trenger ikke være omfattende. Det må være presist nok til at ledelse, butikkansvarlig, utvikler og integrasjonspartner tar de samme beslutningene.

Start med spørsmålene som skaper driftsproblemer

En datakontrakt bør ikke begynne med tekniske feltnavn. Begynn med situasjonene organisasjonen faktisk møter:

• Hvor skal en pris endres, og hvor raskt skal den være synlig i nettbutikken?
• Kan en ordre fullføres dersom lagerintegrasjonen ikke svarer?
• Hva skjer når betalingen er godkjent, men ordren ikke når økonomi- eller lagersystemet?
• Hvilket system avgjør at en ordre er sendt?
• Kan kundeservice endre leveringsadresse etter at ordren er overført?
• Hvordan oppdages produkter som mangler vekt, varenummer eller avgiftsinformasjon?

Svarene gir grunnlaget for både produktstruktur, checkout, integrasjoner og daglig drift. De synliggjør også beslutninger som ellers først blir tatt når en ordre allerede har stoppet.

Bestem hvilket system som eier hvert produktfelt

Produktdata kan komme fra WooCommerce, et produktsystem, et økonomisystem, en leverandørfil eller flere av disse samtidig. Det avgjørende er ikke hvor mange systemer dere har, men om hvert felt har én tydelig eier.

For hvert sentralt produktfelt bør kontrakten beskrive:

• hvilket system som oppretter verdien
• hvilket system som kan endre den
• hvor ofte verdien synkroniseres
• hva som skjer dersom verdien mangler eller er ugyldig
• om manuelle endringer i WooCommerce skal tillates

Ta for eksempel salgspris. Hvis økonomisystemet eier prisen, bør en redaktør normalt ikke kunne gjøre en varig prisendring bare i WooCommerce. Endringen kan bli overskrevet ved neste synkronisering. Resultatet er gjerne en kampanje som avsluttes for tidlig eller en pris som varierer mellom systemene.

Det samme gjelder lagerstatus. Dere må avklare om WooCommerce viser faktisk beholdning, en beregnet tilgjengelighet eller bare status som på lager og utsolgt. Nettbutikken bør ikke love en presisjon som datagrunnlaget ikke kan levere.

Skill mellom produkt, variant og salgbar enhet

Variantprodukter blir raskt kompliserte når farge, størrelse, emballasje eller andre valg påvirker pris, lager, levering og varenummer. En vanlig feil er å bruke varianter til alle typer kundevalg, også når valget egentlig er en tilleggstjeneste eller personlig tilpasning.

Bruk variant når valget representerer en egen salgbar enhet med eget varenummer, lager eller pris. Bruk produktvalg eller tillegg når grunnvaren er den samme, men kunden velger eksempelvis gravering, montering eller gaveinnpakning. Dette skillet gjør integrasjonene enklere og reduserer antallet kombinasjoner WooCommerce må håndtere.

Avtal også hvilke produktegenskaper som skal brukes til filtrering, hvilke som bare vises som informasjon, og hvilke som styrer forretningsregler. Hvis samme felt brukes til alt, blir det vanskelig å endre katalogen uten å påvirke søk, filter og integrasjoner.

Definer checkout som et sett med regler

Checkout er ikke bare et skjema. Den kombinerer kundedata, priser, avgifter, fraktvalg, lagerkontroll, betalingsstatus og samtykker. Derfor bør hvert felt og hvert valg ha en begrunnelse.

Lag en oversikt over hvilke opplysninger som er:

• nødvendige for å ta imot betalingen
• nødvendige for levering og ordrebehandling
• påkrevd for bestemte kundetyper eller markeder
• nyttige, men ikke nødvendige for kjøpet

Fjern eller utsett opplysninger som ikke trengs der og da. Et felt som er nyttig for salg eller kundeservice, er ikke automatisk nødvendig i checkout. Flere felt gir flere valideringsfeil og flere data som må vedlikeholdes og beskyttes.

Datakontrakten bør også angi når priser og lager skal kontrolleres på nytt. En kunde kan ha hatt handlekurven åpen mens pris eller tilgjengelighet ble endret. Det må være tydelig om kontrollen skjer ved visning av handlekurv, ved åpning av checkout eller rett før ordren opprettes.

Planlegg for avbrudd i eksterne tjenester

Checkout er ofte avhengig av betalingsleverandør, adresseoppslag, fraktberegning og lagerdata. Bestem på forhånd hvordan butikken skal oppføre seg hvis én tjeneste ikke svarer.

Det finnes ikke ett riktig svar. For enkelte butikker er det forsvarlig å vise faste fraktalternativer dersom transportørens tjeneste er utilgjengelig. Andre kan ikke ta imot ordren uten en bekreftet fraktpris. Poenget er at valget skal være bevisst, synlig for kunden og testet før situasjonen oppstår.

Beskriv ordrestatus som forretningshendelser

Standard statuser i WooCommerce dekker ikke nødvendigvis den reelle prosessen. En profesjonell ordre kan gå gjennom betalingskontroll, kredittvurdering, plukk, restordre, del-levering, fakturering og retur. Hvis alt presses inn i noen få statuser, mister kundeservice oversikten og integrasjonene får uklare signaler.

Beskriv først hendelsene i vanlig språk:

1. Kunden sender inn bestillingen.
2. Betalingen godkjennes eller reserveres.
3. Ordren overføres til lager eller økonomisystem.
4. Varene plukkes og sendes.
5. Forsendelsen bekreftes med sporingsinformasjon.
6. Betalingen fullføres etter den avtalte regelen.
7. Ordren avsluttes eller går videre til returbehandling.

Deretter kan hendelsene kobles til statuser og tekniske handlinger. Kontrakten bør si hvilket system som får flytte ordren videre, og om endringen kan reverseres. Hvis både lageret og WooCommerce kan markere ordren som sendt, kan kunden få doble meldinger eller betalingen kan behandles på feil tidspunkt.

Ta også med unntakene. Hva skjer med en ordre som er betalt, men avvist av økonomisystemet? Hvem varsles, hvor vises feilen, og hvordan sendes ordren på nytt uten å opprette et duplikat? Dette er viktigere for driften enn enda en funksjon på produktsiden.

Gjør integrasjonene idempotente og sporbare

En integrasjon må tåle at samme melding blir sendt mer enn én gang. Hvis en ordreoverføring prøves på nytt etter et tidsavbrudd, skal den opprinnelige ordren oppdateres eller bekreftes, ikke opprettes på nytt. Denne egenskapen bør være et uttrykkelig krav.

Hver overføring bør kunne spores med et felles kjennetegn, som ordrenummer eller en egen integrasjons-ID. Driftsansvarlig må kunne finne ut:

• hva som ble sendt
• når det ble sendt
• hvilket system som mottok dataene
• om behandlingen lyktes
• hva neste forsøk skal gjøre

Loggen bør gi nok informasjon til feilsøking uten å eksponere betalingsopplysninger eller flere persondata enn nødvendig. Avklar også hvor lenge relevante logger beholdes, og hvem som har tilgang.

Bruk datakontrakten til å beskytte ytelsen

Produktstruktur og integrasjoner påvirker ytelsen direkte. Store variantsett, hyppige lagersynkroniseringer, mange dynamiske prisregler og tunge oppslag i checkout kan gjøre butikken treg selv om serverkapasiteten virker tilstrekkelig.

Datakontrakten hjelper dere med å begrense arbeidet WooCommerce må gjøre. Hvis priser bare endres noen ganger per døgn, trenger de kanskje ikke hentes eksternt for hver sidevisning. Hvis lagerstatus må være ferskere, kan oppdateringer behandles i kø fremfor å gjøre produktvisningen avhengig av et direkte oppslag.

Skill mellom data som må være sanntidsoppdatert, data som kan være noen minutter gamle, og data som kan oppdateres samlet. Denne klassifiseringen gir et mer realistisk grunnlag for hurtigbuffer, bakgrunnsjobber og feilhåndtering.

Gjør kontrakten til en del av driften

Dokumentet har liten verdi hvis det bare brukes i prosjektfasen. Gi én rolle ansvar for å holde det oppdatert når produktmodell, betalingsmåte, fraktoppsett eller integrasjoner endres.

Ved hver endring bør dere kontrollere:

• om et nytt eller eksisterende felt får ny eier
• om valideringsregler endres
• om ordrestatus eller automatiske handlinger påvirkes
• om integrasjonen tåler forsinkelse og gjentatte forsøk
• om kundeservice trenger nye rutiner
• om ytelse, logging og overvåking må justeres

Test med representative produkter og ordretyper, ikke bare ett enkelt standardprodukt. Ta med variantvarer, rabatt, frakt, avbrutt betaling, utsolgt vare og feil i en integrasjon. Det er i kombinasjonene svakhetene vanligvis viser seg.

Et konkret leveransekrav før videre utvikling

Be om én samlet oversikt over produktfelter, checkout-data, ordrehendelser og systemeierskap før neste større WooCommerce-endring. Oversikten bør være forståelig uten tilgang til kildekoden. Hvis teamet ikke kan forklare hvor en verdi kommer fra eller hvem som får endre den, har dere funnet en driftsrisiko som bør avklares.

En god datakontrakt gjør ikke nettbutikken mindre fleksibel. Den gjør det tryggere å endre den. Når eierskap, regler og feilforløp er tydelige, kan nye produkter, integrasjoner og salgsprosesser innføres uten at hver endring blir et forsøk i produksjon.