Guide för kravställning av WordPress & WooCommerce-projekt

Att upphandla ett WooCommerce-projekt kan vara komplicerat. Hur bör en kravställning se ut och hur gallrar man ut leverantörer?

Inom den egna organisationen finns det mycket kunskap om de affärsvärden man vill få ut av sin E-handel, men sällan expertkunskap kring vad för processer man skall förvänta sig av sin leverantör.

I denna guide kommer vi att gå igenom hur man bör tänka när man skriver en kravställning för att ett WordPress- eller WooCommerce-projekt skall bli lyckat och för att man skall välja rätt typ av leverantör.

Innan vi börjar så är det viktigt att säga att denna guide framförallt är till för projekt vars utfall ämnas att användas dagligen i ett par år. Detta innebär att utöver att genomföra projektet behöver det driftas, förvaltas och vidareutvecklas på ett professionellt sätt under hela sin livscykel. Om tanken är att genomföra ett projekt som sedan kasseras inom 3-6 månader är denna guide inte tillämplig. Vidare är guiden riktad mot e-handlare som faktiskt säljer saker och där det är viktigt att lösningen alltid fungerar. Om ni känner att det inte gör något att utcheckningen på sidan ligger nere i ett par dagar är denna guide inte tillämplig.

En kravställnings disposition

En kravställning kan se lite olika ut, men som regel så bör dessa olika ingredienser finnas med:

  • Bakgrund
    • Om produkten / tjänsten
    • Om organisationen
  • Affärsmål
  • User stories
  • Leveransvillkor
    • Kalendertid
    • Krav på arbetsmetod
    • Anvisning runt dokumentation och rapporter
    • GDPR och andra lagkrav
  • Förvaltning
    • Förväntad trafikprofil (antal besökare / månad)
    • Krav drift
    • Krav på tekniskt underhåll
    • Krav på vidareutveckling
  • Bilaga: Dokumentation av tredjepartssystem (om applicerbart)

Vill man kan man även skriva förslag på olika personas och olika use cases, men ovanstående disposition och innehåll bör fungera för de flesta projekt.

White paper: Matris för bedömning av leverantörer i WordPress & WooCommerce-projekt

Spara mängder av tid genom att använda denna matris vid utvärdering av leverantörer och anbud. Fyll i formuläret så levereras en länk direkt till din e-post.




Jag godkänner hantering av personuppgifter

Krav utgår alltid från affärsmål

I alla projekt finns det alltid en grundtes kring vad för affärsvärde man förväntar sig att få ut av projektet man vill driva. Projektet bör alltid ha sin utgångspunkt i dessa mål för att sedan brytas ner i mer specifika kravställningar.

Riktlinjer kring affärsmål som skall uppnås ställs normalt av företagets ledning och kan se ut ungefär såhär:

  • Vi skall öka mängden leads
  • Vi skall omsätta mer per person
  • Vi skall öka mängden arbetsansökningar

Dessa affärsmål bryts sedan ner till funktionella och icke-funktionella krav. I moderna projekt använder man sig ofta av User stories, som är ett enkelt sätt att definiera krav så att både beställare och leverantör förstår och är överens.

Vad är User stories?

En user story är en kortfattad specifikation av ett funktionellt eller icke-funktionellt krav. En specifikation för en E-handel kan till exempel nämna att man har en varukorg. Detta kallas en Epic. En epic bryts sedan ner till flera mindre User stories som i sin tur har Acceptanstester. En User story uttrycks oftast enligt formen “Som <roll> vill jag <mål/önskan/händelse> för att <syfte>”

Exempel på en User story:

Som besökare vill jag få en visuell notifikation som visar hur många produkter jag har i min varukorg när jag lägger till en produkt i min varukorg. Denna funktion är viktig eftersom den gör det tydligt för besökaren hur många produkter som finns i varukorgen.

Acceptanskriterier

  • När jag klickar på “köp” på en produkt för första gången visas en siffra vid “Varukorgen” i menyn.
  • Om jag tar bort alla produkter ur varukorgen försvinner siffran i menyn
  • Om jag lägger till eller tar bort produkter i varukorgen ökar och minskar räknaren för att reflektera hur många produkter varukorgen innehåller

Även icke-funktionella krav fungerar att uttrycka som User stories. Till exempel;

  • Som besökare vill jag att webbplatsen är tillgänglig 99,9% av gångerna jag försöker använda den, så att jag inte blir frustrerad och hittar en annan webbplats för mitt köp.
  • Som besökare vill jag kunna använda webbplatsen med en tal-till-text emulator.

