Tidsplan och leverans

Tiden beror på hur många sidor och funktioner som ingår samt hur snabbt beslut och material kommer in från er sida. En enklare webbplats med färre sidor går betydligt snabbare att bygga än en med skräddarsydda funktioner och integrationer. Vi ger en tidsuppskattning efter att ha gått igenom kraven i uppstarten.

Det beror framför allt på antalet produkter, vilka betal- och fraktlösningar som ska integreras och om butiken ska kopplas mot ett affärssystem. En e-handel med enklare produktsortiment och standardintegrationer tar kortare tid än en med komplexa lagerkopplingar eller flera marknader. Vi sätter en realistisk tidsplan utifrån den faktiska omfattningen.

Det beror på hur mycket assistenten ska kunna göra och hur många system den ska kopplas mot. En assistent som svarar på vanliga frågor utifrån befintligt innehåll går snabbare att sätta upp än en som ska boka tider eller hämta data från flera system. Tester av svarskvalitet tar också tid innan lansering.

De vanligaste orsakerna är sen leverans av material som texter och bilder, långsam återkoppling på designförslag samt ändringar i omfattning under projektets gång. Tekniska utmaningar i integrationer kan också ta längre tid än väntat om det underliggande systemet är dåligt dokumenterat. Tydlig kommunikation och snabba beslut från kundens sida minskar risken för förseningar avsevärt.

Ja, om ni har ett bestämt lanseringsdatum planerar vi arbetet därefter och prioriterar de funktioner som är viktigast för att kunna lansera i tid. Det kan innebära att vissa mindre kritiska funktioner byggs ut i en andra fas efter lansering. Vi är tydliga med vad som är rimligt att hinna innan ett givet datum.

Tiden beror på hur komplext dataflödet är och hur väl dokumenterat det befintliga systemets API är. En enklare integration som skickar order eller fakturaunderlag tar kortare tid än en tvåvägsintegration som synkar lager, kunder och priser löpande. Vi gör en bedömning efter att ha granskat era system.

Om material saknas kan det förskjuta tidsplanen, eftersom design och innehåll ofta hänger ihop. Vi kan i vissa fall hjälpa till att ta fram platshållartexter eller strukturera innehållet tillsammans med er för att inte projektet ska stanna helt. Det är dock bättre för slutresultatet om det faktiska innehållet finns med tidigt i processen.

Det beror på projektets storlek. Mindre projekt levereras ofta i ett svep vid en lansering, medan större projekt delas upp i etapper där grundfunktionaliteten lanseras först och ytterligare funktioner byggs ut löpande. Ett etappvis upplägg gör det möjligt att komma live snabbare och samla erfarenhet innan resten byggs.

Vi kartlägger varje integration för sig och identifierar vilka som är mest komplexa eller beroende av externa parter, exempelvis en leverantör av ett affärssystem. Integrationer som kräver tillgång eller information från tredje part läggs in tidigt i planen eftersom väntetider där är svårast att kontrollera. Resten av tidsplanen byggs sedan runt dessa beroenden.

Ja, det är ett vanligt och ofta klokt upplägg. Vi bygger då grundstrukturen så att fler språk och marknader kan läggas till utan att bygga om hela lösningen. En stegvis lansering minskar risken och gör att ni kan justera innan ni skalar upp till fler marknader.

Tiden styrs av hur många valbara alternativ som finns och hur de påverkar varandra i pris och tillgänglighet. En konfigurator med få, oberoende val tar kortare tid att bygga och testa än en med många kombinationer och regler. Noggrann testning av logiken är ofta den del som tar mest tid.

Efter utveckling återstår testning, granskning tillsammans med er samt eventuella justeringar innan lansering. Vi kontrollerar även att integrationer, formulär och betalflöden fungerar korrekt i skarp miljö innan webbplatsen går live. Denna fas är viktig för att undvika problem direkt efter lansering.

Ja, förändringar i vilka funktioner som ska ingå påverkar normalt tidsplanen, särskilt om ändringen berör grundstrukturen i lösningen. Vi informerar alltid om konsekvenserna för tidsplanen innan en ändring genomförs. Mindre justeringar sent i projektet kan ofta hanteras utan större påverkan.

Det beror på hur många tjänster eller resurser som ska kunna bokas och om systemet ska kopplas mot betalning, kalendrar eller notifieringar via mejl och sms. Ett bokningsflöde med enkel struktur tar kortare tid att bygga och testa än ett med flera parallella resurser och regler. Vi ger en tidsplan efter att ha kartlagt bokningsprocessen.

Vi bygger in viss marginal i planeringen för att hantera tekniska överraskningar, särskilt vid integrationer mot system vi inte styr själva. Om ett problem ändå riskerar att påverka tidsplanen informerar vi er så tidigt som möjligt och föreslår alternativa lösningar. Transparens kring förseningar är viktigare för oss än att dölja dem till sista minuten.