Specify-rådgivning

Gør vanskelig efterspørgsel til et kommercielt system

Specify hjælper virksomheder med at gøre vanskelig kundeefterspørgsel til klarere kommercielle systemer, bedre specifikationsrejser og genanvendelig kapacitet.

Virksomheder ved ofte, at de kan levere mere, end deres webshop kan udtrykke. Det svære er at gøre den viden til en rejse, kunderne kan bruge, en struktur, teams kan styre, og et udfald, virksomheden ansvarligt kan tilbyde.

Det betyder to slags arbejde: at beslutte, hvad der bør findes, og at bygge de dele af det, platformen endnu ikke kan.

Rådgivning koster 400 € i timen ekskl. moms. Omfang og estimerede timer aftales, før noget arbejde går i gang.

Hvorfor det findes

Kan platformen det ikke endnu, er det et projekt, ikke et afslag

Den hyppigste grund til, at en virksomhed ikke kan flytte til en ny handelsplatform, er ikke pris eller strategi. Det er én manglende ting: en integration med det system, der faktisk driver virksomheden, en komponent, deres produkt ikke kan sælges uden, eller en bestillingsproces, der ikke ligner en standardcheckout.

Hele dette site argumenterer for, at virksomheder mister god efterspørgsel ved at afvise forespørgsler, før de har forstået, om de kunne imødekommes. En platform, der afviste en seriøs kunde på grund af en manglende konnektor, ville begå præcis den fejl om sig selv og ville fortjene at få det at vide.

Så når produktet endnu ikke gør det, en virksomhed har brug for:

  1. Afgrænser vi det som udviklingsarbejde, til samme timetakst som alt andet her.
  2. Siger vi ligeud, om vi kan bygge det, og takker nej, når vi ikke kan gøre det godt.
  3. Aftaler vi på forhånd, hvem der ejer det, der bygges, hvem der vedligeholder det, og hvad der sker med det, hvis den ene part går.
  4. Viser behovet sig at være generelt frem for specifikt, bliver det en del af platformen og holder op med at være nogens specialkode.

Eksempler på, hvordan det ser ud

  • Et ERP-, PIM- eller WMS-system uden en eksisterende konnektor, også systemer ingen uden for virksomheden har set
  • Et produkt, der skal visualiseres, før det kan specificeres eller bestilles
  • Et godkendelsestrin mellem en konfigureret specifikation og en bindende ordre
  • En tilbudsproces, standardforløbet ikke udtrykker
  • Katalog-, kapacitets- eller kundedata, der skal migreres, før noget andet kan begynde

Intet af dette gør Specify til et bureau, og intet af det er et løfte om, at enhver integration er mulig. Nogle systemer har ingen brugbar grænseflade, og nogle komponenter er en større opgave, end en virksomhed forventer. Afgrænsningen er der, hvor det bliver fastslået, på skrift, før nogen forpligter sig.

Udvikling

At bygge det, der mangler

Ingeniørarbejde, afgrænset og faktureret i timer som alt andet. Det er det, en onboarding som regel har brug for, når en virksomhed er for stor eller for specifik til produktet, som det er i dag.

Specialkomponenter og visualisering

Grænseflader, platformen ikke leverer, til produkter, der ikke kan sælges ud fra et foto og en dropdown.

  • Produktvisualisering og konfigurerbare forhåndsvisninger
  • Specifikationsgrænseflader til en bestemt produktfamilie
  • Vælgere til materiale, overflade og komponenter med reelle begrænsninger bag sig
  • Særskilt præsentation af et konfigureret resultat, før det bindes
  • Arbejde med tilgængelighed og ydeevne på alt, der bygges

Integrationer med de systemer, I allerede kører

At forbinde Specify med den software, der faktisk driver virksomheden, også systemer uden en eksisterende konnektor.

  • Forbindelser til ERP, PIM, WMS og CRM
  • Synkronisering af produkter, priser og lager
  • Overlevering af tilbud og ordrer til eksisterende processer
  • Produktions- og planlægningssystemer
  • Særskilte API'er, filbaseret udveksling og hvad virksomheden nu engang har

