DB Assistenten analyserer Procudans egne historiske salgspriskalkulationer og budgetdata for at give sælgerne et kvalificeret, datadrevet udgangspunkt for prissætning. Systemet erstatter ikke sælgerens vurdering — det supplerer den med indsigt der ellers ville kræve manuel gennemgang af mange systemer. Grundlaget er ... kalkulationer fra 2024–2026 på tværs af ... unikke vare/debitor kombinationer. Systemet anvender outlier-detektion (IQR-metode) til automatisk at identificere og udelukke fejlregistreringer og engangstilfælde fra beregningerne. En volatilitetsalgoritme viser prisspænd baseret på historisk spredning i DG1%. To tværgående metoder sammenligner kundens DB3 med andre kunder — både inden for samme kategori (peers) og på tværs af alle kundekategorier (kategori-landskab). Datagrundlaget opdateres løbende og tæller dynamisk fra de faktiske kalkulationer i systemet. Anbefalinger vises som et DB/DG-interval baseret på de 6 metoders udfald samt historisk prisvolatilitet — ikke kun et enkelt tal. Dette giver sælgeren et tydeligt billede af forhandlingsrummet. Prisassistenten anvender en dedikeret Anthropic API-nøgle til separat omkostningstracking. AI-modellen kan skiftes direkte i appen under Udviklingsindstillinger til sammenligning af modelkvalitet under prototype-fasen.

Procudan opererer med tre DB-niveauer. At forstå forskellen er avgørende for at bruge systemet rigtigt:

Eksempel: En kunde på Island kan have høj DB1 fordi fragtomkostningen er inkluderet i prisen — men lav DB3 når fragten trækkes fra. En lokal kunde der selv henter varen kan have lavere DB1 men højere DB3. DB1 alene siger derfor intet om hvor lønsom kunden reelt er — det gør DB3.

Systemet er opdelt i tre faner efter dette princip:

Tilsvarende findes DG1%, DG2% og DG3%. DG1% bruges til budget og booking men er upålidelig til sammenligning. DG3% er ren indtjeningsgrad og sammenlignelig på tværs af kunder.

Systemet kender Procudans faktiske prissætningshistorik — ikke generiske markedspriser. Hver historisk kalkulation indeholder kostpris, salgspris, dækningsgrad og mængde. Budgetdata for 2026 indgår som en selvstændig reference. Kundekategorier (M, A, B, C) er integreret fra ABCM-systemet.

Systemet identificerer og ekskluderer statistiske outliers fra beregningerne. En kalkulation flagges kun som outlier hvis den både afviger statistisk fra IQR-grænserne OG afviger mere end 50% fra medianværdien. Dette sikrer at reelle salg med usædvanlig høj eller lav DB ikke fejlagtigt ekskluderes — kun åbenlyse fejlregistreringer og ekstreme engangstilfælde filtreres fra.

Seks uafhængige beregningsmetoder giver hver sit bud på salgsprisen. Ingen enkelt metode er facit — tilsammen tegner de et billede af hvad der er sandsynligt, hvad budgettet forventer, hvad markedet beder om, og hvor usikker beregningen er. Metode 1-4 arbejder på DB1-basis (inkl. alle omkostninger, budgetsammenligneligt). Metode 5-6 arbejder på DB3-basis (rent, sammenligneligt på tværs af kunder).

Hver historisk kalkulation har et udfaldsfelt: Vundet, Tabt, Forældet eller Åben. Via togglen 'Anvend status i beregninger' i toolbar kan status aktiveres som et aktivt signal. Når toggle er OFF vises status stadig i historiktabellerne som information — det er kun beregningerne og AI-kaldene der slås fra. Bemærk: data har en vis usikkerhed da Tabt ikke altid afspejler det reelle kommercielle udfald — brug med omtanke.

Status-kolonnen og udfaldsfordelingen vises altid uanset toggle — det er information til sælgeren. Det er kun beregningerne og AI-kaldene der skifter adfærd.

DB3-metoderne (5 og 6) beregnes nu live med 180-dages vindue og respekterer status-toggle: når status er aktiv ekskluderes Tabt og Forældet helt fra beregningen.

Tre AI-kald afvikles sekventielt ved hver beregning. Dataanalytikeren kører først og identificerer mønstre og trends i det historiske data. Derefter analyserer tværanalytikeren, hvordan kundens DB3 forholder sig til andre kunder på samme vare på tværs af kundekategorier. Begge analytikers observationer sendes som kontekst til prisstrategen, der laver den endelige anbefaling. Kald 1 og 2 afvikles automatisk ved beregning — Kald 3 startes af sælgeren.

Herunder kan du læse de præcise instruktioner AI'en modtager ved hver beregning.

Indlæser...

Indlæser...

Indlæser...

