Bästa uthyrningsprogrammet för små och växande uthyrningsföretag

De flesta uthyrningsföretag börjar på samma sätt, oavsett vad de hyr ut: en delad kalender eller ett kalkylblad för bokningar, en pappersleveranssedel eller två, och en WhatsApp-grupp med den som kör den dagen. Det finns inget att skämmas för - det är helt enkelt rimligt för stadiet företaget befinner sig i. Under det första året eller två motiverar volymen verkligen inget mer avancerat, och ett kalkylblad som grundaren själv byggt är ofta snabbare att uppdatera än vilket färdigt system som helst.

Frågan som verkligen spelar roll för ett litet eller växande uthyrningsföretag är inte "när behöver jag riktigt program" - många driver bekvämt vidare på ett kalkylblad i flera år. Den mer användbara frågan är vad man faktiskt ska leta efter när kalkylbladet börjar krångla, så att det som ersätter det inte behöver ersättas igen arton månader senare. Det är vad den här artikeln handlar om: en praktisk checklista, inte ett argument för att alla företag behöver samma verktyg från dag ett.

Tre tecken brukar dyka upp, ungefär i den här ordningen. Det första är dubbelbokningar - två personer, eller samma person två gånger, lovar samma artikel till två olika kunder eftersom ingen av dem kunde se den andras ändring i tid. Det brukar börja som ett sällsynt, ursäktande telefonsamtal och blir en återkommande kostnad i återbetalningar, ersättningsutrustning och kunder som inte kommer tillbaka. Det tenderar också att koncentreras till de sämsta tänkbara tillfällena - en hektisk helg eller en säsongstopp, när antalet förfrågningar är som störst och det finns minst tid för någon att upptäcka en konflikt innan den redan har lovats till två personer.

Det andra tecknet är pappersarbete som försvinner precis vid fel tillfälle: en signerad leveranssedel som aldrig kom tillbaka till kontoret, en skadeanteckning klottrad på baksidan av en faktura och sedan förlorad, en deposition som ingen hittar en anteckning om. Inget av detta handlar om ohederlighet - det är helt enkelt så att papper och minne inte skalar särskilt bra bortom ett visst antal jobb i veckan, och ett företag som hanterar ett dussin jobb i veckan når det taket långt tidigare än väntat.

Det tredje tecknet, det som kostar mest utan att synas, är att förlora överblicken över vem som faktiskt är skyldig vad. När fakturering sker under lediga stunder mellan jobb i stället för i samband med bokningen, är det lätt att ett företag har tusentals kronor utestående som det inte hunnit fakturera för - inte för att kunderna inte vill betala, utan för att ingen har bett om det. Lägg till några ej återbetalda depositioner och några förlängda uthyrningar som aldrig fakturerats om, och gapet mellan vad kalkylbladet säger och vad som faktiskt är skyldigt kan bli betydande innan någon sätter sig ner och stämmer av allt ordentligt.

Som ett illustrativt exempel: föreställ dig ett tvåpersoners verktygsuthyrningsföretag som just nu sköter sina bokningar via en delad kalender och en pappersanteckningsbok vid kassan. Det fungerar, för det mesta - tills en hektisk lördag när båda delägarna tar emot en bokning på samma betongblandare inom loppet av tjugo minuter av varandra, och ingen av dem upptäcker det förrän en kund dyker upp för att hämta den. Multiplicera den enda lördagen med några månaders tyst missade fakturor och ett par depositioner som ingen krävt tillbaka, och argumentet för förändring handlar inte längre om bekvämlighet utan om pengar som faktiskt lämnas kvar på bordet.

Det första riktiga testet för ett litet team handlar inte om funktioner - det handlar om huruvida ett system tar bort arbete eller lägger till en ny hög av det. Ett verktyg som bara hanterar bokningar, och som ändå behöver en separat app för e-signaturer, ett separat faktureringsverktyg och ett separat sätt att ta emot depositioner, har inte egentligen löst problemet med ihoplappade verktyg. Det har bara lagt till en sjätte inloggning till högen.

Det här är ett av de områden där det är värt att titta på vad en verkligt sammanhållen plattform täcker, som ett användbart exempel på den nivå man bör sikta på snarare än som ett skäl att anta att en specifik produkt är det enda svaret. Renttix är ett verkligt exempel på det: offerter, avtal, e-signaturer, utkörning, betalningar, depositioner, fakturering och returer sker på en och samma plattform, i stället för att hanteras som fem separata prenumerationer som limmats ihop med kopiera-och-klistra-in. För ett tvåpersonersföretag är den skillnaden inte abstrakt - det är skillnaden mellan en inloggning att kolla en lördagsmorgon och fyra.

Små uthyrningsföretag har sällan enkel prissättning, även när allt annat hos dem är det. En betongblandare kanske prissätts per dag men med ett billigare helgpris; ett festtält kanske prissätts som en fast avgift per evenemang i stället för per timme; en generator kanske kräver minst tre dagars uthyrning för att det ska löna sig att lasta den på en skåpbil. Ingen av dessa komplexiteter försvinner bara för att ett företag är litet - om något har en liten aktör ofta ännu mindre tålamod med ett system som bara klarar ett enda faktureringsmönster.