Særskilte bestillings- og godkendelsesforløb

Hvor standardvejen fra specifikation til ordre ikke passer til den måde, virksomheden sælger på.

  • Godkendelsestrin mellem en specifikation og et tilsagn
  • Forløb for tilbud, forhandling og revision
  • Håndtering af kundespecifikke priser og vilkår
  • Bestilling med flere parter, hvor den, der specificerer, og den, der køber, ikke er den samme
  • Overleveringspunkter mellem webshoppen og et menneske

Onboarding og migrering

At få en stor eksisterende virksomhed over på platformen uden at miste det, den allerede ved.

  • Migrering af katalog- og produktdata
  • Modellering af eksisterende kapacitet og begrænsninger ind i platformens strukturer
  • Historiske forespørgsels- og kundedata
  • Paralleldrift, mens det gamle system stadig kører
  • Oplæring og overlevering til det team, der skal drive det

Alt, der bygges på den måde, afgrænses, estimeres og aftales, før det går i gang, og aftalen siger, hvem der ejer det, og hvem der vedligeholder det bagefter. Den samtale kommer først, fordi specialbygget software har en omkostning, der fortsætter efter fakturaen.

Rådgivning

At finde ud af, hvad der bør findes

Den anden halvdel af arbejdet, og som regel den halvdel, der bør komme først. At bygge den forkerte integration korrekt er stadig den forkerte integration. Det er de problemer, Specify er bygget omkring, og ligger en forespørgsel uden for dem, siger vi det frem for at tage opgaven.

Analyse af forespørgsler og efterspørgsel

Forstå de vanskelige kundeforespørgsler, der i dag ender som e-mailtråde, telefonopkald, regneark eller tavs opgivelse.

  • Analysér repræsentative forespørgsler
  • Identificér tilbagevendende manglende oplysninger
  • Adskil kundens fakta, antagelser og ubekendte
  • Find For tidligt nej: forespørgsler afvist, før de blev forstået
  • Kortlæg, hvor efterspørgsel med høj hensigt forsvinder
  • Definér et bedre arbejdsforløb til håndtering af forespørgsler

Kapacitetsmodellering

Repræsentér, hvad en virksomhed reelt kan levere, ud over det, dens katalog tilfældigvis publicerer.

  • Kortlæg materialer, mål og konfigurationer
  • Adskil standard-, modificerede og specialtilpassede udfald
  • Registrér kombinationer, der ikke er mulige
  • Modellér leverandørafhængigheder og betingelser for leveringstid
  • Definér begrænsninger for minimumsordre og geografi
  • Udarbejd Kapacitetskortet og Begrænsningsregisteret

Design af specifikationsrejsen

Design den proces, hvor en kunde beskriver, hvad de faktisk har brug for.

  • Beslut hvilke spørgsmål der stilles, og i hvilken rækkefølge
  • Adskil nødvendige oplysninger fra valgfri detaljer
  • Design gradvis afklaring i stedet for én lang formular
  • Håndtér usikkerhed og acceptable alternativer
  • Fjern blindgyder, så ingen vej ender i ingenting
  • Definér, hvornår et menneske skal se på det

Produkt- og butiksinformation

Fremvis de oplysninger, kunderne gentagne gange har brug for, og som sitet i dag ikke leverer.

  • Analyse af manglende oplysninger op mod reelle forespørgsler
  • Produktsidens struktur og klarhed i specifikationer
  • Forklaringer af konfiguration og levering
  • Sprog om tillid, godkendelse og afvisning
  • Sammenligningsindhold og ofte stillede spørgsmål
  • Observationer om tilgængelighed og anbefalinger til billeder

Kommercielle regler, begrænsninger og kompetence

