The State of Most Rental Websites Right Now
Walk through the websites of equipment hire companies across any sector, whether broadcast, pro audio, lighting, AV, medical devices, or any other technical rental sector and the pattern is almost universal. The website is a static catalogue. It shows what the business might have. It does not show whether any of it is available. It cannot take a booking. It cannot process a payment. It exists to present the company and prompt an enquiry.
Behind that website, there is almost always a rental management system. That system holds the live product data, the asset records, the availability calendar and the order book. But it is a separate system. The website is not connected to it in any meaningful way. The product descriptions on the website may have been copied from a manufacturer’s website months or years ago. They may not have been updated since.
This means the business is maintaining two separate product catalogues. Every new product added to the rental system needs to be added to the website separately. Every product retired from the fleet should be removed from the website, though it often is not. The website is a snapshot of the business at a point in time, not a live representation of what is actually available today.
The customer visiting that website does not know any of this. They see a product they want. They submit an enquiry. They wait. They are inconvenienced from the outset.
Why the Rental Management Software Market Created This Problem
The static catalogue is not an accident. It is the natural consequence of how rental management software developed.
The major rental management platforms, for example Current RMS (now OnRent Events), Rentman, InspHire and their equivalents, were built primarily as back-office operational tools. Their purpose was to manage the internal complexity of running a rental business: equipment tracking, order management, warehouse operations, crew scheduling, quoting and invoicing. They are, in the main, good at this. The problem is that being strong on back-office management and providing a customer-facing eCommerce channel are different engineering problems, and most platforms were built to solve only the first one.
Current RMS customers have described the situation clearly in public reviews: the software requires them to maintain a separate website that accepts equipment orders, then manually transfer each order into the rental management system. One reviewer described compensating for “the lack of pretty key features like payment integration and online booking with lots of hours of extra admin.” This is the structural consequence of a system designed for back-office management being used in a world where customers expect to transact online.
Rentman has moved further toward customer self-service in recent iterations, describing a flow where customers can book and pay online. But its primary market is AV and event production, where the majority of jobs are complex enough to require a quoting workflow regardless. The online booking layer is an API, sitting on top of a system whose architecture is organised around projects, crew and event logistics rather than around professional and consumer customer-facing journeys with live availability and checkout.
Quipli has taken a genuinely eCommerce-first approach, but it was built for the construction and general equipment rental market, operates as a single-site solution and does not address the technical equipment hire environment or multi-channel, multi-brand operation.
The result across the industry is consistent: rental management and customer-facing eCommerce are treated as separate problems, solved by separate products, requiring the business to maintain two systems that are never fully in sync.
The Two-System Problem
The practical day-to-day cost of running a rental management system alongside a static website is not always visible as a single line item. It accumulates across small inefficiencies that become structural over time.
Every time a product is added to the fleet, it needs to be entered into the rental system and then separately described, photographed, priced and published on the website. If the rental system has 400 products and the website has 380, nobody is quite sure which 20 are missing or why.
Every time a product is retired, it should come off the website. Often it does not, because the person who removes it from the rental system is not the person responsible for the website, and the two have no automated connection.
Every time a product’s pricing changes, the change needs to be reflected in both places. If it is not, customers are quoted prices from the website that the business then has to honour or explain. More friction.
Every time a customer finds a product on the website and enquires about it, a member of staff has to check the rental system to confirm it is actually in the fleet, is available on the requested dates, and at the price shown. The website could not tell the customer any of this.
None of these tasks is individually significant. Together, across a catalogue of hundreds of products and a team managing both systems, they represent a meaningful and ongoing operational overhead that compounds as the business grows.
What the Customer Actually Experiences
The customer experience of the static catalogue model is best understood by comparison.
The same production company Assistant Director who is trying to hire equipment for a shoot has already booked their travel on a platform that showed live seat availability, offered dynamic pricing based on their dates, let them select options, process payment and receive instant confirmation in under three minutes.
They have booked their hire cars through a platform that showed live vehicle availability at their chosen location, displayed the full price including all fees upfront, took their card details and confirmed the booking immediately.
They come to a rental website and find a product page with no dates, no availability, no pricing and a button that says Request a Quote.
The friction is not relative. It is absolute. The customer is not comparing the rental website to a bad online experience elsewhere. They are comparing it to the experience they had for every other transaction they completed that day.
Some customers will submit the enquiry anyway. They may have a specific relationship with the business or no viable alternative. But a meaningful proportion will not. They will try the next company on the search results page, or they will abandon the search entirely. The business never knows this happened because an abandoned visit generates no data in a system that cannot receive bookings.
What It Costs: The Revenue the Business Cannot See
The cost of operating a static catalogue is primarily invisible because it is denominated in revenue that never arrives rather than in costs that appear on a statement.
Across more than 100,000 orders processed through Circulio-powered rental channels in recent years, an average of 44 per cent of all orders placed through eCommerce-enabled channels were completed entirely by customers without any staff involvement. By value, 45 per cent of fee-bearing rental turnover was generated through those self-service orders.
A rental business operating a static catalogue is currently generating zero per cent from this model. Not because its customers are different, or because its products are unsuitable for online ordering, or because customers will order the wrong things, but because the infrastructure that would allow customers to transact online does not exist.
The gap between zero and 44 per cent is not a theoretical improvement. It is the difference between a business that processes every enquiry manually and one that processes nearly half its order volume automatically.
You can read a detailed breakdown of what that model looks like in our article on self-service rental orders.
Circulio-powered channels average 44 per cent self-service orders. See how the platform makes that possible.
Explore online booking →The Catalogue Maintenance Cost Is Also Real
Beyond the invisible cost of lost revenue, the two-system model carries a visible one.
Maintaining a separate website and a separate rental management system requires ongoing effort from someone in the business. That effort is either a direct cost, if a developer or digital agency is involved in website updates, or an indirect one, if someone in the operations team is responsible for keeping the website current. Either way, it consumes time that could be directed elsewhere.
More significantly, the website is almost never current. There is always a lag between what is in the rental system and what appears on the website. That lag means the website cannot be trusted as a source of truth even for the business’s own sales team, let alone for customers.
A rental business running on the Circulio platform has one product catalogue. Products added to the platform are immediately available on every relevant Circulio-powered website and channel. Pricing changes apply everywhere they are meant to at once. A product removed from the fleet disappears from all channels automatically. The website is always current because it is not a separate website. It is the customer-facing view of the same system that runs operations.
The First Step Is Not a Rebuild
The most common reason rental businesses do not address the static catalogue problem is that they persuade themselves that what they do is so technically complex, so nuanced, and requires so much human interaction, that the mere concept of providing live availability and self-service ordering is a non-starter. Or they are just so busy dealing with request a quote forms they are not making time to think about it at all.
The practical starting point for most rental businesses is to identify the portion of their product catalogue that is genuinely repeatable and well-defined: the standard packages, the commonly hired combinations, the products where the configuration does not change and the pricing does not need to be negotiated. This is almost always a larger proportion of the catalogue than initially expected and it is where the Circulio team always start their onboarding.
Moving that portion online first, with live availability and a checkout, does not require removing the quoting workflow for the rest of the asset base. In Circulio, both models coexist. The business keeps expert quoting for the complex work. It moves the repeatable work online. Over time, as customers demonstrate their willingness to transact online, the proportion that moves to self-service grows naturally.
The question is not whether two separate systems is the right approach. It is whether the current model, where every enquiry requires manual processing regardless of its complexity, is the right default for a business that wants to grow.
Frequently Asked Questions
Why do so few rental businesses have eCommerce on their websites?
The primary reason is structural. Most rental management software was built as a back-office operational tool, not as an eCommerce platform. It manages inventory, quoting, orders and warehouse operations effectively, but it was not designed to provide a customer-facing online store with live availability and checkout. Rental businesses therefore end up maintaining a separate static website alongside their rental system, with no automated connection between the two.
Is it possible to add online booking to an existing rental management system?
Some rental management systems offer partial integrations with external booking widgets or customer portals. These typically require manual synchronisation between the external booking tool and the rental system, or depend on API connections that need ongoing maintenance. The fundamental problem is that the two systems have separate product catalogues and separate availability states, which requires ongoing effort to keep aligned. The alternative is a platform where the customer-facing channel and the operational back office are the same system, with no synchronisation required.
How out of date is a typical rental website catalogue?
This varies by business and by how much resource is dedicated to keeping the website current. In practice, most rental businesses accept a degree of divergence between what is in their rental management system and what appears on their website. New products may take days or weeks to appear online. Retired products may remain listed indefinitely. Pricing discrepancies are common. The degree of divergence tends to increase as the business grows, because the maintenance burden grows with the catalogue.
What is the minimum viable first step toward rental eCommerce?
The most practical starting point is to identify the portion of the product catalogue where the configuration is fixed and the pricing does not require negotiation. Standard packages, commonly hired combinations and single-item hires at published rates are good candidates. Moving these to a live availability and checkout model first, while retaining a quoting workflow for complex or bespoke orders, allows the business to test self-service without abandoning the workflows it depends on for complex work.
Does moving to eCommerce mean losing the relationship with customers?
No. The customers who value a direct relationship with the hire team will continue to use it for the complex, high-value work where that relationship adds genuine value. The customers who would prefer to transact online without a conversation will be able to do so. The data from live rental channels suggests that a substantial proportion of customers, including professionals and trade customers, will use self-service when it is available, without any reduction in order quality.
How does Circulio address the two-system problem?
Circulio was built as a single system in which the customer-facing eCommerce channel and the operational back office share the same product catalogue, the same availability engine and the same order records. A product added to the Circulio platform is immediately available on every channel it has been assigned to. Availability shown to customers is calculated from the same data that drives warehouse operations. There is no synchronisation between a website and a rental system because they are not separate systems.