Det är ett skäl att kontrollera, innan man skriver på för något, om det uthyrningssystem man överväger stöder dags-, timme-, vecko- och fastprisfakturering, kombinerade priser och minsta uthyrningsperioder som standard, i stället för något som skulle kräva skräddarsydd utveckling för att läggas till senare. Ett litet företag har ingen utvecklare anställd. Vilken faktureringsflexibilitet som än behövs måste redan finnas där.

En oproportionerligt stor del av ett litet uthyrningsteams dag går åt till frågor som egentligen inte behöver en människa för att besvaras: "har min deposition återbetalats", "kan ni skicka den fakturan igen", "vilken tid är leveransen". Ingen av dessa frågor är svåra - de är bara avbrott, och ett kontor med två eller tre personer absorberar avbrott mycket sämre än ett med tjugo, eftersom det inte finns någon att lämna över telefonen till.

En kundportal där kunder själva kan se sina beställningar, fakturor och dokument online tar inte bort behovet av bra service - den tar bort behovet av att en person manuellt svarar på frågor som egentligen bara är "låt mig kolla upp det åt dig". För ett litet team är det inte en trevlig extra bekvämlighet; det är skillnaden mellan att få en oavbruten timme att lasta en skåpbil och att bli avbruten var tionde minut.

Ett litet uthyrningsföretag har nästan säkert redan ett bokföringssystem, om än informellt, och det är mycket troligt en av ett fåtal vanliga plattformar - QuickBooks, Xero, Sage Business Cloud eller Zoho Books. Oavsett vilket uthyrningsprogram som införs måste det fungera tillsammans med det, inte ersätta det. Att för hand skriva in varje faktura på nytt i ett separat bokföringsprogram är precis den typ av manuellt steg som ett litet företag minst av allt har råd att bära, och det är också där siffror oftast blir tysta fel.

En plattform som Renttix, som synkroniserar med QuickBooks, Xero, Sage Business Cloud och Zoho Books, är ett bra exempel på vad man bör kontrollera: skickar uthyrningssystemet vidare data till den bokföringsprogramvara som redan används, eller förväntar det sig att ett företag byter bokförare och rutiner samtidigt som det byter bokningssystem. Det är en femminutersfråga värd att ställa innan man skriver på, eftersom den förhindrar månader av dubbelregistrering efteråt.

I ett litet uthyrningsföretag kan personen som svarar i kontorstelefonen på morgonen vara samma person som levererar och hämtar utrustning på eftermiddagen. Programvara vald utifrån antagandet om ett dedikerat kontorsteam och ett separat chaufförsteam passar inte den verkligheten - det skapar bara ett andra jobb: att i efterhand skriva in det som hände på plats i systemet, så fort någon äntligen är tillbaka vid ett skrivbord.

En fältapp som fångar signaturer, foton och GPS-position, och som fungerar offline när en arbetsplats saknar täckning, spelar större roll för ett sådant företag än för ett större med dedikerad utkörningspersonal, just eftersom det inte finns någon annan som gör pappersarbetet senare. Om samma person som lastar skåpbilen också måste vara den som bekräftar att en leverans skett, måste verktyget för det fungera stående på en uppfart, inte bara vid ett skrivbord.

Det ärliga svaret på "kommer det här fortfarande att fungera när jag lägger till ett andra depåkontor, en tredje skåpbil eller tjugo fler kunder i månaden" är att ingen kan lova att ett system fortfarande passar perfekt vid tio gånger storleken. Vad som är rimligt att förvänta sig är att systemet inte har ett hårt tak inbyggt från dag ett - att det inte är skräddarsytt för ett företag av exakt den storlek det har just nu och inte större. Det är en fråga värd att ställa två gånger, eftersom kostnaden för att välja fel inte visar sig förrän ett par år senare: inte bara priset på ny programvara, utan tiden som läggs på att på nytt mata in varje kund, varje pris och all utrustningshistorik från grunden i ett andra system, samtidigt som man fortfarande försöker driva verksamheten dag för dag.

Ett dokumenterat API, inget krav på dag ett

Ett dokumenterat API är en praktisk signal om just den typen av tillväxtutrymme. Ett litet företag behöver inte koppla samman andra system med sitt uthyrningsprogram på dag ett, och bör inte behandla ett API som ett omedelbart krav. Men ett växande företag kommer förr eller senare att vilja koppla samman något - en webbplats, ett rapporteringsverktyg, ett internt system som ännu inte byggts - och en plattform med ett dokumenterat REST-API innebär att den anslutningen blir möjlig senare utan att man behöver byta plattform bara för att få den.

Det är i grunden hela balansen mellan "överinvestera inte, underinvestera inte" samlad på en enda punkt. Ett litet uthyrningsföretag behöver inte rapportering i företagsskala, logistik för flera depåer eller ett dussin integrationer konfigurerade från dag ett - att köpa allt det i förväg innebär att spendera pengar och komplexitet på ett problem företaget ännu inte har. Men att välja något så grundläggande att det inte har någon väg vidare bortom var företaget står i dag garanterar bara att man måste göra om hela den här övningen om två år. Mellanvägen är en plattform som täcker vad ett litet team behöver nu - ett system i stället för fem, mindre telefonadministration, fungerande bokföringssynkronisering, en fältapp som fungerar på plats - utan att aktivt hindra företaget från att växa. Om det är till hjälp att se hur den balansen ser ut i praktiken kan ni boka en demo.