The questions operators actually ask.

Knull Trolley is a connected shopper mobility service for retail destinations. It combines a designed trolley, a network of docking points across the destination, a shopper app for release and return, and an operator platform that shows where the fleet is and how it is being used.

Destinations where shoppers carry goods over distance or across levels: shopping centres, retail destinations, outlet villages and mixed-use districts. It is bought by the operator, and used by the shopper.

Not necessarily. Many destinations run Knull alongside existing equipment, in the areas where distance, levels or dwell time make an unmanaged trolley pool impractical.

Knull is engaging destinations on deployment. We do not publish customer names, deployment counts or performance statistics, and we will not present unverified figures as fact.

With discovery and a site assessment. We look at shopper flows, entrances, levels, dwell points, connectivity and servicing access before proposing a fleet size or dock network. The six stages are set out on the Deployment page.

It depends on the site, the dock locations agreed and the power and connectivity work involved. We give an indicative schedule once the site assessment is complete rather than quoting a generic timeline here.

Access for assessment and installation, agreed dock locations, power and connectivity at those locations, and an operational owner on the destination side. The responsibilities split is set out on the Deployment page.

Yes. A pilot in a defined zone — one mall arm, one level, one entrance cluster — is a normal first step, with agreed measurement criteria before expanding.

Commercial proposals are prepared per destination once the deployment scope is understood. We do not publish list pricing, because fleet size, dock count, service scope and installation requirements vary widely between sites.

Pilot deployment, managed fleet (trolley-as-a-service) and commercial rollout. Each is described on the Commercial Models page, including what is typically in scope and how a proposal is produced.

Service commitments are agreed contractually per deployment. We do not publish standard SLA figures on the website, because doing so would misrepresent what is actually negotiated.

Destination size and layout, annual footfall, trading pattern, the areas you want covered, and any constraints on dock placement, power or connectivity.

No integration is required for the service to run. Where operators want fleet and session data alongside their own reporting, we discuss an export or interface as part of deployment design.

The service is designed to keep working locally. Release and return continue at the dock, and the platform reconciles state when the connection returns.

The app is the primary route for release, return and receipt. Deployment design covers what happens for shoppers who cannot or prefer not to use it.

Yes. A demo walks through fleet visibility, dock occupancy and session views against your floor plan. The console shown on this website is an illustrative interface, not live production software.

Redistribution is part of the operating model agreed per destination — it can sit with the destination team, with Knull, or be shared. The platform surfaces where redistribution is needed rather than requiring a manual sweep.

Units are serviceable in place, and the platform flags units that need attention rather than relying on visual inspection. Cadence and ownership are agreed as part of the service model.

Fleet state, dock occupancy, exceptions that need action, and utilisation over time. The intent is exception-led operations, not constant monitoring.

They find a dock, release a unit through the app, use it during their visit, and return it to any dock in the network. The four steps are set out on the How It Works page.

Yes. Returning to any dock in the network is core to the design — it is what makes the service usable across levels and entrances.

The app directs the shopper to the nearest dock with capacity. Dock occupancy is visible to operators so capacity problems are addressed before they affect shoppers.

It is designed for continuous public use in premium retail environments: stable carrying architecture, controlled handling, serviceable components and a docking interaction that is obvious without instruction.

The platform flags it and the unit can be taken out of service from the console rather than waiting for it to be found on the floor.

Certification and compliance evidence is provided directly during procurement. We do not publish certification claims on the website.

Operationally, the service records sessions — release, return, dock and duration — so the fleet can be managed. Shopper account data is handled under the privacy policy.

The operator console is built around fleet and dock state, not shopper identity. Reporting is aggregate.

Data residency is agreed as part of deployment design, and is a normal procurement question for UK and UAE deployments.

Enquiry details are stored so we can respond, and are used only for that purpose unless you opt in to hear more. See the privacy policy.