Plan the task around a measurable outcome
Scope and duration are the two decisions that determine whether a proximity pilot produces usable evidence or simply generates inconclusive noise. Scope defines what the pilot covers: the physical area, the number of devices, the features under test and the operational boundaries. Duration sets how long the pilot runs before you evaluate the results.
These two variables are linked. A narrow scope with a short duration might confirm that beacons power on and transmit, but it will not tell you whether the system behaves reliably across a full trading week or a busy event day. A broad scope with a short duration creates too many moving parts to diagnose when something underperforms. The practical task is to match the scope tightly to the question you need answered, then set a duration long enough for that question to receive a trustworthy response.
In most UK deployments, the core question is not whether the technology works in principle but whether it works in this building, with this footfall, using this integration. That dictates a scope limited to one clear use case and a duration that captures the variation your venue actually experiences.
Why scope and duration are decided together
If you plan a two-week pilot but include notification triggers, indoor navigation, and analytics dashboards in scope, you will spend the fortnight troubleshooting integration issues rather than observing visitor behaviour. Conversely, if you plan a three-month pilot to test a single entrance notification, the cost of hardware rental and staff time will be difficult to justify to whoever signs off the budget.
The sensible approach is to state the pilot's single most important question first, then derive both scope and duration from that question. For example: "Can we detect when a visitor enters the footwear department and trigger a relevant notification within five seconds, at least 90% of the time, during a normal Saturday trading period?" That question constrains the scope to one zone, one trigger type and one metric. It constrains the duration to a period that includes at least one Saturday, plus enough surrounding days to establish a baseline.
Pilot, measure and correct
Retail environments
Shops present a particular challenge for pilot duration because footfall varies enormously between weekdays, weekends and seasonal peaks. A pilot that runs only from Monday to Thursday will miss the busiest period and may give a misleading impression of system load and notification frequency. At the same time, running a pilot across a major promotional event introduces abnormal conditions that are equally unrepresentative.
A practical scope for a retail pilot typically covers one department or one entrance, a single notification type, and a clearly defined visitor segment who have opted in. The duration should include at least one full week of normal trading, ideally two, so you can compare weekday and weekend performance. If the retailer has a regular promotional cycle, avoid scheduling the pilot to overlap with an atypical event unless testing that specific scenario is the stated objective.
Museums and galleries
Museum visitor patterns differ from retail. Footfall tends to be steadier throughout the day but varies significantly by day of the week and during school holidays. A pilot scoped to a single gallery or one themed trail can produce useful results in a shorter timeframe because visitor flow through a defined route is more predictable than in a shop.
However, museums often want to test content delivery rather than simple zone detection. If the pilot includes audio triggers, image loading or accessibility features, the scope expands to cover content performance as well as signal reliability. That typically requires a longer duration because you need enough visitors actually engaging with the content to form a judgement about completion rates and drop-off points.
Events and temporary venues
Events present the opposite problem. You often have only one or two days, so duration cannot be extended. The scope must therefore be extremely narrow: one function, such as zone entry detection or a single information point, tested with whatever footfall the event provides. The limitation is obvious: you cannot generalise from a single event day. The pilot tells you whether the system survived the conditions, not whether it will perform consistently across a full exhibition season.
For recurring events, a more useful approach is to scope the pilot across two or three instances of the same event, treating each as a separate test cycle. That requires hardware that can be reliably reinstalled and reconfigured between events, which is itself a useful thing to learn from the pilot.
Operational factors that affect duration
- Staff availability: If the pilot requires floor staff to observe behaviour, reset devices or answer visitor questions, the duration must fit within rota patterns and avoid periods of annual leave or stocktake.
- Integrator support windows: If the deployment relies on a supplier for configuration changes or troubleshooting, the pilot duration should account for their response times. A three-day pilot with no supplier availability on day two leaves a gap in the data.
- Battery behaviour: If the pilot is also assessing power consumption, the duration must be long enough to observe a meaningful discharge curve rather than a single day's drop.
- Building access: Some venues restrict out-of-hours access. If beacon repositioning or signal testing is needed outside public hours, the pilot schedule must align with access windows.
Acceptance evidence and rollback
Scope creep during the pilot
The most frequent mistake is expanding the scope after the pilot has started. A team notices that the beacons could also track dwell time, so they add analytics. Someone suggests testing a second notification format. Within days, the pilot has three objectives instead of one, and none of them can be evaluated cleanly. The discipline is to document the scope before installation, treat any addition as a separate question, and resist the temptation to bolt on extras however tempting they seem mid-pilot.
Duration that is too short to be meaningful
A one-day pilot is rarely sufficient for anything beyond confirming that devices transmit. Signal behaviour changes with the number of people in a space, the position of doors, and even the weather if the building has large glass facades. A single day captures one combination of those variables. For any pilot that aims to inform a deployment decision, a minimum of five to seven active days is a reasonable starting point, adjusted upward for venues with high day-to-day variation.
Ignoring the evaluation period
Duration is not just the period when beacons are active. You need time afterwards to analyse the data, reconcile it with observational notes, and form a conclusion. A common oversight is scheduling the pilot to end on a Friday and expecting a deployment decision the following Monday. Build at least two to three days of post-pilot analysis into the timeline before any decision meeting.
Key checks before confirming scope and duration
- Can you state the pilot's single primary question in one sentence?
- Does the scope include only what is necessary to answer that question?
- Does the duration capture the range of conditions the system would face in normal operation?
- Have you excluded any period that would produce atypical results, unless atypical conditions are what you are testing?
- Is there enough post-pilot time to analyse results before the next decision point?
- Have you documented the scope in writing and shared it with the integrator, venue operations and any other involved parties?
- Is there a clear criterion for what counts as a successful outcome, agreed before the pilot begins?
Limitations to communicate upfront
A pilot with a narrow scope and a short duration cannot prove that a full deployment will succeed. It can only show whether the system performs acceptably under the tested conditions. That distinction matters when reporting results to stakeholders. Overstating what the pilot demonstrates leads to unrealistic expectations for the rollout. The honest framing is: "Under these specific conditions, the system did or did not meet the agreed threshold. Here is what we still do not know."
Where the pilot reveals a problem, the scope and duration may need to be revised before a second attempt. That is not a failure of the original pilot; it is the purpose of running one.