• PLANLAGTData fra SharePoint-liste eller database — erstatter hardkodet JS-fil
• PLANLAGTStjerne-feedback gemmes og matches mod faktisk salgspris i BC365
• PLANLAGTVolumendata fra BC365 integreres i vægtning og kategori-algoritme
• PLANLAGTKundesegment-analyse — DG-mønstre på tværs af segmenter
• PLANLAGTVolumen-håndtering — Ordrestyørrelse og aftalt volumen skal indgå som aktiv parameter i vægtning og algoritmer — ikke blot som kontekst.
• PLANLAGTKalkulations-succesrate fra ordredata — Kobling til ordretabellen i BC365 for at afgøre om en tidligere kalkulation resulterede i en ordre eller blev afvist af kunden. Giver AI-modellen et stærkere signal om hvilke priser der faktisk virker i markedet. Kræver dataudtræk fra BC365 — enten som demo-data eller via direkte integration.
• PLANLAGTDeep-link integration fra BC365 — DB Assistenten kan åbnes direkte fra salgspriskalkulationsbilledet i BC365 via en URL med parametre. ERP-leverandøren sender varenr., debitornr. og kostpris som URL-parametre og felterne udfyldes automatisk ved sideload. Format: /prisassistent.html?varenr=X&debitornr=Y&kostpris=Z
• PLANLAGTFiltrering og søgning i historiktabeller — Predefinerede filtre og fritekst-søgning i begge historiktabeller så brugeren hurtigt kan isolere relevante data. Inspireret af søgefunktionen i director.html. Filtrering påvirker kun visningen — AI-kaldene bruger altid de rå ufiltrerede data.
• PLANLAGTIn-app hjælp via hover-ikoner — Små ℹ️-ikoner ved nøgleelementer der viser kontekstuel hjælp ved hover. Relevant når flere brugere onboardes. Lav prioritet i prototype-fasen.
• PLANLAGTStjerne-feedback med datasnapshot og notefelt — Udviddet feedback hvor en stjerne-bedømmelse gemmes sammen med: snapshot af aktuel sessions-data (varenr., debitornr., kostpris, AI-anbefaling, alle metoderesultater) og et kort fritekst-notefelt hvor brugeren kan uddybe sin bedømmelse. Giver konstruktivt grundlag for løbende forbedring af modellen. Kræver beslutning om lagerløsning — SharePoint-liste er den oplagte kandidat.
• PLANLAGTAutomatisk fragtberegning — K Hansen og udland — Fragtomkostning beregnes automatisk baseret på leveringsadresse, antal paller og ldm. Danske kunder: K Hansen Transport — baseret på eksisterende Excel-prisliste fra K Hansen som integreres som opslagstabel i beregneren. Udenlandske kunder: Blue Water eller tilsvarende speditør — kræver afklaring om API/MCP interface eller manuel prisliste-integration. K Hansen Excel-ark afventer gennemgang og strukturering.
• PLANLAGTAI Insights — tværgående analyse på tværs af data — Et selvstændigt analyse-view der giver ledelse og kundechefer overblik over om kunderne betaler de rigtige DB-niveauer set i forhold til: kundekategori (M/A/B/C) — betaler C-kunder strukturelt højere DB end A-kunder som forventet, eller er der afvigelser der kræver handling? Volumen — er der en tydelig sammenhæng mellem ordrestørrelse og opnået DB pr. enhed? Vare-segmenter — er der varegrupper hvor vi systematisk under- eller overpræsterer på DB? Sælger-performance — er der forskelle i opnået DB på tværs af kundechefer på sammenlignelige kunder og varer? Trend over tid — bevæger det samlede DB-niveau sig i den rigtige retning? Baseres på HIST og KALK-data samt KATEGORI-lookup. AI-analyse opsummerer mønstre og flaggger afvigelser der kræver kommerciel opmærksomhed. Kræver et separat view eller dashboard-integration.

Funktioner vi har overvejet og bevidst valgt fra — med begrundelse. Dokumenteret så vi ikke genopfinder hjulet.

• FRAVALGTTekst til sælger til kundekommunikation — Et AI-genereret tekst-forslag som sælgeren kan bruge overfor kunden til at forklare og begrunde den anbefalede pris. Fravalgt fordi: DB Assistenten arbejder med kostpris og DB uden IPO og fragtomkostninger — den endelige salgspris kunden præsenteres for er derfor ikke tilgængelig i systemet. En kundebegrundelse baseret på ufuldstændige prisdata ville blive for generisk til at have kommerciel værdi. Genovervejes når fuld prisstruktur inkl. IPO og fragt er tilgængelig i beregneren.
• FRAVALGTPrompt-dialog efter beregning — Mulighed for at stille opfølgende spørgsmål til AI'en i samme kontekst efter første analyse. Fravalgt fordi: (1) det nuværende kontekstfelt + Opdater AI Anbefaling dækker behovet tilstrækkeligt, (2) lang dialoghistorik kan få AI'en til at ræsonnere ud fra egne tidligere svar fremfor datagrundlaget, (3) hypotetiske spørgsmål som “hvad hvis kostpris stiger 10%?” løses bedre ved at taste ny kostpris og køre en ny beregning.
• FRAVALGTEkstern markedsindeks-data (FAO, Eurostat) — Integration af eksterne råvareprisindeks til at justere historiske priser for markedsbevægelser. Fravalgt fordi: den friske kostpris fra indkøb allerede afspejler alle markedsbevægelser — inflation, forsyningskæde-disruption og geopolitik er implicit indlejret i kostprisen. Eksterne indeks ville være redundant data.
• FRAVALGTOmkostningsstruktur i beregningen — Leveringstype, fragtomkostning, IPO og diverse tillægsomkostninger som aktive parametre i prisberegningen. Fravalgt i nuværende fase fordi: kompleksiteten overstrækker prototypens scope og risikerer at forvirre frem for at hjælpe. Ligger stadig i PLANLAGT til fremtidig overvejelse.