För vidare läsning kan vi rekommendera User Stories Applied av Mike Cohn.

Vem skall vara intern kravställare?

Långsiktigt skall verksamheten äga utfallet från projektet och förhoppningsvis använda det i sin dagliga verksamhet. Det innebär att kvaliteten på kraven enbart kan säkras av de som vet hur systemet ska användas.

Projektet mår därför bäst av att kravställas och testas av olika enheter inom organisationen. En IT-organisation är till exempel experter på krav utifrån teknik och system, medan i ett E-handels projekt så kan sälj- och logistikavdelningarna vara experter på den funktionalitet man vill ha. Att använda sig av flera avdelningar minimerar en risk för hemmablinda beslut jämfört med om hela kravställningen kommer från en och samma enhet.

För att kravställningsprocessen lyckas behövs 5 saker;

  1. Se över rollerna, ansvar och mandat.
  2. Skapa en kravstrategi som beskriver hur kravhanteringsarbetet ska gå till.
  3. Facilitera workshopar med olika intressenter för att landa prioriteringar.
  4. Etablera en modell för hur kravarbete och prioritering skall ske.
  5. Etablera plan för hur projektet redovisas i er organisationsstruktur och kultur.

Ställ krav på projektets arbetsprocesser

Det finns många olika sätt att driva projekt. Det kan kännas skönt för er som inköpare att ett projekt har ett fast pris, men detta arbetssätt blir sällan det som producerar det bästa resultatet. Ni bör istället leta efter en leverantör som är van vid målstyrning och som jobbar med så kallade agila arbetsmetoder.

Iterativ arbetsprocess

I en agil arbetsmetod arbetar man efter att uppnå affärsmålen snarare än att leverera exakt på den kravspecifikationen som ni kom överens om i början av projektet. Den kunskap som alla parter införskaffar under projektets lopp är oerhört värdefull och bör tas tillvara på bästa sätt. Att genomföra projektet enligt agila principer är därför det som tillför mest nytta till er organisation.

Samtidigt skall det sägas att det också kräver att ni avsätter tid för att vara engagerade i projektet. Om ni inte engagerar er i projektet blir projektet inte bättre än den ursprungliga kravspecifikationen som ni kom med. Läs mer om hur agila WordPress projekt fungerar.

Ställ krav på moderna utvecklingsmetoder

Skall ni få en bra leverans är moderna utvecklingsmetoder oerhört viktiga och det bör ställas krav på vilka interna processer leverantören har. Detta kan vara avgörande för projektets långsiktiga framgång och kan skydda er som kund från många dyra problem.

Versionshantering

Alla moderna leverantörer med självaktning använder sig av versionshantering. Detta innebär att varje förändring kan följas och skapar möjligheter för många att arbeta på samma projekt samtidigt utan att förstöra för varandra. Idag används normalt GIT, men SVN är också ett system som används i stor utsträckning i WordPress-världen.

Lokala utvecklingsmiljöer

När man utvecklar så vill man gärna följa en strikt process där den enskilda utvecklaren arbetar på sin egen dator i en kopia av den “riktiga” miljön som man skall använda sen. Detta gör att flera utvecklare kan samarbeta samtidigt. Om man inte använder sig av lokala utvecklingsmiljöer så kan det vara problematiskt för flera att arbeta samtidigt, vilket sänker farten och höjer risken i projektet rejält.

Det är också viktigt att ställa frågor kring hur detta hanteras. Hur lång är uppsättningstiden per person? Vissa leverantörer kan ha 4-8 timmars uppsättningstid för en utvecklingsmiljö medan andra kan ha 30 minuter. Även om det kan verka obetydligt i projektarbetet kan det ge oerhörda kostnader längre fram.

VPN och acceptansmiljöer

Efter att utvecklarna arbetat i sina lokala miljöer måste det de har gjorts visas upp för er som kund och godkännas. Detta görs ofta i separata miljöer och med en databas som så mycket som möjligt liknar så som det kommer se ut när det är “färdigt”. Dessa kan benämnas som “testmiljöer”, “utvecklingsmiljöer” eller “stagingmiljöer” eller liknande, men oftast har de ungefär samma funktion.

