AV and Live Production Rental Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do rental software projects model inventory as a stock count?

Because that is what warehouse software does everywhere else, and most developers arriving in this sector have built ecommerce fulfilment. It fails immediately in rental, where the same item goes out, comes back, needs turnaround time, and is committed to three jobs across the same fortnight.

This is the biggest scope failure in the category because it is architectural rather than cosmetic. A system built on a stock count will keep telling you gear is available while it sits on a truck in another city, and no amount of later screen work fixes it. The related error is treating a package as a bundle that always moves together, which collapses the first time a comms case is part sub hired or a rack is broken to cover a shortage.

The fix is to insist on a timeline per asset before anything else is designed. Each asset has out, prep, show, return and service windows, and availability is computed across overlapping jobs against those windows rather than against show dates. Containers, serialised assets, bulk stock and consumables are modelled as different things because they behave differently, and a container can be partly pulled with the system knowing what is left in the case. Ask a prospective developer to whiteboard availability at the first meeting. If they draw quantity on hand, the rest of the conversation does not matter.

What goes wrong when you migrate the asset register?

The migration in this sector is not a data move, it is an inventory decision nobody has ever written down. What is a serialised asset with a service history. What is bulk stock counted in tens. What is a consumable that leaves and never returns. What belongs permanently in which case, and what merely travelled in it last month. In most houses that structure lives in the heads of two senior prep techs and in the physical arrangement of the shelves.

Two failures follow. The first is that a migration run against an existing spreadsheet inherits its errors and its ambiguity, so the new system launches with cable counts that were last accurate two seasons ago and packages that describe an old configuration. Crews stop trusting it within a fortnight and revert to paper, which is how these projects die.

The second is losing service and repair history. Lamp hours, fault records and repair dates are what tell you whether a fixture is due for attention, and if they arrive as a note field rather than as dated events you have thrown away your maintenance intelligence.

The fix is to treat inventory discovery as its own priced phase with a physical count behind it, rather than as a data import. Start with the top revenue kit categories and leave the long tail of clamps and adapters as bulk stock until the model has proved itself on gear that matters. Migrate service history as dated events with the asset serial attached, and where the history is unreliable, mark it as unverified rather than presenting it as fact.

Why do accounting, scanning and vendor integrations break after launch?

A rental house has fewer integrations than a bank and each one hurts more when it fails, because the failure lands in a prep bay at five in the morning.

Accounting is the most common. Xero, QuickBooks and Sage are three different jobs, not one, and the usual break is a chart of accounts change or a tax code change made by the bookkeeper without telling anyone, after which invoices post to the wrong place and nobody notices until the quarter. Barcode hardware is the second: a handheld that worked on the old warehouse wireless starts dropping scans after a network change, and scans that never arrive look exactly like items that were never pulled. Label stock fails in its own way, with labels that survive a demo and not a road case, so barcodes become unreadable on the flight cases that travel most.

Sub rental vendors are the least automatable of all, because the other house is a phone call and a person, and no integration changes that.

The fix is to design for the warehouse rather than the office. Handhelds should queue scans locally and sync when they can, so a wireless dropout slows a prep rather than losing it. Reconcile invoice totals between your system and the accounting package weekly and alert on any difference rather than trusting the posting. And accept that sub rental will be entered by a human, so make entering it take fifteen seconds on a phone, because anything slower will not happen under pressure.

What happens when sub rental and damage are not recorded against the job?

This is the gap where the money actually goes. Every busy house sub rents, and in peak season it can be a serious share of what leaves the building. It is arranged by phone under pressure, agreed at whatever price gets it there, and recorded weeks later as an invoice with a reference nobody can match to a job. The margin is invisible at the only moment it could be improved.

The reverse exposure is the same problem viewed from the other side. Your gear goes out on another house's paperwork with your serial numbers on it, and when it comes back damaged the claim depends entirely on what you can prove about its condition when it left. A fault found on return that never gets recorded is worse again, because the same faulty unit is pulled for the next show and fails on site in front of a client.

The fix is to make sub rental in and out first class transactions attached to the job, with vendor, agreed rate, expected return and the margin on the line visible while the deal is being made. Then make the prep floor produce evidence: scanning at pull, at truck load, at return and at check in, with a fault state that removes an asset from availability the moment it is flagged rather than when someone gets round to it, and photographs attached at check in so a damage charge carries proof rather than an argument. After one clean season you can finally see which recurring shortage costs more in sub rental than the equipment would cost to own, which is usually the business case for the whole project.

Should you build custom or configure what you already own?

Stay bought if you are a smaller house doing straightforward dry hire with limited kit list complexity. Current RMS is well built, quick to get running and costs a fraction of a custom project. Rentman is a sensible choice if crew scheduling is your dominant pain and your equipment side is simple. Flex Rental Solutions is the right buy if inventory complexity is the whole problem and your process is willing to bend to its shape.

Before building, be honest about configuration. Plenty of houses run a capable product with packages never properly defined, prep and turnaround windows never set, and reporting never built, then conclude it cannot do what it has never been asked to do.

Build when two or more of these are true. You are past roughly four million dollars in rental revenue with more than one show going out per day. Sub rental is a material line and you cannot see its margin per job. Your prep floor depends on two people who hold the knowledge of what belongs in each case. You transfer gear between depots and availability is a phone call. Or you have lost an account to a missing item and cannot explain in the debrief how the system said it was available.

How do hidden costs get into the quote?

Multiple warehouses first. Inter depot transfers effectively double the availability model, because an asset now has a location dimension and a transit window as well as a timeline. A quote written for one warehouse and delivered across three is a different project.

Radio frequency identification second. Gate reads are genuinely faster at scale and they are a hardware project, with tag placement on metal cases, read reliability and portal installation to work through. Prove the process with handheld barcode scanning first, then decide whether volume justifies a second project, rather than putting it in the first release because it demonstrated well.

Crew scheduling third. Staff, freelancers and agency crew carry different rates, availability rules and compliance requirements, and it is properly its own phase rather than a module you add to an equipment build.

Fourth is international freight and carnets, which need case dimensions and weights captured accurately first, so the data work precedes the feature. Fifth, and the usual schedule risk, is the inventory discovery described above. It is physical work in a warehouse that is also running shows, and it cannot be compressed by adding developers.

What separates a build that works from one that fails here?

The working build is trusted by the prep floor in the first month. That is the only test that matters, and it is won or lost on whether the system reflects how cases are actually packed. If a package cannot be part pulled, if a fault flag takes six clicks, or if a scan gun is slower than a pen, crews route around it and you are back on paper with a maintenance bill.

The second difference is that the load list and the pull sheet are recognised as different documents with different logic. Cases carry dimensions and weight, the load plan knows what fits, and the load order reflects the unload sequence on site, which the crew chief cares about more than anything else in the system. Scanning at truck load produces the manifest the site crew checks against, so a missing case is found in the yard rather than in the venue.

The third is job costing that closes. Every cost attaches as it is committed, including crew hours from the schedule, sub rental at the agreed rate, freight, consumables issued and any damage recharge, so a job closes with a real gross margin that rolls up per client across a season.

The fourth is ownership, in writing before kickoff: the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the code is yours from the first commit. Your asset register, service history and client pricing are the business, and none of it should sit somewhere you cannot take with you.