Specify-rådgivning

Gör svår efterfrågan till ett kommersiellt system

Specify hjälper företag att göra svår kundefterfrågan till tydligare kommersiella system, bättre specifikationsresor och återanvändbar kapacitet.

Företag vet ofta att de kan leverera mer än vad deras webbutik kan uttrycka. Det svåra är att göra den kunskapen till en resa kunderna kan använda, en struktur team kan styra och ett utfall företaget ansvarsfullt kan erbjuda.

Det innebär två sorters arbete: att bestämma vad som bör finnas, och att bygga de delar av det som plattformen ännu inte klarar.

Rådgivning kostar 400 € per timme exklusive moms. Omfattning och uppskattade timmar överenskoms innan något arbete börjar.

Varför detta finns

Klarar plattformen det inte än är det ett projekt, inte ett avslag

Den vanligaste orsaken till att ett företag inte kan flytta till en ny handelsplattform är inte pris eller strategi. Det är en enda sak som saknas: en integration med det system som faktiskt driver bolaget, en komponent deras produkt inte kan säljas utan, eller en beställningsprocess som inte liknar en standardcheckout.

Hela den här webbplatsen argumenterar för att företag förlorar god efterfrågan genom att avvisa förfrågningar innan de förstått om de skulle kunna tillgodoses. En plattform som avvisade en seriös kund på grund av en saknad konnektor skulle begå exakt det misstaget om sig själv och skulle förtjäna att få höra det.

Så när produkten ännu inte gör det ett företag behöver:

  1. Avgränsar vi det som utvecklingsarbete, till samma timpris som allt annat här.
  2. Säger vi rakt ut om vi kan bygga det, och tackar nej när vi inte kan göra det bra.
  3. Kommer vi överens i förväg om vem som äger det som byggs, vem som underhåller det, och vad som händer med det om någondera parten drar sig ur.
  4. Visar sig behovet vara generellt snarare än specifikt blir det en del av plattformen och slutar vara någons specialkod.

Exempel på hur det ser ut

  • Ett ERP-, PIM- eller WMS-system utan befintlig konnektor, även system ingen utanför verksamheten har sett
  • En produkt som måste visualiseras innan den kan specificeras eller beställas
  • Ett godkännandesteg mellan en konfigurerad specifikation och en bindande order
  • En offertprocess som standardflödet inte uttrycker
  • Katalog-, kapacitets- eller kunddata som måste migreras innan något annat kan börja

Inget av detta gör Specify till en byrå, och inget av det är ett löfte om att varje integration är möjlig. Vissa system har inget användbart gränssnitt, och vissa komponenter är ett större åtagande än ett företag väntar sig. Avgränsningen är där det fastställs, skriftligt, innan någon binder sig.

Utveckling

Att bygga det som saknas

Ingenjörsarbete, avgränsat och fakturerat per timme som allt annat. Det är vad en onboarding oftast behöver när ett företag är för stort eller för specifikt för produkten som den ser ut i dag.

Specialkomponenter och visualisering

Gränssnitt som plattformen inte levererar, för produkter som inte kan säljas utifrån ett foto och en rullgardinsmeny.

  • Produktvisualisering och konfigurerbara förhandsvisningar
  • Specifikationsgränssnitt för en viss produktfamilj
  • Väljare för material, ytbehandling och komponenter med verkliga begränsningar bakom sig
  • Särskild presentation av ett konfigurerat resultat innan det binds
  • Arbete med tillgänglighet och prestanda på allt som byggs

Integrationer med de system ni redan kör

Att koppla Specify till den programvara som faktiskt driver verksamheten, även system utan befintlig konnektor.

  • Kopplingar till ERP, PIM, WMS och CRM
  • Synkronisering av produkter, priser och lager
  • Överlämning av offerter och order till befintliga processer
  • Produktions- och planeringssystem
  • Särskilda API:er, filbaserat utbyte och vad verksamheten nu råkar ha

Särskilda beställnings- och godkännandeflöden

Där standardvägen från specifikation till order inte stämmer med hur företaget säljer.

  • Godkännandesteg mellan en specifikation och ett åtagande
  • Flöden för offert, förhandling och revidering
  • Hantering av kundspecifika priser och villkor
  • Beställning med flera parter, där den som specificerar och den som köper inte är samma
  • Överlämningspunkter mellan webbutiken och en människa

Onboarding och migrering