Dessa miljöer får under inga som helst omständigheter ligga ute publikt mot Internet, oavsett om innehållet på webbplatsen är hemligt eller ej. Om de ligger ute offentligt så kan de dels bli utsatta för attacker under utvecklingsarbetet, men de kan också bli indexerade av sökmotorer – vilket kan vara en katastrof för er digitala marknadsföring. Av dessa anledningar så rekommenderar vi att dessa endast är åtkomliga via VPN.

Byggjobb och komponenthantering

När man arbetar flera så är det viktigt att ha en process som separerar standardiserade processåtgärder – byggjobb – från den enskilda individens dator. Dessa åtgärder behöver göras som en del av den övergripande infrastrukturen, annars kommer det vara mycket svårt för flera personer att samarbeta. Dessa byggjobb kan sedan användas för att till exempel optimera och analysera kod löpande för att på så sätt skapa hög kvalitet i det löpande arbetet.

I dessa byggjobb är komponenthantering ofta en viktig princip. Detta görs normalt med en mjukvara som heter Composer och är ett strukturerat och modernt sätt för att säkra att alla komponenter som används i projektet hämtas från rätt källa och är signerade.

Utöver detta kan byggjobben utgöras av en mängd andra processåtgärder såsom implementation av SASS eller prestandaförbättringar som webpack. Så länge det finns en process och en befintlig standard som är dokumenterad och/eller versionshanterad så kan man vara ganska säker på att detta blir rätt.

Deployverktyg

När kod skall driftsättas så är det fördelaktigt om den driftsätts på ett kontrollerat och automatiserat sätt. Detta är speciellt viktigt om man har hög last och behöver driftsätta kod till många parallella miljöer samtidigt. Genom att ha en automatiserad process så minskar även risken för fel.

Verktyg som man vill skall finnas här är primärt Capistrano som är störst, men det finns även många andra tekniker såsom Deployer, Rocketeer, Ansible mfl.

Automatiserade tester

När förändringar görs i ett komplext projekt kan en ändring på ett ställe få konsekvenser på fem andra. För att säkra att detta inte händer så är det viktigt att det finns automatiserade tester som säkerställer att det helt enkelt inte går att driftsätta saker som gör att viktiga funktioner inte fungerar.

Visuella jämförelsetester

En liten ändring kan orsaka småfel både här och där. Det kan vara väldigt svårt – om inte omöjligt – för en människa att upptäcka om dessa detaljer blivit fel någonstans. Därför använder man sig av visuella jämförelsetester. Vad man praktiskt gör är att på ett automatiserat sätt så tar man skärmdumpar av webbplatsen i en mängd olika skärmstorlekar före och efter förändringen – och sedan räknar man ut skillnaden. Denna skillnad presenteras sedan i en rapport till utvecklaren och denne kan ta beslut om förändringarna är de avsedda eller om de var oavsiktliga.

På detta sätt hindrar man att väldigt många fel upptäcks i god tid innan de når ut till besökarna – era slutkunder – och orsakar inkomstbortfall och prestigeförlust.

GDPR

GDPR (General Data Protection Regulation) är EUs nya datalagstiftning som reglerar hur personuppgifter får lagras. Personuppgifter är ett relativt vitt begrepp och omfattar egentligen det mesta som går att spåra tillbaka till en person – inklusive e-postadresser.

Det är inte bara viktigt att leverantören känner till hur lagstiftningen fungerar, utan också av högsta vikt att leverantören hanterar personuppgifter korrekt. Det är till exempel ej tillåtet att kopiera data från produktionsmiljön till en testmiljö utan att däremellan anonymisera användardatan. Detta kräver en automatiserad process för detta såväl i projektet som under den löpande förvaltningen. Att arbeta med en webbyrå som ej har en process för detta kommer utsätta ert företag för risk.

Ställ krav på leveransvillkor

En av de viktigaste ställningstagandena handlar om när leverans kan ske. Här är det viktigt att tänka på att man som kund också måste ha en hel del bandbredd själv för att kunna få en snabb leverans. Det kommer att vara omöjligt för er att lägga en exakt tidsplan så pass tidigt i projektet, men en ungefärlig riktlinje baserat på era affärsbehov är såklart nödvändig.

Betalningsvillkor

Beroende på er och leverantörens likviditet kan det vara viktigt med lite längre perioder på varje faktura. 30, 60 eller 90 dagar? Det bör framgå tidigt så att det inte blir ett problem längre fram.

Rapporteringskrav

