Kort svar: Et internt dashboard samler de 8-10 tal, forretningen styres efter – omsætning mod mål, ordrer og kurv, annonceafkast, konvertering, retur og drift – på ÉT sted, alle kan se. Den pragmatiske arkitektur: et regneark eller Looker Studio som nav, hvor data skubbes ind automatisk (ordrer via API/webhook, annoncer og trafik via connectors, regnskabstal månedligt) – ingen kode, ingen BI-licenser. Reglerne, der afgør succesen: højst ti tal, hvert tal med en ejer, og én månedlig afstemning mod kilderne – et dashboard, ingen stoler på, er værre end ingenting.
Virkeligheden i mange webshops: omsætningen bor i WooCommerce, annoncetallene i to annoncekonti, trafikken i analytics, økonomien i regnskabet – og det samlede billede bor ingen steder. Så styres der på mavefornemmelse og den seneste fane, nogen havde åben. Hvor mandagsrapporten er ugens puls-tjek, er dashboardet det fælles styringsbillede: altid opdateret, altid samme tal for alle. Her er den realistiske vej til at bygge det – uden BI-afdeling.
Dashboards dør af overvægt: fyrre grafer, ingen kigger på, fordi intet skiller sig ud. Vælg i stedet efter én test: „hvis dette tal ændrer sig markant, GØR vi så noget?“ Tre grupper dækker de fleste: Forretningen – omsætning måned-til-dato mod mål (målet PÅ dashboardet – tal uden sammenligning er bare tapet), antal ordrer, gennemsnitskurv. Marketing – annonceudgift og afkast (ROAS eller omkostning pr. ordre), besøg og konverteringsrate. Driften – returprocent, gennemsnitlig leveringstid og oppetid/fejl (fra jeres overvågning). Læg dertil ét-to tal, der er SÆRLIGE for jer (B2B-andel, abonnenter, NPS). Skriv for hvert tal: definitionen (hvad tæller med?), kilden og EJEREN – den person, der skal kunne forklare bevægelsen på ugemødet. Uden ejere er et dashboard bare vejr-tv.
Mønstret er det samme som i lagersynkroniseringen: ét nav, alle kilder leverer til, i stedet for et spindelvæv. For små og mellemstore shops er navet i praksis et regneark eller Looker Studio (gratis): trafik- og annoncedata kommer via færdige connectors, mens shoppens egne tal skubbes ind automatisk – et lille dagligt flow henter ordretal via API’et og skriver én række pr. dag i arket (dato, omsætning, ordrer, kurv …). Regnskabstal (dækningsgrad, faste omkostninger) opdateres månedligt fra regnskabssystemet – gerne manuelt; de ændrer sig langsomt, og én række om måneden er ikke automatiserings-værdig. Først når kilder, historik og behov vokser ud af arket, giver rigtige BI-værktøjer mening – og til den tid flytter du bare navet, ikke idéen.
En realistisk byggeplan på en dag: 1) Opret arket med én fane pr. kilde (shop-dagstal, annoncer, mål/økonomi) og én samlefane med månedens billede. 2) Byg dags-flowet (n8n/Make: hent i gårs ordrer, skriv rækken – samme teknik som mandagsrapporten, bare til et ark i stedet for en mail). 3) Tilslut annonce- og trafik-connectors i Looker Studio, og peg den også på arket. 4) Design ÉN side: de ti tal øverst med retning og mål, tre-fire grafer under (omsætning over tid mod sidste år, ROAS, konvertering) – og modstå fanen „side 2“ så længe som muligt. 5) Sæt fejlovervågning på dags-flowet (dead man’s switch – et dashboard med huller i data mister troværdigheden først). Del linket med hele teamet, og hæng det evt. på en skærm – synlige tal opdrager stille alle beslutninger.
Et dashboard ændrer først noget, når det får et fast MØDE at bo i: fem minutter på ugemødet, hvor hvert tals ejer siger én sætning – „kurven falder, fordi kampagnen trækker småordrer; vi hæver fri fragt-grænsen“. Det tvinger definitionerne på plads og gør tallene til handlinger. To adfærdsregler mere: når et tal ser MÆRKELIGT ud, er første hypotese altid datafejl (tjek kilden, før du reagerer på tallet) – og når et tal aldrig flytter beslutninger i tre måneder, ryger det af og gør plads. Dashboardet er et værktøj, ikke et trofæ: målet er ikke at SE professionel ud, men at opdage skævheder uger tidligere, end mavefornemmelsen ville – og de shops, der lykkes, taler påfaldende ofte om tallene i datid: „vi KUNNE se det komme“.
Dashboardets valuta er tillid, og tillid tæres af små afvigelser: refusioner, der tæller forskelligt i shop og regnskab, moms med/uden, tidszoner der forskyder døgnet. Derfor: afstem én gang om måneden mod kilderne (dashboardets månedsomsætning mod WooCommerce-analytics OG mod bogføringen – små definitionsforskelle er okay, NÅR de er kendte og noterede), og skriv definitionerne på selve dashboardet („omsætning = gennemførte ordrer inkl. moms, ekskl. fragt“), så diskussionen aldrig starter forfra. Én sidste ting: dashboards, der henter fra shoppens API hver dag, skal gøre det skånsomt (én natlig kørsel, få felter) – så belaster de intet på en ordentlig WooCommerce-hosting, og butikken mærker aldrig, at den bliver målt.
Start med Looker Studio + et regneark som nav: gratis, connectors til trafik og annoncer, og shop-tal skubbes ind med et lille dagligt flow. Skift først til BI-værktøjer, når behovet beviser det.
Højst ti – hvert med definition, kilde og ejer. Testen: ændrer tallet sig markant, skal det udløse handling. Tal, der aldrig flytter beslutninger, ryger af.
Rapporten er PUSH i fast rytme (mandagsmailens fem tal); dashboardet er det altid-opdaterede fælles opslagssted med flere dimensioner. De styrker hinanden – rapporten skaber vanen, dashboardet dybden.