Att få ett stort befintligt företag på plattformen utan att förlora det som det redan vet.

  • Migrering av katalog- och produktdata
  • Modellering av befintlig kapacitet och befintliga begränsningar in i plattformens strukturer
  • Historiska förfrågnings- och kunddata
  • Parallelldrift medan det gamla systemet fortfarande är i gång
  • Utbildning och överlämning till det team som ska driva det

Allt som byggs på det här sättet avgränsas, uppskattas och överenskoms innan det börjar, och avtalet anger vem som äger det och vem som underhåller det efteråt. Det samtalet kommer först, eftersom specialbyggd programvara har en kostnad som fortsätter efter fakturan.

Rådgivning

Att komma fram till vad som bör finnas

Den andra halvan av arbetet, och oftast den halva som bör komma först. Att bygga fel integration korrekt är fortfarande fel integration. Det är de här problemen Specify är byggt kring, och ligger en förfrågan utanför dem säger vi det hellre än att ta uppdraget.

Analys av förfrågningar och efterfrågan

Förstå de svåra kundförfrågningar som i dag blir e-posttrådar, telefonsamtal, kalkylblad eller tyst avhopp.

  • Analysera representativa förfrågningar
  • Identifiera återkommande saknad information
  • Skilj kundens fakta, antaganden och okända faktorer åt
  • Hitta För tidigt nej: förfrågningar som avvisats innan de förstods
  • Kartlägg var efterfrågan med hög avsikt försvinner
  • Definiera ett bättre arbetsflöde för hantering av förfrågningar

Kapacitetsmodellering

Representera vad ett företag faktiskt kan leverera, utöver det som katalogen råkar publicera.

  • Kartlägg material, mått och konfigurationer
  • Skilj standard-, modifierade och specialanpassade utfall åt
  • Registrera kombinationer som inte är möjliga
  • Modellera leverantörsberoenden och villkor för ledtid
  • Definiera begränsningar för minimiorder och geografi
  • Ta fram Kapacitetskartan och Begränsningsregistret

Utformning av specifikationsresan

Utforma den process där en kund beskriver vad de faktiskt behöver.

  • Bestäm vilka frågor som ställs, och i vilken ordning
  • Skilj nödvändig information från valfria detaljer
  • Utforma gradvis förtydligande i stället för ett långt formulär
  • Hantera osäkerhet och godtagbara alternativ
  • Ta bort återvändsgränder, så att ingen väg slutar i ingenting
  • Definiera när en människa måste granska

Produkt- och webbutiksinformation

Visa den information kunderna gång på gång behöver och som webbplatsen i dag inte ger.

  • Analys av saknad information mot verkliga förfrågningar
  • Produktsidans struktur och tydlighet i specifikationer
  • Förklaringar av konfiguration och leverans
  • Språk om förtroende, godkännande och avslag
  • Jämförelseinnehåll och vanliga frågor
  • Observationer om tillgänglighet och rekommendationer för bilder

Kommersiella regler, begränsningar och behörighet

Bestäm hur kommersiell sanning styrs: vem kan lova vad, och på vilken grund.

  • Identifiera vem som kan godkänna vad, och vid vilken tröskel
  • Dokumentera de indata ett pris beror av
  • Skilj ett sannolikt utfall från en godkänd offert
  • Utforma arbetsflöden för granskning och godkännande
  • Definiera strukturen för Beslutsregistret
  • Förbättra spårbarheten i kommersiella åtaganden

Analys och förbättring av webbutiken

Granska en kommersiell upplevelse mot en skriven standard och gör fynden till en ordning någon kan agera på.

  • Definiera omfattningen av en analys innan den börjar
  • Skilj faktiska fel från hypoteser
  • Prioritera fynden efter kommersiell effekt
  • Översätt observationer till en förbättringsplan
  • Förbered implementeringsbriefer
  • Bestäm vad som skulle behöva mätas för att veta att det fungerade

Experiment och kommersiell förbättring

Gör en osäker rekommendation till ett test som kan falla ut negativt.

  • Skriv hypotesen och namnge kundproblemet
  • Välj mätvärdet innan ändringen byggs
  • Förbered text- eller upplevelsevarianter
  • Identifiera risker och vem som måste godkänna
  • Fastställ kriterier för framgång och misslyckande i förväg
  • Registrera resultatet, även när ingenting rörde sig

AI-stödda arbetsflöden för handlare