Har ni en intern beställare som har tillåtelse att ta beslut om nya funktioner och inte bara att prioritera inom projektet? Då är det viktigt att det finns krav vad gäller rapporter. Det är viktigt att kunna följa via mötesprotokoll när tillägg görs och vad som prioriteras i projektet.

Ställ krav på vidareutveckling och drift

När projektet väl är genomfört kommer det att hamna i en sorts vidareutvecklings/förvaltningsfas. Nu börjar ni arbeta aktivt med verktyget och det är här det tillför mest värde till organisation och som ni ser frukten av er investering.

I denna fas är det viktigt att ständigt iterera och utvärdera för att se till att så mycket värde som möjligt tillförs till organisationen. Här krävs det oftast en mångfacetterad kunskap. Med hjälp av dataanalys, statistikverktyg och användartester (tillsammans med att lyssna på sina kunder och prospekt) så kan man få fram information om det är någonting som behöver förtydligas och/eller förändras.

Denna process är viktig och hjälper er att höja ROI och sänker er kostnad för att uppnå era utsatta mål. Därför är det viktigt att även ha med i er kravställning på projektet och leverantören.

Drift och teknisk förvaltning

När projektarbetet väl är slutfört så kommer detta driftas. Problemet med drift är att många gånger så har driftsbolaget ganska så dålig koll på hur applikationen skall driftas och är totalt avskärmade från processen runt att utveckla applikationen.

Moderna utvecklingsmetoder kräver en strömlinjeformad arbetsprocess och detta innebär att denna separation mellan de som utvecklar applikationen och de som driftar den kan vara farlig. Det krävs ett mycket gott samarbete för att applikationen skall kunna skala på ett bra sätt och tillföra det tilltänka värdet till organisationen.

SLA och viten

Den viktigaste frågan man kan ställa sig när man kravställer drift är vilka SLA nivåer som gäller och vilken responstid man kan förvänta sig när någonting går fel. Viten är också viktigt att ställa krav på. Ett SLA utan viteskrav är ett värdelöst SLA. Ett rimligt SLA är ett grundläggande krav och är precis lika viktigt som hur lösningen är utformad. Kan inte leverantören lämna ett vettigt SLA är det lika bra att välja bort leverantören.

Lastbalansering

Om lösningen skall skala eller klara av besökare i någon större utsträckning måste det finnas lastbalanserare i driftslösningen. Detta innebär att last balanseras ut mellan flera olika servrar så att lösningen inte går under när det blir stora trafikmängder.

Cache och prestandaoptimering

För att applikationen skall vara snabb och klara av mycket trafik så behövs cache och löpande prestandaoptimering. Normalt är det väldigt svårt för någon som inte varit särskilt insatt i projektet att enkelt optimera prestandan. Har man riktig otur så har inte detta perspektiv funnits med över huvud taget innan man skall drifta projektet, och det kan bli väldigt problematiskt.

Loggövervakning

När besökare går in på webbplatsen så genererar webbplatsen loggar. Allteftersom till exempel PHP uppdateras eller nya versioner av WordPress & WooCommerce läggs till så kan det uppstå mindre problem. Det kan också finnas inbyggda flaskhalsar som varit svåra att upptäcka under det löpande utvecklingsarbetet som gör att webbplatsen blir oerhört långsam eller helt enkelt slutar fungera under vissa specifika förutsättningar. Detta kan leda till en tappad affär för den som har webbplatsen, så det bör tas på största allvar.

På tusen användningar av webbplatsen kanske detta bara händer en enda gång, vilket gör att de döljer sig i ett berg av data. Med hjälp av loggövervakning går det att på ett smidigt sätt att följa upp mönster och avvikelser i den enorma mängd av data för att kunna göra någonting åt saken.

Säkerhetsscanning

När det kommer kritiska säkerhetsuppdateringar måste dessa läggas in snabbt. Därför är det viktigt att det finns en automatiserad lösning på plats för att kontrollera och varna om det finns säkerhetsbrister i de komponenter som används på webbplatsen. En bra kontroll använder sig oftast av WPScan Vulnerability Database.

Teknisk förvaltning

Med öppen källkod använder man sig av öppna komponenter. Detta är en oerhörd styrka som gör att man får mycket mer för pengarna jämfört med att välja proprietära system. Detta gör att det ofta kommer säkerhetsuppdateringar och funktionsuppdateringar som är kostnadsfria. Dessa uppdateringar måste dock installeras och kontrolleras noggrant innan de läggs till för att säkra webbplatsens eller E-handelns funktion.

Hur avgränsar man valet av möjliga leverantörer?