Beslut, hvordan kommerciel sandhed styres: hvem kan love hvad, og på hvilket grundlag.

  • Identificér, hvem der kan godkende hvad, og ved hvilken tærskel
  • Dokumentér de input, en pris afhænger af
  • Adskil et sandsynligt udfald fra et godkendt tilbud
  • Design gennemgangs- og godkendelsesforløb
  • Definér strukturen for Beslutningsregisteret
  • Forbedr sporbarheden af kommercielle tilsagn

Analyse og forbedring af webshoppen

Undersøg en kommerciel oplevelse op mod en skriftlig standard, og gør fundene til en rækkefølge, nogen kan handle på.

  • Definér omfanget af en analyse, før den begynder
  • Adskil egentlige fejl fra hypoteser
  • Prioritér fund efter kommerciel effekt
  • Oversæt observationer til en forbedringsplan
  • Forbered implementeringsbriefs
  • Beslut, hvad der skulle måles for at vide, at det virkede

Eksperimenter og kommerciel forbedring

Gør en usikker anbefaling til en test, der kan komme negativt tilbage.

  • Skriv hypotesen, og navngiv kundeproblemet
  • Vælg målepunktet, før ændringen bygges
  • Forbered tekst- eller oplevelsesvarianter
  • Identificér risici, og hvem der skal godkende
  • Fastsæt succes- og fejlkriterier på forhånd
  • Registrér resultatet, også når intet flyttede sig

AI-understøttede arbejdsforløb for forhandlere

Find ud af, hvor AI ansvarligt kan hjælpe i handel og administration, og hvor den ikke må beslutte.

  • Koncepter for forhandlerforløb og indholdsstyring
  • Kontroller for kapacitetsopdatering og udkast kontra publicering
  • Hvor menneskelig gennemgang er obligatorisk
  • Ændringshistorik og ansvar for ændringer
  • Prompt- og informationsarkitektur
  • Grænsen mellem fortolkning og kommerciel kompetence

Handels- og produktstrategi

Beslut, om efterspørgselsdrevet handel overhovedet er relevant for en virksomhed, før nogen bygger noget.

  • Driftsmodeller for konfigurerbare produkter og specialprodukter
  • Strategi for leverandør- og produktionsnetværk
  • Strategi for hensigtsdata: hvilken uindfriet efterspørgsel er værd at opsamle
  • Beslutninger om selv at bygge eller købe
  • Definition af pilot og rækkefølge for implementering
  • Skriftlige kommercielle produktbriefs

Flere af disse overlapper i praksis. En kapacitetsmodel, ingen kan godkende ud fra, er ikke færdig, og en specifikationsrejse bygget på en umodelleret kapacitet vil producere svar, virksomheden ikke kan holde.

Hvor det som regel begynder

Sætninger, vi hører i begyndelsen

Ligner en af disse noget, I har sagt højt inden for den seneste måned, er rådgivning sandsynligvis relevant.

  • Vi ville gerne flytte, men det integrerer ikke med det system, der driver vores virksomhed.
  • Vores produkt skal ses, før det kan bestilles, og ingen platformskomponent kan det.
  • Der er et godkendelsestrin mellem en specifikation og en ordre, som en standardcheckout ikke kan udtrykke.
  • Kunder spørger ofte efter produkter, vi kan lave, men ikke offentliggør.
  • Specialforespørgsler tager flere dage og går gennem tre afdelinger.
  • Vores konfigurator skaber blindgyder, og vi ved ikke hvor.
  • Vi ved ikke, hvilke oplysninger kunderne mangler.
  • Salg ved, hvad der er muligt. Hjemmesiden gør ikke.
  • Vi overvejer en AI-understøttet købsrejse og ved ikke, hvad det autoritative datalag bør være.
  • Vi har brug for at gøre gentaget tilbudsarbejde til noget, der skalerer.
  • Vi har brug for en pilotbrief, før vi forpligter os til en større implementering.