Kom fram till var AI ansvarsfullt kan hjälpa till i handel och administration, och var den inte får besluta.

  • Koncept för handlarens arbetsflöde och innehållshantering
  • Kontroller för kapacitetsuppdatering och utkast kontra publicering
  • Var mänsklig granskning är obligatorisk
  • Ändringshistorik och ansvar för ändringar
  • Prompt- och informationsarkitektur
  • Gränsen mellan tolkning och kommersiell behörighet

Handels- och produktstrategi

Bestäm om efterfrågestyrd handel över huvud taget är relevant för ett företag, innan någon bygger något.

  • Driftsmodeller för konfigurerbara produkter och specialprodukter
  • Strategi för leverantörs- och produktionsnätverk
  • Strategi för avsiktsdata: vilken outnyttjad efterfrågan är värd att fånga upp
  • Beslut om att bygga själv eller köpa
  • Definition av pilot och ordningsföljd för implementering
  • Skriftliga kommersiella produktbriefer

Flera av dessa överlappar i praktiken. En kapacitetsmodell som ingen kan godkänna utifrån är inte färdig, och en specifikationsresa byggd på en omodellerad kapacitet ger svar som företaget inte kan hålla.

Var det oftast börjar

Meningar vi hör i början

Ligger någon av dessa nära något ni sagt högt den senaste månaden är rådgivning troligen relevant.

  • Vi skulle gärna flytta, men det integrerar inte med det system som driver vår verksamhet.
  • Vår produkt måste ses innan den kan beställas, och ingen plattformskomponent klarar det.
  • Det finns ett godkännandesteg mellan en specifikation och en order som en standardcheckout inte kan uttrycka.
  • Kunder frågar ofta efter produkter vi kan tillverka men inte publicerar.
  • Specialförfrågningar tar flera dagar och går mellan tre avdelningar.
  • Vår konfigurator skapar återvändsgränder och vi vet inte var.
  • Vi vet inte vilken information kunderna saknar.
  • Sälj vet vad som är möjligt. Webbplatsen gör det inte.
  • Vi överväger en AI-stödd köpresa och vet inte vad det auktoritativa datalagret bör vara.
  • Vi behöver göra återkommande offertarbete till något som skalar.
  • Vi behöver en pilotbrief innan vi binder oss till en större implementering.

Listan är inte uttömmande och inget på den kommer att träffa er formulering exakt. Den röda tråden är ett glapp mellan vad ett företag faktiskt kan leverera och vad dess programvara låter en kund fråga efter. Låter det bekant är en brief det snabbaste sättet att fastställa om det finns arbete här värt att göra.

Uppdragsformat

Fem sätt att arbeta tillsammans

  1. Fokuserat rådgivningsmöte

    En tydligt definierad fråga, granskning eller ett beslut. Några timmar, oftast ett enda samtal med förberedelse på var sida om det. Passar när ni vet vad ni frågar om och behöver ett svar ni kan agera på.

  2. Diagnostiskt uppdrag

    Förstå den nuvarande processen innan något föreslås: intervjuer, befintligt underlag, verkliga förfrågningar och var processen faktiskt brister. Slutar i en skriven problemdefinition snarare än en lösning.

  3. Rådgivningssprint

    Ta fram en konkret leverans: en Kapacitetskarta, en begränsningsmodell, en prototyp för ett specifikationsflöde, en förbättringsplan, en pilotbrief, en experimentplan eller en implementeringsbrief. Avgränsat till en namngiven produkt, så att det är uppenbart när den är färdig.

  4. Implementering och byggande

    Att bygga komponenten, integrationen, flödet eller migreringen mot en omfattning som överenskommits i förväg. Det är ingenjörsarbete och det är det format en onboarding oftast slutar i. Avtalet namnger vem som äger resultatet och vem som underhåller det innan någon kod skrivs.

  5. Löpande rådgivning och implementeringsstöd

    Återkommande hjälp med produkt-, kommersiella och implementeringsbeslut, för företag som gör arbetet själva och vill ha någon att diskutera med. Faktureras mot faktiska timmar, utan minimiarvode.

Så fungerar det

Från brief till överenskommen omfattning