Att hitta potentiella leverantörer att vara med i upphandlingen kan vara utmanande. I de allra flesta fall arbetar man med en byrå, men om man har en tillräckligt stor organisation så kan det hända att man arbetar med ett internt team av utvecklare och behöver förstärkning av en expertresurs som guidar det interna teamet rätt.

Det finns fler aspekter till att leta en bra leverantör än att bara googla “webbyrå stockholm”. När ni gör urvalet så var mer specifik. Är det en E-handel ni skall göra? Googla “WooCommerce webbyrå”. Är det en marknadsföringswebbplats? Googla “WordPress webbyrå”. Dessa tillsammans med de rekommenderade leverantörerna i WooExperts kan vara en bra utgångspunkt för er upphandling.

Geografi, lagutrymme och språk

Idag så har Internet och digitaliseringen skapat en vardag där det är möjligt att samarbeta över långa distanser. Detta har skapat möjligheter som tidigare inte var möjliga, men i slutändan finns det saker som fortfarande är värt att betänka.

Går det ett träffa leverantören för fysiska möten?

Även om samarbeten idag fungerar väl över stora fysiska avstånd och fysiska möten inte behövs i lika stor utsträckning är det fortfarande värdefullt att kunna ses.

Om leverantören har ett större avstånd än 20 mil till närmaste kontor så kan fysiska möten vara omständigt att få till. Detta är absolut värt att ta i beaktning.

Vilket lagutrymme gäller om någonting går riktigt fel?

Om en leverantör befinner sig utomlands så agerar denna leverantör inte under samma lagutrymme som Svenska företag. Detta kan till exempel påverka hur personuppgifter och känslig data hanteras på företaget. Inom Europa måste alla företag från den 25:e Maj 2018 följa EUs regler kring dataskydd, GDPR (General Data Protection Regulation). Detta innebär att välja en leverantör utanför EU som inte har full koll på lagstiftningen kan kosta ert företag oerhörda summor i vitesbelopp.

Rent praktiskt innebär GDPR många olika saker, men som exempel så måste leverantören anonymisera orderdata när man hanterar det till de olika test- och acceptansmiljöerna på ett automatiserat sätt.

Vilket språk kommunicerar leverantören på?

Det som oftast går fel i ett projekt, oavsett hur bra kravställningen är skriven, är alltid kommunikation. Därför är det viktigt att så långt det är möjligt försöka förebygga möjliga problem i kommunikationen. Detta är enklast att göra genom att ställa krav på vad för språk leverantören kommunicerar med.

Har leverantören rätt tjänsteutbud och storlek?

En viktig aspekt när man väljer leverantör är om leverantörens tjänsteutbud helt enkelt är kompatibelt med vad man vill göra och om leverantören klarar av att leverera i hela livscykeln. Detta hör normalt ihop med företagets storlek då väldigt små leverantörer och enskilda frilansare inte har möjlighet att lägga den tid och energi på process- och kompetensutveckling som ett större företag har möjlighet att göra.

Har byrån en mångfacetterad kunskap?

Olika byråer är specialiserade på olika saker. För att genomföra riktigt bra projekt är det bra om byrån har många olika kompetenser som bidrar till kompetensen överlag i företaget. Även om det kanske är så att systemadministratören eller AdWords-experten kanske inte kommer genomföra särskilt mycket i just ert projekt så är det ändå värdefullt för framtiden att denna kompetens finns hos leverantören. Kunskap har en tendens att sprida sig när man klustrar ihop den och detta kommer att bidra till att den rådgivning och de beslut som tas gynnar projektets framgång.

Gör byrån allt mellan himmel och jord?

Har byrån en tydlig inriktning, eller gör de precis allt mellan himmel och jord? Det är inte ovanligt att se leverantörer som jobbar både med EpiServer, WooCommerce, Magento och Umbraco. Det kan finnas en fara i att välja en leverantör med ett för spretigt teknikerbjudande då risken är stor att det finns begränsad plattformskompetens.

Verkar byrån ha rätt storlek?

För företag som behöver vara lättfotade och kunna agera snabbt på omvärldens förändringar är det viktigt med bandbredd. Driver man en mindre verksamhet så är det ofta naturligt att leta efter en annan mindre verksamhet. Mindre verksamheter är ofta väldigt lyhörda och lätta att jobba med och det går ofta att förhandla fram ett bra pris då det saknas stor overhead i organisationen. Nackdelen här blir ofta att man har sällan en väl utvecklad arbetsprocess för hela livscykeln – man är bra på några få saker och inte särskilt bra på många andra.

