Krav til et transportstyringssystem: Veiledning for 2026
En praktisk sjekkliste over krav til transportstyringssystem for transportører, med dekning av planlegging, POD, integrasjoner, KPI-er og RFP-spørsmål.
Kontrolltavlen er full, kaiavtalen flytter på seg, og økonomi spør hvorfor forrige ukes fullførte oppdrag fortsatt ikke er fakturert. En sjåfør har sendt en leveringsbekreftelse via en meldingsapp, en annen POD ligger i en lastebil, og ingen kan bekrefte om free-time-klokken på en container har utløpt. Dette er den operative virkeligheten bak krav til transportstyringssystem. En lang funksjonsliste løser ikke dette. Det riktige systemet må knytte planlegging, utførelse, containerstatus, proof of delivery, fakturering, compliance og prestasjonsdata sammen i én brukbar arbeidsflyt.
Markedet beveger seg i den retningen. En referanse anslår det globale markedet for transportstyringssystem til USD 18.50 billion in 2025, med en prognose på USD 37.04 billion by 2030, tilsvarende en 14.9% CAGR from 2025 to 2030 (market benchmark for transportation management software). For mellomstore transportører og containeroperatører er dette mindre viktig som markedsoverskrift enn som kjøpssignal. TMS-programvare blir operativ infrastruktur, ikke et penere dispatch-regneark.
Table of Contents
Why Most TMS Requirement Lists Miss the Real Buyer Problem
Den vanligste scoping-feilen er å kopiere en enterprise-sjekkliste inn i et anskaffelsesløp for mellommarkedet. Listen inneholder multimodal optimalisering, transportøranskaffelse, control-tower-dashbord, prediktiv analyse og alle integrasjoner leverandøren noen gang har bygget. Samtidig må dispatcher fortsatt registrere jobber på nytt fra e-post, sjåfører mangler adgangsnotater, og økonomi venter på signerte POD-er.
Et krav betyr bare noe hvis det endrer en beslutning eller fjerner en flaskehals. Det nyttige spørsmålet er ikke «Har plattformen synlighet?», men «Kan dispatcher identifisere hver jobb som står i fare for å miste en terminalavtale, se hvem som eier neste handling, og varsle kunden før feilen blir et krav?»
Start with operational evidence
Utfør tre diagnoser før du snakker med leverandører.
Gå gjennom de siste 30 dagene med avvik. Se på sene hentinger, bommede leveringsvinduer, manglende POD-er, fakturadisputter, dupliserte jobber, feil i kjøretøytilgjengelighet, detention-eksponering og manuelle kundeoppdateringer. Ikke stol på ledelsesoppsummeringer. Sammenlign dispatch-tavlen, sjåførmeldinger, leveringsdokumenter og økonomiregistre.
Knytt en forretningskonsekvens til hvert gap. En manglende POD kan forsinke fakturering, skape en tvist eller tvinge ansatte til å purre på mottaker. En tapt terminalslot kan gi ventetid, omplanlegging og misfornøyde kunder. Du trenger ikke et konstruert spareestimat. Du må derimot identifisere hvilken feil som bruker kontanter, kapasitet eller ledelsesoppmerksomhet.
Prioriter krav etter effekt på kontantstrømmen. Legg POD-innhenting, validering av jobbføring, fakturaklargjøring og oppgjørskontroller høyt hvis sene dokumenter bremser innkreving. Legg avansert optimalisering lavere hvis planleggerne allerede kan lage brukbare ruter, men ikke får lukket fullførte jobber ryddig.
Praktisk regel: Et krav hører hjemme i RFP-en bare når kjøperen kan navngi den operative beslutningen det forbedrer, brukeren som trenger det, og beviset som viser at det virket.
Bransjeveiledning gir fortsatt et nyttig minimum. Gartners TMS-kriterier dekker planlegging, fraktkilder og anskaffelse, synlighet, utførelse og analyse, inkludert ordreinntak, konsolidering, valg av transportmåte og rute, transportørvalg, kommunikasjon og KPI-måling (industry coverage of Gartner's TMS criteria). Bruk disse kategoriene som et gulv, og legg deretter til de kontant- og containerkontrollene som generiske maler ofte overser.
Krav er ikke en ønskeliste. De er beslutninger om hva driften må kunne gjøre pålitelig på en travel dag.
Core Functional Modules a Mid-Market TMS Must Cover
En dispatcher opplever et TMS som en kjede av overleveringer. En ordre kommer inn, teamet validerer den, tildeler et kjøretøy, informerer sjåføren, følger fremdriften, samler leveringsbevis og frigir oppdraget for fakturering. Hvis ett trinn ligger utenfor systemet, gjenskaper ansatte den samme informasjonen andre steder.
The operational sequence
Ordreinntak bør ta imot strukturert data fra e-post, kundeportaler, API-er eller manuell registrering uten å skape duplikater. Systemet bør bevare referanser, adresser, krav, priser, leveringsvinduer og dokumentvedlegg.
Planlegging trenger en visuell jobbrute med filtrering på kjøretøy, sjåfør, kunde, status, terminal og avvik. En planlegger skal kunne omdisponere, tildele på nytt og masse-redigere jobber uten å åpne hver enkelt registrering. Hvis demoen bare fungerer med én ren jobb, be leverandøren demonstrere et forsinket kjøretøy, en avlyst slot og en endring som påvirker flere jobber.
Sjåførbrief må legge de praktiske instruksjonene der sjåføren kan bruke dem. Det inkluderer ruteinformasjon, hente- og leveringsreferanser, adgangsbegrensninger, kontaktinformasjon, tidskrav og container- eller forseglingsinformasjon der det er relevant. En sjåførapp som svikter uten stabil forbindelse er en produksjonsrisiko, så test offline-oppførsel i stedet for å akseptere en muntlig forsikring.
Utførelsesoppfølging bør vise planlagte versus faktiske milepæler, gjeldende status, ETA, årsak til forsinkelse og ansvarlig bruker. Sporing er ikke nyttig hvis den bare produserer et kart uten en avviks-kø.
POD-innhenting ligger direkte i kontantkonverteringsløpet. Sjåføren bør sende inn et lesbart dokument eller en digital POD fra mobilflyten, med tidsstempler og vedlegg knyttet til riktig jobb. Sett en intern standard for rask innsendelse, og mål den. Kjøperen bør ikke nøye seg med «sjåfører kan laste opp dokumenter» som fullt svar.
Fakturering bør identifisere fullførte jobber med POD-støtte og flagge manglende referanser, avvikende kvanta, prisavvik eller uløste avvik før en faktura når kunden. Oppgjør bør avstemme forventede og faktiske kostnader, støtte godkjenninger og bevare en revisjonsspor.
| Module |
Minimum Acceptable Behavior |
Failure Mode if Missing |
| Order intake |
Capture structured job data and attachments without duplicate entry |
Re-keying, missing references, duplicate jobs |
| Planning board |
Filter, reassign, reschedule, and bulk-edit live jobs |
Planners work from stale spreadsheets |
| Driver briefing |
Deliver route, access, timing, and reference notes on mobile |
Missed instructions and avoidable calls |
| Execution |
Record milestones, ETA, delays, and owners |
Problems surface only after a complaint |
| POD capture |
Tie images or digital records to the correct completed job |
Billing waits while documents are chased |
| Invoicing |
Release supported jobs and flag exceptions |
Incorrect invoices and debtor disputes |
| Settlement |
Compare planned charges with actual costs |
Margin leakage and manual reconciliation |
Bruk denne oversikten over moduler i et transportstyringssystem for å teste om en leverandørs terminologi faktisk samsvarer med reelle arbeidsflyter. Den viktige forskjellen er mellom en modul som finnes i menyen, og en arbeidsflyt som overlever en krevende driftsdag.
Container-Specific Requirements Beyond Generic Haulage
En sjekkliste for pallgods behandler en bevegelse som et opphav, en destinasjon, et kjøretøy og en leveringshendelse. Containeroperatører håndterer et annet operativt objekt. Oppdraget kan avhenge av bookingreferanse, release order, terminalavtale, containernummer, ISO-kode, portstatus og en free-time-frist.
Et generisk TMS registrerer ofte havnen som enda et stopp. Det er ikke tilstrekkelig. Et terminalbesøk er en slot-avhengig hendelse, og konsekvensene av forsinkelse kan fortsette etter at lastebilen har forlatt området. Systemet må skille mellom et haulage order og et release order, bevare bookingreferansen og vise den eksakte containeren som er knyttet til flyttingen.
Minimum container data model
På jobbnivå bør du kreve felter for:
- Booking number, slik at flyttingen kan matches mot kunden eller shipping-instruksjonen.
- Container number and ISO container code, slik at den fysiske enheten og typen er entydig.
- Terminal or quay, inkludert relevant hente- eller leveringssted.
- Free-time expiry, med synlig status og ansvar for neste handling.
- Release type, slik at dispatch forstår om flyttingen avhenger av release, booking, interchange eller annen autorisasjon.
- Slot appointment details, inkludert planlagt tid, bekreftelsesreferanse og endringshistorikk.
- Live ETA to the terminal, slik at teamet kan gripe inn før en slot går tapt.
Demurrage- og detention-sporing bør ikke være gjemt i et notatfelt. Systemet bør vise klokken, knytte den til containeren og jobben, og generere et avvik når fristen nærmer seg eller operativ data er ufullstendig.
| Requirement Area |
Generic Haulage Assumption |
Container-Specific Need |
| Job identity |
Customer order and delivery reference |
Booking, release, container, and haulage references |
| Vehicle movement |
Pickup and delivery milestones |
Terminal slot, gate event, interchange, and quay status |
| Freight detail |
Goods, quantity, packaging |
ISO code, container number, seal, and release type |
| Time control |
Delivery window |
Free-time expiry plus detention and demurrage exposure |
| Visibility |
Vehicle or shipment location |
ETA to terminal and status across port-related events |
| Exception handling |
Late pickup or delivery |
Missed slot, unavailable release, gate rejection, or clock risk |
En containeroperatør bør avvise enhver plattform som ikke kan vise disse feltene i dispatcherens arbeidsvisning. guiden om container transport software architecture gir nyttig kontekst for å vurdere container-spesifikke arbeidsflyter, men den endelige testen er operativ. Gi leverandøren en reell booking, en endret terminalslot og en free-time-frist. Be teamet håndtere avviket uten å opprette et side-regneark.
Integrations and Data Exchange That Operators Actually Rely On
Integrasjonsdiskusjoner blir ofte til arkitekturteater. Leverandører snakker om API-er og tilkobling, mens kjøperen glemmer å spørre hvem som eier dataene, hvor ofte de flyttes, og hva som skjer når feeden stopper.
Bruk tre nivåer. Det første beskytter økonomi, det andre beskytter dispatch, og det tredje beskytter terminalutførelse.
Tier one protects the invoice
ERP- og regnskapstilkoblinger omfatter Sage, Xero, QuickBooks, SAP Business One og Microsoft Dynamics 365 Business Central. Økonomi eier vanligvis masterdataene, inkludert kunder, avgiftsinnstillinger, kontokoder, priser og debitorstatus. Integrasjonen bør bruke et dokumentert REST API, en godkjent connector eller sikker filutveksling, med planlagte eller hendelsesstyrte oppdateringer.
Minst må dere utveksle kunde- og jobbreferanser, fakturalinjer, avgiftsdata, valuta der det er relevant, kreditstatus, betalingsstatus og avregningsjusteringer. Uten denne forbindelsen må ansatte registrere fakturaer på nytt, og økonomi sliter med å avstemme debitorsaldoer.
Tier two protects the daily plan
Telematikk- og sjåførsystemer som Webfleet, Microlise, Trimble og Geotab leverer operative data. Driftsavdelingen eier den operative tolkningen, selv om telematikkleverandøren kontrollerer kildesystemet. Bruk REST API-er, webhooks eller sikre filer, med hyppige oppdateringer tilpasset hendelsen. Minste datasett bør omfatte kjøretøyidentitet, sjåføridentitet, posisjon, tidsstempel, tenning eller bevegelsesstatus, ETA-input og relevante varsler om sjåfør eller kjøretøy.
Kunde- og 3PL-portaler bør utveksle ordreskaping, statusmilepæler, ETA, årsak til avvik, POD-tilgjengelighet og referansenummer via REST eller SFTP. Hvis feeden svikter, bør ikke dispatcher gå tilbake til telefonsamtaler og spredte meldinger.
Tier three protects terminal execution
Port- og EDI-systemer kan omfatte Portbase, Cargo Community System, EDIFACT IFTMIN, PortNet og API-er for terminalavtaler. Den eksterne havnen eller terminalen eier ofte dataene. Spør konkret om TMS-et støtter nødvendig meldingsformat, kvitteringshåndtering, synlighet for feil og oppdateringer av slot-status.
| Tier |
Integration Group |
Typical Systems |
Data Owner |
Protocol / Cadence |
Failure Mode if Missing |
| One |
ERP and accounting |
Sage, Xero, QuickBooks, SAP Business One, Business Central |
Finance |
REST, connector, or SFTP, scheduled or event-driven |
Duplicate rekeying and unreconciled balances |
| Two |
Telematics and driver apps |
Webfleet, Microlise, Trimble, Geotab |
Operations and fleet |
REST or webhook, frequent event updates |
Dispatch falls back to calls |
| Two |
Customer and 3PL portals |
Customer platforms and partner portals |
Operations or customer |
REST or SFTP, order and milestone events |
Manual status updates and document chasing |
| Three |
Port and EDI systems |
Portbase, Cargo Community System, PortNet, terminal APIs |
External terminal or port |
EDI, API, or secure file exchange, event-based |
Manual slot booking and opaque port status |
Det farlige gapet er et TMS som integrerer med økonomi, men ikke har praktisk porttilkobling. For en containeroperatør kan det etterlate den mest tidskritiske delen av oppdraget utenfor systemet.
Security, Compliance and Road-Safety Evidence
En sikkerhetsslide fra leverandøren er ikke bevis. Anskaffelsen trenger dokumenter, systemtilgang og kontraktsforpliktelser som tåler en kunderevisjon eller myndighetsinspeksjon.
Krev et gyldig ISO 27001 certificate covering the specific TMS service, ikke bare leverandørens morselskap. Be om en publisert SOC 2 Type II-rapport eller tilsvarende assurance, GDPR-tilpassede behandlingsvilkår, hostingsdetaljer relevante for organisasjonen din og en tydelig policy for datalagring. Kontrakten bør også dekke underdatabehandlere, varslingsplikt ved brudd, dataeksport og sletting.
Evidence the operation can retrieve
Rollebasert tilgang bør skille mellom dispatch, sjåfører, økonomi, kunder, administratorer og underleverandører. MFA, kryptering under overføring og i ro, uforanderlige revisjonsspor og kontrollert administratortilgang er grunnleggende kontroller. Be om å se hvordan systemet logger endringer i priser, POD-er, leveringsstatus, fakturaer og brukerrettigheter.
For operatører som påvirkes av EU Mobility Package, bekreft hvordan tachograph- og førertidsdata importeres, lastes ned, lagres og fremlegges under inspeksjon. Et TMS erstatter ikke spesialiserte compliance-systemer automatisk. Det må vise nøyaktig hvilke data det håndterer og hvor et annet system fortsatt er autoritativt.
ISO 39001 definerer krav til road traffic safety management systems og er en nyttig referanse for repeterbare, revisjonsbare sikkerhetsprosesser (ISO's transport sector guidance). Et TMS kan støtte dette beviset gjennom registrering av sjåføratferd, hendelseslogger, opplæringsstatus, underleverandørkvalifisering, kjøretøykontroller og koblinger mellom sikkerhetskontroller og tildelt arbeid.
En praktisk ressurs om forsyningskjede-compliance kan hjelpe med å strukturere det bredere kontrollrammeverket. Under leverandørevalueringen bør du be hver leverandør demonstrere henting av bevis live. Hvis det å produsere et revisjonsspor krever en supportsak, er kontrollen ikke operativt moden.
Deployment, Onboarding and Total Cost of Ownership
I 2026 bør enkel implementering og tydelig prisinformasjon være grunnkrav, ikke spesielle innrømmelser for mindre operatører. En mellomstor transportør bør ikke akseptere et langt transformasjonsprogram bare fordi leverandøren tilbyr flere skjermer enn virksomheten kan bruke.
Krev en navngitt onboarding-leder, en skriftlig scope og en fast go-live-plan for kjerneflyten fra planlegging til faktura. Leverandøren bør tilby en sandbox-tenant for parallellkjøring, dokumenterte importmaler, rollebasert opplæring og en prosess for håndtering av feil etter oppstart. Spør hva kunden selv må levere, fordi skjult internt arbeid fortsatt er en del av prosjektkostnaden.
Build the real cost model
Prissett systemet over en treårsperiode. Ta med lisensiering, integrasjonsarbeid, datamigrering, opplæring, intern prosjekttid, supportnivåer, enhets- eller tilkoblingskostnader der det er relevant, og alternativkostnaden ved forsinket fakturering.
| Cost Line |
Year 1 |
Year 2 |
Year 3 |
Notes |
| Software licence |
Quoted amount |
Quoted renewal |
Quoted renewal |
State whether pricing is per vehicle, driver, job, or user |
| Implementation |
One-time amount |
None or change requests |
None or change requests |
Require a fixed scope and cap |
| Integrations |
Build and setup |
Maintenance |
Maintenance |
Separate native connectors from custom work |
| Training |
Initial delivery |
Refresher or new-user training |
Refresher or new-user training |
State what is included |
| Support |
Support tier |
Support tier |
Support tier |
Define response times and escalation |
| Internal time |
Staff allocation |
Change management |
Change management |
Include finance and driver adoption work |
| Exit and migration |
Contracted service |
Contracted service |
Contracted service |
Define export format and assistance |
Røde flagg inkluderer minimumsforpliktelser lengre enn 24 months, avgifter per API-kall og onboarding fakturert med ubegrensede dagsatser. Leverandører bør forklare alle variable kostnader før signering. En billig lisens med dyr integrasjon er ikke et billig TMS.
KPIs, SLAs and the POD-to-Invoice Performance Loop
Et dashbord fullt av målinger kan fortsatt gjøre kontantløpet usynlig. Definer hver KPI som en operativ beregning med eier, kilde, avviksregel og konsekvens.
On-time delivery trenger et navngitt avtalevindu. «On time» bør bety at faktisk ankomst eller fullføring skjer innenfor det avtalte vinduet, ikke bare at sjåføren nådde området i nærheten.
POD turnaround bør måle tiden fra levering fullført til skanning eller digital opplasting. Bruk medianen, ikke et selektivt rapportert best case, og segmenter resultatet på sjåfør, kunde, type oppdrag og underleverandør.
Invoice-to-cash bør måle perioden fra akseptert POD og fakturafrigivelse til kundebetaling. Dette knytter dispatch-adferd til økonomiske resultater. En POD som kommer sent, er ikke bare et dokumentproblem. Den utsetter tidspunktet da virksomheten trygt kan fakturere.
Et praktisk drifts-eksempel kan sette 95% on-time delivery within a 60-minute window, POD median under 4 hours og DSO under 38 days. Disse tallene er eksempler på KPI-definisjoner, ikke universelle benchmarker. TMS-et må vise hvordan hvert resultat beregnes, hvem som leverer dataene, og hva som skjer når leverandørens tjeneste ikke når avtalt terskel.
| KPI |
Definition |
Target |
Data Source |
SLA Response |
| On-time delivery |
Completion inside the named appointment window |
95% within a 60-minute window |
TMS milestone and appointment data |
Root-cause review and service credit if vendor data is unavailable |
| POD turnaround |
Median hours from delivery completion to uploaded POD |
Under 4 hours |
Driver app and POD timestamp |
Escalation for failed mobile workflow |
| Invoice readiness |
Completed jobs with required references and POD attached |
Define during contracting |
TMS job, POD, and billing records |
Correction plan for workflow defects |
| Invoice-to-cash |
Days from POD acceptance and invoice release to payment |
DSO under 38 days |
TMS and accounting system |
Finance review of disputes and integration failures |
For bredere flåtekontroller kan 2025 fleet safety and compliance tips supplere kravene til road safety ovenfor. Hold målesløyfen lukket: leveringshendelse, POD-aksept, fakturafrigivelse, tviststatus og betalingsutfall skal kunne spores til samme jobb.
Sample RFP Language and Vendor Evaluation Questions
En god RFP tvinger leverandøren til å beskrive oppførsel under press. Bytt ut «provides real-time visibility» med en testbar klausul: «Leverandøren må vise planlagte og faktiske milepæler, gjeldende avvikstatus og tidspunkt og kilde for hver oppdatering for hver aktiv jobb.»
Copy-ready clauses
- Data ownership: «All operativ, kunde-, jobb-, POD-, faktura-, revisjons- og konfigurasjonsdata som opprettes av kjøperen, forblir kjøperens eiendom og må kunne eksporteres i et dokumentert og brukbart format.»
- Audit access: «Kjøperen må kunne hente bruker-, status-, pris-, POD-, faktura- og rettighetsendringer med tidsstempler og identitet på aktøren.»
- Integration service level: «Kritiske integrasjoner må ha en avtalt tilgjengelighetsmålsetting, overvåking, hendelsesvarsling og gjenopprettingsprosess.»
- POD retention: «POD-bilder og tilhørende metadata må kunne hentes gjennom kjøperens avtalte oppbevaringsperiode og kunne eksporteres ved terminering.»
- Exit assistance: «Leverandøren må tilby dokumentert eksport, overgangsstøtte og rimelig samarbeid med en erstatningsleverandør.»
Thirty questions that force useful answers
- Can the system capture orders from our required channels?
- Can planners filter the live jobs grid by vehicle, driver, customer, status, and exception?
- Can users bulk-edit or reassign jobs?
- Can the system preserve a full change history?
- Can drivers receive route, access, and reference instructions on mobile?
- Does the driver workflow operate when connectivity is unavailable?
- Can the system record planned and actual milestones?
- Can it flag jobs at risk before the appointment window is missed?
- Can drivers upload PODs directly against the correct job?
- Can finance see which jobs are invoice-ready?
- Can the system block or flag invoices with missing PODs or references?
- Can it reconcile expected and actual transport charges?
- Can it capture booking, release, container, terminal, and ISO code data?
- Can it display free-time expiry and detention or demurrage risk?
- Can it record terminal slot bookings and changes?
- Can it calculate or receive live ETA to the terminal?
- Which ERP and accounting systems have supported connectors?
- Which REST, webhook, SFTP, or EDI interfaces are available?
- Which party owns each exchanged data field?
- What happens when an integration fails?
- Can users see rejected messages and retry them?
- Can the system exchange POD and status data with customer portals?
- Does the service have ISO 27001 coverage for the TMS itself?
- Is a SOC 2 Type II report or equivalent available?
- How are MFA, encryption, roles, and audit logs implemented?
- How are driver-hours and tachograph workflows supported?
- Can the vendor show safety and subcontractor evidence retrieval?
- Who owns onboarding, and what is included in the fixed scope?
- Is there a sandbox for parallel running and user acceptance testing?
- What are the licence, integration, support, renewal, API, exit, and termination charges?
Vekt scorekortet mot on-time performance, POD turnaround, invoice readiness, container status control og ERP integration. Nice-to-have-analyse bør ikke overstyre arbeidsflytene som holder lastebiler i bevegelse og fakturaer forsvarlige.
Mapping the Requirements to Logivo as a Worked Example
En praktisk vurdering av Logivo bør starte med det publiserte operative omfanget, ikke med et salgsutsagn. Transportstyringsplattformen dekker jobopprettelse, tildeling, oppfølging av utførelse, sjåførbrief, digital POD-innhenting og fakturering i en sammenhengende arbeidsflyt. Den inkluderer også container-haulage-arbeidsflyter og praktisk AI-støtte for dokument- og dataregistreringsoppgaver.
| Requirement Area |
Fit |
Notes |
| Functional modules |
Meets core scope |
Validate bulk editing, exception ownership, and offline driver behavior |
| Container specifics |
Relevant coverage |
Confirm the exact booking, release, terminal, and free-time fields required |
| Integrations |
Requires validation |
Confirm native ERP, telematics, portal, API, SFTP, and port connectivity |
| Security |
Contract and evidence check |
Request service-specific certifications, audit controls, retention, and processing terms |
| Deployment |
Designed for lower setup overhead |
Confirm scope, timeline, migration duties, training, and change-request pricing |
| KPIs |
Configurable starting point |
Test calculation logic for milestones, POD turnaround, invoice readiness, and cash data |
| RFP readiness |
Suitable for structured evaluation |
Require measurable answers and written commitments rather than feature descriptions |
En mellomstor transportør bør fortsatt validere tre områder før signering: den eksakte containerstatusmodellen, regnskapsintegrasjonen og avstemmingsprosessen, samt oppførselen til mobilflyten ved dårlig dekning. Se på denne tabellen som en startvurdering, ikke en erstatning for live prosess-testing.
Quick-Reference Checklist, Glossary and FAQ
Gi denne sjekklisten til driftsleder, økonomidirektør og dispatcher. Hvert spørsmål bør få et tydelig ja eller nei under en leverandørdemonstrasjon.
Buyer checklist
- Functional core: Kan systemet opprette, planlegge, tildele, brief’e, følge opp, fullføre og fakturere jobber i én arbeidsflyt?
- Jobs grid: Kan brukere filtrere, masse-redigere, tildele på nytt og identifisere avvik uten å åpne hver jobb?
- POD: Kan sjåfører sende inn signert eller digitalt bevis direkte mot jobben?
- Invoice control: Kan økonomi identifisere fakturaklare jobber og manglende dokumenter?
- Container control: Kan systemet lagre booking number, container number, terminal, release type, slot og free-time expiry?
- Terminal visibility: Kan dispatch se ETA og portrelaterte avvik i samme operative visning?
- ERP integration: Kan kunde-, pris-, faktura-, avgifts-, betalings- og justeringsdata flyttes uten dobbel registrering?
- Driver and telematics data: Kan systemet motta data om kjøretøy, sjåfør, posisjon, tidsstempel og milepæler?
- Port exchange: Kan det støtte nødvendig API, SFTP, EDI eller avtaleprosess?
- Security: Leverer leverandøren service-spesifikk sertifisering, MFA, kryptering, rollekontroller og revisjonsspor?
- Compliance: Kan teamet hente sjåfør-, hendelses-, underleverandør- og dokumentbevis?
- Deployment: Finnes det en navngitt onboarding-leder, fast scope, sandbox, migreringsplan og opplæringsplan?
- Commercials: Er lisensiering, integrasjoner, support, API-bruk, onboarding, fornyelse og exit-kostnader spesifisert?
- KPIs: Er definisjonene for on-time delivery, POD turnaround, invoice readiness og invoice-to-cash nedskrevet?
- RFP protection: Dekker kontrakten og SLA dataeierskap, tilgjengelighet, revisjonstilgang, oppbevaring og overgangsstøtte?
Plain-English glossary
TMS: Programvare som håndterer transportplanlegging, dispatch, utførelse, synlighet, dokumenter, fakturering og oppgjør.
POD: Proof of delivery, som et signert leveringsnotat, digital bekreftelse, tidsstempel eller tilhørende leveringspost.
EDI 204 and 214: Vanlige elektroniske meldinger som brukes til å kommunisere transporttildelinger og hendelser for forsendelsesstatus. Bekreft nøyaktige meldingsformater kundene dine krever.
ISO 39001: En standard for road traffic safety management systems, nyttig for strukturerte sikkerhetskontroller og revisjonsbart bevis.
SOC 2: En uavhengig assurance-rapport om kontroller som er relevante for sikkerhet og tilhørende tjenesteforpliktelser.
Telematics: Data om kjøretøy og sjåfør, inkludert posisjon, bevegelse og utvalgte operative signaler.
Slot booking: En planlagt avtale for at et kjøretøy skal få adgang til en terminal, depot, lager eller annen kapasitetssensitiv lokasjon.
Detention: En kostnad eller eksponering knyttet til å holde utstyr utenfor tillatt periode. Demurrage gjelder vanligvis utstyr eller last som blir i en terminal utover tillatt periode. Kontraktsdefinisjoner varierer, så konfigurer systemet i tråd med gjeldende vilkår.
Frequently asked questions
How long does a typical mid-market rollout take?
Svaret avhenger av datakvalitet, integrasjoner, prosessvariasjon og brukerberedskap. For kjerneflyten fra planlegging til faktura bør du kreve at leverandøren foreslår en fast, evidensbasert go-live-plan i stedet for en åpen implementering.
What's the smallest viable scope for a 20-truck fleet?
Start med ordreinntak, jobbrute, dispatch, sjåførbrief, utførelsesmilepæler, POD-innhenting, fakturaklargjøring og regnskapsintegrasjon. Legg til avansert optimalisering og bredere portaltilkobling etter at kjerneflyten er stabil.
How do we avoid scope creep during onboarding?
Skriv minimum viable process inn i avtalen. Navngi nødvendige felter, integrasjoner, brukere, rapporter, akseptansetester og opplæringsleveranser. Legg alle ekstra forespørsler inn i en priset endringskontrollprosess.
When does building versus buying make sense?
Bygg bare når driftsmodellen deres er særpreget og dere kan finansiere langsiktig eierskap, support, sikkerhet, integrasjoner og oppgraderinger. Kjøp når prosessen er generell nok til å bruke beprøvde arbeidsflyter, men krev konfigurasjon og datatilgang i stedet for dyr spesialutvikling.
Logivo tilbyr en samlet arbeidsflyt for transportører og containeroperatører for å planlegge jobber, brief’e sjåfører, fange digitale POD-er, håndtere containerrelatert arbeid og koble fullførte jobber til fakturering. Besøk Logivo for å sammenligne arbeidsflyten mot din RFP, og test deretter de tre områdene som betyr mest i driften din: POD-turnaround, regnskapsintegrasjon og kontroll av containerstatus.