Fem steg. Ingenting är fakturerbart förrän det tredje är undertecknat, och de två första sker oavsett om ni går vidare eller inte.

  1. 1. Skicka in en brief

    Ni beskriver verksamheten, problemet och det önskade utfallet

    Formuläret längst ned på den här sidan frågar vad som händer i dag, var processen bryter samman och vad som bör vara annorlunda efteråt. Det tar ungefär tio minuter och det är samma struktur vi ändå skulle använda i det första samtalet.

  2. 2. Vi går igenom den

    Vi avgör om det är ett uppdrag vi bör ta

    Två frågor: ligger det inom det Specify verkligen är bra på, och finns det tillräckligt med information för att avgränsa det ansvarsfullt. Är svaret nej på någon av dem säger vi det. Att skicka in en brief är inte ett godkännande av ett uppdrag.

  3. 3. Omfattning och avtal

    Allt överenskoms skriftligt innan arbetet börjar

    Målet, leveranserna, vilka som deltar, de uppskattade timmarna, timpriset, tidplanen, vad vi är beroende av från er, sekretess där det är relevant, vem som äger resultaten och vad de får användas till, och vem som granskar och godkänner. Där något byggs anges också vem som underhåller det efteråt och vad som händer med det om någondera parten drar sig ur. Visar sig uppskattningen vara fel säger vi till innan timmarna används, inte efteråt.

  4. 4. Arbetet börjar

    Intervjuer, underlag, modellering, prototypframtagning, byggande

    Blandningen beror på uppdraget. En diagnostik är mest intervjuer och läsning av verkliga förfrågningar. En rådgivningssprint är mest modellering och skrivande. Ett byggnadsuppdrag är ingenjörsarbete, där ert team är med i granskningen snarare än får veta i slutet.

  5. 5. Fynden blir möjliga att agera på

    Uttryckliga resultat, beslut, öppna frågor och nästa steg

    Ni får vad som hittades, vad vi rekommenderar, vad som fortfarande är okänt och vad vi skulle göra härnäst. Öppna frågor står som öppna snarare än att tyst slutas med ett antagande.

Där ett uppdrag avslöjar ett mönster vi anser på sikt bör bli en del av plattformen registrerar vi det separat. Det är vår anteckning om vår produkt, och den innehåller aldrig er konfidentiella information.

Priser

Tydligt timpris

Rådgivning faktureras till 400 € per timme, exklusive moms.

Innan arbetet börjar lämnar Specify en överenskommen omfattning eller en arbetsuppskattning som täcker målet, de förväntade leveranserna, deltagarna och det troliga antalet timmar. Ni godkänner en uppskattning och ett timpris, inte en öppen taxameter.

Valuta och moms

Priserna är i euro. 400 € per timme är exklusive moms, som tillämpas enligt ert faktureringsland.

Vad som är fakturerbart

Tid som läggs på uppdraget, inklusive förberedelse, workshoppar, analys och skriftligt arbete. Avgränsningssamtalet innan ett avtal finns är inte fakturerbart.

Uppskattningar

Uppskattade timmar överenskoms i förväg och är en uppskattning, inte ett fast pris. Om arbetet kommer att överskrida uppskattningen tar vi upp det innan timmarna används.

Utlägg

Rese- och tredjepartskostnader överenskoms separat i förväg om de alls uppstår. De flesta uppdrag sker på distans och medför inga.

Det finns inget paket, ingen nivå och inget minimiarvode. Varje uppdrag avgränsas skriftligt innan det börjar, och faktureras mot de timmar det faktiskt tar.

Varför vi gör detta

Rådgivning som informerar plattformen

Specify-rådgivning är inte tänkt att bli en fristående byråverksamhet vid sidan om. Den finns eftersom det snabbaste sättet att lära sig vad handelsprogramvara bör göra är att först lösa problemet för hand, med ett verkligt företag, under verkliga begränsningar, och eftersom en plattform som bara kan betjäna de kunder den redan passar aldrig får veta vad den saknar.

Uppdrag avslöjar saker ett roadmap-möte inte kan:

  • Vilka kommersiella beslut som är svårast att strukturera
  • Vilken kapacitetsinformation som gång på gång saknas
  • Vilka integrationer företag faktiskt behöver, snarare än de som låter självklara
  • Vilka komponenter en produktkategori verkligen inte kan säljas utan
  • Vilka frågor kunder genomgående har svårt att besvara
  • Vilka begränsningar som behöver tydligare representation
En handlare blockerad av något plattformen inte klarar
En rådgivningsutredning, och oftast ett utvecklingsarbete
Fungerande programvara för det företaget
Samma behov dyker upp från någon annan
En återanvändbar metod, komponent eller plattformskapacitet
Nästa företag blockeras inte alls av det

Vissa problem är specifika för ett företag. Andra avslöjar kapaciteter plattformen på sikt bör göra återanvändbara. De flesta uppdrag kommer att vara av den första sorten, och det säger vi hellre än att antyda att varje rådgivningsinsats tyst blir programvara.