Har leverantören rätt erfarenhet?

Erfarenhet kan yttra sig på ett par olika sätt. Det kan vara allt ifrån hur många år i branschen man har till vilka typer av kunder man är van att arbeta med.

Estimat och spikes

Många av kraven kan ta avsevärd tid att undersöka och dessa kan därför inte alltid estimeras av leverantören. Att leverantören inte vet behöver inte vara ett uttryck för att de inte har erfarenhet och kompetens utan kan istället vara för att de vill göra rätt lösning snarare än att hitta på en siffra tagen ur luften. Att göra mindre undersökningar, så kallade “spikes” är ett vanligt förekommande arbetssätt. Efter att ett urval gjorts så att ni har 1-2 leverantörer kvar så var inte rädd för att ge dem tid att göra en betald undersökning – det kan löna sig.

Leta efter liknande arbeten i portfolion

Det första som man kan titta på när man undersöker leverantörens erfarenhet är att se om det finns liknande projekt bland företagets tidigare genomförda arbeten. WordPress och WooCommerce är oerhört flexibla och modulära mjukvaror och de kan användas för en mängd olika applikationer. Om ni letar efter en byrå som till exempel specialiserat sig på WooCommerce E-handel så är det en aspekt ni letar efter, om ni letar efter en webbyrå som fokuserar på att WordPress LMS implementationer är detta någonting ni får leta efter.

Om Certifieringar, partnerskap och rykte

WordPress och WooCommerce är byggda på öppen källkod. Detta innebär att bara för att en leverantör själva hävdar att de är experter så behöver det inte vara sant. Varje gång någon nämner att man är expert så bör man ta detta med en nypa salt och undersöka om det faktiskt stämmer.

Certifieringar och partnerskap

I praktiken existerar inte certifieringar inom WordPress och WooCommerce. Vad som däremot finns är WooExperts, som är partnerprogrammet för WooCommerce-experter. Det går inte att komma in i detta programmet utan att bli godkänd av Automattic, som är företaget som driver WooCommerce och WordPress. Detta partnerprogram är det enda som liknar en certifiering som går att komma i vår bransch och bör tas på största allvar. Det är helt enkelt tryggare att välja en leverantör som man vet har blivit godkända av Automattic.

Antal Open Source projekt

Ett annat kvalitetsmärke man bör titta på är hur många öppen-källkod projekt som leverantören har varit delaktig i. Det man först och främst skall titta efter när man upphandlar ett WordPress eller WooCommerce projekt är om företaget bidragit med förbättringar till antingen WordPress eller WooCommerce-kärnan. Har man gjort detta innebär det ofta att man har en mycket djup kunskap om mjukvaran.

Nästa sak man bör undersöka är hur många Plugins och teman som leverantören har tillgängliggjort. Detta kontrolleras enklast genom att leta efter en wordpress.org-profil eller ett företags-github konto. Fördelen med att undersöka wordpress.org-profilen är att där går det att se en uppskattning på hur många användare ett specifikt plugin har. Normalt så kan man säga att om leverantören har ett eller flera plugins med många användare så är de vana vid att göra vältestade lösningar som samtidigt tillför mycket värde för dess användare. Detta är egenskaper som ni antagligen önskar att dra nytta av.

Sist i ordningen är att undersöka hur många projekt man engagerat sig i utanför WordPress och WooCommerce-sfären. Kanske finns det något intressant projekt som utnyttjar spännande teknik eller är banbrytande? Att det är publicerat innebär att leverantören inte är rädd för att bli granskad i sömmarna av andra ens på sina sidoprojekt.

Deltagande i branschträffar

Inom WordPress och WooCommerce finns det officiella branschträffar. Dessa kallas WordCamps och WooConfs. Dessa är sanktionerade av WordPress foundation och följer strikta krav och riktlinjer för att få använda detta varumärket. Som sådant brukar dessa ha kommittéer som avgör vilka som får hålla föreläsningar baserat på dess uppfattade värde för publiken. Att ha föreläst eller anordnat en sådan branschträff är starkt meriterande.

Slutsats

Att välja rätt leverantör kan vara oerhört svårt. Vi hoppas att denna guide hjälper er i upphandlingsdjungeln och att ni hittar en leverantör som hjälper er att ta er WordPress E-handel till skyarna.

Lycka till med er E-handel!