Listen er ikke udtømmende, og intet på den vil ramme jeres formulering præcist. Den røde tråd er en afstand mellem det, en virksomhed faktisk kan levere, og det, dens software lader en kunde spørge om. Lyder det bekendt, er en brief den hurtigste måde at fastslå, om der er arbejde her, der er værd at udføre.

Opgaveformater

Fem måder at arbejde sammen på

  1. Fokuseret rådgivningsmøde

    Ét klart defineret spørgsmål, en gennemgang eller en beslutning. Nogle få timer, som regel én samtale med forberedelse på hver side af den. Passende, når I ved, hvad I spørger om, og har brug for et svar, I kan handle på.

  2. Diagnostisk opgave

    Forstå den nuværende proces, før noget foreslås: interviews, eksisterende dokumentation, reelle forespørgsler og der, hvor processen faktisk bryder sammen. Ender i en skriftlig problemdefinition frem for en løsning.

  3. Rådgivningssprint

    Producér én konkret leverance: et Kapacitetskort, en begrænsningsmodel, en prototype på et specifikationsforløb, en forbedringsplan, en pilotbrief, en eksperimentplan eller en implementeringsbrief. Afgrænset til et navngivet produkt, så det er tydeligt, hvornår det er færdigt.

  4. Implementering og bygning

    At bygge komponenten, integrationen, forløbet eller migreringen mod et omfang aftalt på forhånd. Det er ingeniørarbejde, og det er det format, en onboarding som regel ender i. Aftalen navngiver, hvem der ejer resultatet, og hvem der vedligeholder det, før der skrives kode.

  5. Løbende rådgivning og implementeringsstøtte

    Tilbagevendende hjælp på tværs af produkt-, kommercielle og implementeringsbeslutninger, til virksomheder, der selv udfører arbejdet og gerne vil have nogen at diskutere med. Faktureres mod faktiske timer, uden minimumshonorar.

Sådan fungerer det

Fra brief til aftalt omfang

Fem trin. Intet er fakturerbart, før det tredje er underskrevet, og de første to sker, uanset om I går videre eller ej.

  1. 1. Indsend en brief

    I beskriver virksomheden, problemet og det ønskede udfald

    Formularen nederst på denne side spørger, hvad der sker i dag, hvor processen bryder sammen, og hvad der bør være anderledes bagefter. Den tager cirka ti minutter, og det er den samme struktur, vi alligevel ville bruge i den første samtale.

  2. 2. Vi gennemgår den

    Vi beslutter, om det er en opgave, vi bør tage

    To spørgsmål: ligger det inden for det, Specify reelt er god til, og er der information nok til at afgrænse det ansvarligt. Er svaret nej til et af dem, siger vi det. At indsende en brief er ikke en accept af en opgave.

  3. 3. Omfang og aftale

    Alt aftales skriftligt, før arbejdet begynder

    Formålet, leverancerne, hvem der deltager, de estimerede timer, taksten, tidsplanen, hvad vi er afhængige af fra jer, fortrolighed hvor det er relevant, hvem der ejer resultaterne, og hvad de må bruges til, og hvem der gennemgår og godkender. Hvor noget bygges, står der også, hvem der vedligeholder det bagefter, og hvad der sker med det, hvis den ene part går. Viser estimatet sig at være forkert, siger vi til, før timerne bruges, ikke bagefter.

  4. 4. Arbejdet går i gang

    Interviews, dokumentation, modellering, prototyping, bygning

    Blandingen afhænger af opgaven. En diagnostik er mest interviews og læsning af reelle forespørgsler. Et rådgivningssprint er mest modellering og skrivning. En byggeopgave er ingeniørarbejde, hvor jeres team er med i gennemgangen frem for at få det at vide til sidst.

  5. 5. Fundene bliver til noget, man kan handle på

    Eksplicitte resultater, beslutninger, åbne spørgsmål og næste skridt

    I får, hvad der blev fundet, hvad vi anbefaler, hvad der stadig er ukendt, og hvad vi ville gøre som det næste. Åbne spørgsmål står som åbne frem for stille at blive lukket med en antagelse.