Det har kommersiell och inte bara filosofisk betydelse. Specialkod skriven för ett företag måste underhållas av någon så länge det företaget använder den, och en plattform som samlar på sig tillräckligt av den slutar vara en plattform. Att tidigt avgöra om något är specialbyggt eller en kandidat att bli generellt är hur det undviks, och det är ett samtal vi hellre tar under avgränsningen än två år senare.

Handlarkonfidentiell information förblir konfidentiell. Allt som informerar plattformen är ett abstraherat mönster, inte era data, era priser eller er leverantörslista. Där ett uppdrag ger något vi skulle vilja generalisera frågar vi först.

Ni behåller rättigheterna till era leveranser och er konfidentiella information enligt det undertecknade uppdragsavtalet. Ingenting på den här sidan ändrar de villkoren, och avtalet gäller där de två skiljer sig åt.

Vad vi inte påstår

Rekommendationer är inte resultat

Rådgivning börjar med underlag, begränsningar och en definierad kommersiell fråga. Rekommendationer presenteras inte som uppmätta utfall, och varje förväntad effekt bör testas eller verifieras där det är praktiskt möjligt.

  • Vi lovar inte ökad konvertering, ökad omsättning eller lägre kostnad, eftersom vi inte har någon uppdragshistorik som skulle låta oss förutsäga det ärligt.
  • Vi lovar inte kortare ledtider. Ledtider är en egenskap hos er produktion, inte hos ett dokument vi skriver.
  • Vi automatiserar inte produktion, och ingenting i ett uppdrag ändrar vad er fabrik eller era leverantörer kan göra.
  • Vi påstår inte att varje specialförfrågan kan göras lönsam. Viss efterfrågan bör avvisas snabbare, och att säga det är ofta det mer värdefulla fyndet.
  • Vi lovar inte statistiskt tillförlitliga experimentresultat vid volymer där statistik inte gäller.
  • Vi påstår inte att varje uppdrag blir en plattformsfunktion, och inget uppdrag prissätts utifrån antagandet att det kanske gör det.
  • Vi påstår inte att vi kan integrera med vilket system som helst. Vissa har inget användbart gränssnitt, och avgränsningen är där det fastställs snarare än upptäcks senare.
  • Vi är ett litet team och har inte en byrås leveranskapacitet. Där ett arbete kräver fler personer än vi har säger vi det hellre än att tänja oss för att ta det.

Det enda vi åtar oss är att ni efteråt vet mer om er egen kommersiella process än ni gjorde innan, skriftligt, inklusive de delar som visar sig vara obekväma.

Så tänker vi kring detta

Se resonemanget innan ni beställer något av det

Specify för en katalog över idéer till kommersiella förbättringar: vilket problem var och en adresserar, hur den skulle kunna implementeras, vad som kan gå fel, och vad som skulle behöva mätas för att veta om den fungerade. Ett urval publiceras, mer delas med kunder, och resten förblir internt.

De publicerade posterna är ett rättvisande urval av hur dessa uppdrag angrips. Liknar resonemanget det ni vill se tillämpat på er egen katalog, er kapacitet och era begränsningar, är det vad en brief sätter i gång.

Rådgivningsbrief

Skissa en rådgivningsbrief

Fyra korta skärmar, ungefär tio minuter. Den frågar om samma saker vi skulle fråga om i ett första samtal, vilket gör att samtalet kan börja längre fram.

  1. Problemet
  2. Sammanhang
  3. Era uppgifter
  4. Bekräfta

Vad är problemet?

Börja med vad som faktiskt händer snarare än vad ni tror att lösningen är. Vet ni redan lösningen, säg det också.

Vad för er till Specify?

Välj så många som stämmer. Det avgör vem som läser briefen, inte vad den kostar.

Vad händer i dag, och var bryter processen samman? Konkret slår allmänt: en verklig förfrågan som gick illa är värd mer än en beskrivning av kategorin.

Vad bör vara tydligare, snabbare, säkrare eller kommersiellt möjligt efter uppdraget?

Börja här

Skissa en rådgivningsbrief

Ungefär tio minuter. Den frågar vad som händer i dag, vad som bör vara annorlunda och vilka som skulle behöva vara med. Att skicka in den är inget åtagande, och ingenting är fakturerbart förrän en omfattning är överenskommen skriftligt.

Vill ni hellre börja med underlag än med ett samtal körs demobutiken på den här webbplatsen och visar hur produkten gör arbetet.