Bench testing tells you whether your device works. A pilot tells you whether it works where it will live. The temptation is to run a long one, but a tightly scoped two week deployment usually produces more usable information than a quarter of open-ended testing.
Write down what would make it a failure
Before installation, state the specific outcomes that would tell you the design is wrong. Vague success criteria produce pilots that everyone declares successful and nobody learns from. Define the number, the condition, or the behaviour that constitutes a fail.
Instrument more than the product needs
During a pilot, capture more raw data than the shipping product would. Signals you did not plan to use are exactly what you will want when an unexplained event shows up in the log. Storage is cheaper than a second deployment.
Record the installation itself
Time the install, note every tool required and write down every moment somebody had to improvise. Installation friction is the part of the product that never appears in a specification and it heavily influences whether the customer would deploy a second unit.
Keep a change log with timestamps
Anything that changes on site, including maintenance on the machine itself, needs a timestamp. Without it you will spend days investigating an anomaly that was somebody servicing the equipment.
Plan the exit before the entry
Agree in advance what happens at the end: whether the unit is removed, left running or upgraded. A pilot that quietly turns into an unsupported permanent installation creates an obligation you never scoped.
Debrief while it is fresh
Hold the review within days of the pilot ending, and include whoever did the physical work. The most valuable observations tend to come from the person who had to hold the enclosure in place while finding a screwdriver.