Hvor en opgave afdækker et mønster, vi mener på sigt bør blive en del af platformen, registrerer vi det særskilt. Det er vores note om vores produkt, og den indeholder aldrig jeres fortrolige oplysninger.

Priser

Klar timepris

Rådgivning faktureres til 400 € i timen, ekskl. moms.

Før arbejdet går i gang, leverer Specify et aftalt omfang eller et arbejdsestimat, der dækker formålet, de forventede leverancer, deltagerne og det sandsynlige antal timer. I siger ja til et estimat og en takst, ikke til et åbent taxameter.

Valuta og moms

Taksterne er i euro. 400 € i timen er eksklusive moms, som pålægges efter jeres faktureringsland.

Hvad der er fakturerbart

Tid brugt på opgaven, inklusive forberedelse, workshops, analyse og skriftligt arbejde. Afgrænsningssamtalen, før der findes en aftale, er ikke fakturerbar.

Estimater

Estimerede timer aftales på forhånd og er et estimat, ikke en fast pris. Hvis arbejdet kommer til at overskride estimatet, siger vi til, før timerne bruges.

Udgifter

Rejse- og tredjepartsomkostninger aftales særskilt på forhånd, hvis de overhovedet opstår. De fleste opgaver kører på afstand og medfører ingen.

Der er ingen pakke, intet niveau og intet minimumshonorar. Enhver opgave afgrænses skriftligt, før den går i gang, og faktureres efter de timer, den faktisk tager.

Hvorfor vi gør det

Rådgivning, der oplyser platformen

Specify-rådgivning er ikke ment som en selvstændig bureauforretning ved siden af. Den findes, fordi den hurtigste måde at lære, hvad handelssoftware bør kunne, er først at løse problemet i hånden, med en rigtig virksomhed, under rigtige begrænsninger, og fordi en platform, der kun kan betjene de kunder, den allerede passer til, aldrig finder ud af, hvad den mangler.

Opgaver afdækker ting, et roadmap-møde ikke kan:

  • Hvilke kommercielle beslutninger der er sværest at strukturere
  • Hvilke kapacitetsoplysninger der gentagne gange mangler
  • Hvilke integrationer virksomheder faktisk har brug for, frem for dem der lyder oplagte
  • Hvilke komponenter en produktkategori reelt ikke kan sælges uden
  • Hvilke spørgsmål kunder konsekvent har svært ved at besvare
  • Hvilke begrænsninger der har brug for en klarere repræsentation
En forhandler blokeret af noget, platformen ikke kan
En rådgivningsundersøgelse, og som regel et udviklingsforløb
Fungerende software til den virksomhed
Det samme behov dukker op fra en anden
En genanvendelig metode, komponent eller platformskapacitet
Den næste virksomhed er slet ikke blokeret af det

Nogle problemer er specifikke for én virksomhed. Andre afdækker kapaciteter, platformen på sigt bør gøre genanvendelige. De fleste opgaver vil være den første slags, og det siger vi hellere end at antyde, at ethvert stykke rådgivning stille og roligt bliver til software.

Det har kommerciel og ikke kun filosofisk betydning. Specialkode skrevet til én virksomhed skal vedligeholdes af nogen, så længe den virksomhed bruger den, og en platform, der samler nok af den, holder op med at være en platform. At beslutte tidligt, om noget er specialbygget eller en kandidat til at blive generelt, er måden, det undgås på, og det er en samtale, vi hellere vil tage under afgrænsningen end to år senere.

Forhandlerfortrolige oplysninger forbliver fortrolige. Alt, der oplyser platformen, er et abstraheret mønster, ikke jeres data, jeres priser eller jeres leverandørliste. Hvor en opgave frembringer noget, vi gerne vil generalisere, spørger vi først.

