Self storage booking software that ends in a paid, papered move-in.

A booking is finished when a verified customer holds a specific unit, has paid the first month and has a rental allocated against that unit. Anything short of that is an enquiry wearing the clothes of a booking, and it will still need a member of staff to turn it into a tenancy.

The reservation flow shows unit-type pricing and availability read from live inventory, helps a visitor size what they need before they choose, then claims one particular unit rather than reserving a size in the abstract. Email verification confirms the person exists at the address they gave. The account is created, documents are collected where the site requires them, the first card payment is taken through Stripe, and the rental is written against the held unit.

• Quote from the same unit types and pricing plans staff work from.
• Size the requirement before the visitor commits to a unit type.
• Hold one identified unit for the duration of the session.
• Verify the email address, then create the customer record.
• Collect the documents the onboarding requirements of that site name.
• Take the first card payment and allocate the rental in the same step.

Because it claims one. Availability read from a list is a number that was true when the page rendered, and two visitors reading the same number will cheerfully buy the same space in the same minute. The flow claims a specific unit out of inventory and holds it for the session, so the second visitor is refused at the point of claiming rather than at the point of arriving with a van.

Losing that race is a recorded outcome, not an error page. Someone who registered, verified their email and ended up holding nothing is a state the system can name, which is what makes them contactable afterwards. The unit and its state stay visible to staff in the list, board and map views over one filter set, so an online hold is never a private fact known only to the website.

Booking sessions are staged end to end, so an abandonment is a row rather than a hole. Two stages carry the recovery work: the visitor who registered and verified but never got a unit held, and the visitor who held a unit and opened a payment but never completed it. Those are different problems and deserve different messages.

A resume link returns the visitor to the point they left, with the hold still in place where one exists. The second stage is worth chasing hardest, because inventory is already committed to somebody who has not paid for it, and that is a cost rather than only a missed sale. Recovery messages go out through the same template catalogue as the rest of the email and SMS for the estate, with the same consent controls and delivery tracking.

Every attempt carries a lead attribution record naming one of eight channels: website, walk-in, telephone, email, referral, campaign, partner and other. There is deliberately no channel meaning we did not measure. An unmeasured lead reports as not captured, because a vocabulary that offers a polite shrug fills up with polite shrugs and the channel report becomes fiction.

Attribution sits on the attempt rather than on the finished tenancy, so an abandoned session still tells you which channel produced it. A campaign that generates holds nobody completes is a different failure from one that generates nothing.

Ask what is actually reserved when a customer books: a named unit, or a size the office allocates later. Ask what happens when two people book the last unit at once. Ask whether a booking can complete at a site with no published agreement, and what the operator does with the money if it can.

On tax, ask about the first charge specifically rather than about tax in general, because recurring invoices and the initial online payment are frequently handled by different code.

At a site with no published storage agreement, the booking is refused and the customer is told, rather than being charged for a tenancy nobody can paper afterwards. The agreement engine spans 15 modules and refuses to publish a template that still holds unresolved placeholders, so a half-finished draft cannot become a live contract by accident, and booking honours the same rule from the other side. The refusal is deliberate and it is correct, but it does mean publishing the agreement is a configuration step you complete before a site can sell anything online.

The other edge is tax, and it is worth stating plainly: a site that has configured rent tax collects none of it on a first month booked online. Tax policy resolves per scope and category, treatment is recorded and every policy change is audited, and that machinery applies to the invoices that follow. The first charge taken inside the booking does not yet apply it. What the code will not do is blur the two reasons a tax figure can be zero, since a rate chosen as zero and a rate that is unknown are carried out of the pricing call as different facts, so no part of the system can treat an unconfigured site as a zero-rated one. Read nothing here as complete online-booking tax handling.