I bevarer rettighederne til jeres leverancer og jeres fortrolige oplysninger som fastlagt i den underskrevne opgaveaftale. Intet på denne side ændrer de vilkår, og aftalen er gældende, hvor de to afviger fra hinanden.

Hvad vi ikke påstår

Anbefalinger er ikke resultater

Rådgivning begynder med dokumentation, begrænsninger og et defineret kommercielt spørgsmål. Anbefalinger fremlægges ikke som målte resultater, og enhver forventet effekt bør testes eller verificeres, hvor det er praktisk muligt.

  • Vi lover ikke øget konvertering, omsætning eller lavere omkostninger, fordi vi ikke har en opgavehistorik, der ville lade os forudsige det ærligt.
  • Vi lover ikke kortere leveringstider. Leveringstider er en egenskab ved jeres produktion, ikke ved et dokument, vi skriver.
  • Vi automatiserer ikke produktion, og intet i en opgave ændrer, hvad jeres fabrik eller jeres leverandører kan.
  • Vi påstår ikke, at enhver specialforespørgsel kan gøres rentabel. Noget efterspørgsel bør afvises hurtigere, og at sige det er ofte det mere værdifulde fund.
  • Vi lover ikke statistisk pålidelige eksperimentresultater ved mængder, hvor statistik ikke gælder.
  • Vi påstår ikke, at enhver opgave bliver til en platformsfunktion, og ingen opgave prissættes ud fra en antagelse om, at den måske gør.
  • Vi påstår ikke, at vi kan integrere med ethvert system. Nogle har ingen brugbar grænseflade, og afgrænsningen er der, hvor det bliver fastslået frem for opdaget senere.
  • Vi er et lille team og har ikke et bureaus leveringskapacitet. Hvor en opgave kræver flere folk, end vi har, siger vi det frem for at strække os for at tage den.

Det eneste, vi forpligter os på, er, at I bagefter ved mere om jeres egen kommercielle proces, end I gjorde før, på skrift, inklusive de dele, der viser sig at være ubelejlige.

Sådan tænker vi om det

Se tankegangen, før I bestiller noget af det

Specify fører et katalog over idéer til kommercielle forbedringer: hvilket problem hver enkelt adresserer, hvordan den kunne implementeres, hvad der kunne gå galt, og hvad der skulle måles for at vide, om den virkede. Et udvalg offentliggøres, mere deles med kunder, og resten forbliver internt.

De offentliggjorte poster er et retvisende udsnit af, hvordan disse opgaver gribes an. Ligner ræsonnementet det, I gerne vil have anvendt på jeres eget katalog, jeres kapacitet og jeres begrænsninger, er det, en brief sætter i gang.

Rådgivningsbrief

Skitsér en rådgivningsbrief

Fire korte skærmbilleder, cirka ti minutter. Den spørger om det samme, vi ville spørge om i en første samtale, hvilket betyder, at samtalen kan begynde længere fremme.

  1. Problemet
  2. Kontekst
  3. Jeres oplysninger
  4. Bekræft

Hvad er problemet?

Begynd med, hvad der faktisk sker, frem for hvad I tror løsningen er. Kender I allerede løsningen, så sig også det.

Hvad bringer jer til Specify?

Vælg så mange, som passer. Det afgør, hvem der læser briefen, ikke hvad den koster.

Hvad sker der i dag, og hvor bryder processen sammen? Konkret slår generelt: én reel forespørgsel, der gik skidt, er mere værd end en beskrivelse af kategorien.

Hvad bør være klarere, hurtigere, sikrere eller kommercielt muligt efter opgaven?

Start her

Skitsér en rådgivningsbrief

Cirka ti minutter. Den spørger, hvad der sker i dag, hvad der bør være anderledes, og hvem der skal involveres. At indsende den er ikke en forpligtelse, og intet er fakturerbart, før et omfang er aftalt skriftligt.

Vil I hellere begynde med dokumentation end med en samtale, kører demobutikken på dette site og viser, hvordan produktet gør arbejdet.