{"id":3734,"date":"2026-10-23T14:34:08","date_gmt":"2026-10-24T02:34:08","guid":{"rendered":"https:\/\/footworklab.net\/?p=3734"},"modified":"2026-10-23T14:34:08","modified_gmt":"2026-10-24T02:34:08","slug":"foot-scanner-demo-request","status":"publish","type":"post","link":"https:\/\/footworklab.net\/es\/news\/3734\/","title":{"rendered":"Requesting a Foot Scanner Demo: How to Make One Session Tell You Most of What You Need"},"content":{"rendered":"
\n

About the author<\/strong> \u2014 FOOTWORK LAB is a manufacturer of foot assessment equipment and custom orthotic insoles, based in Ruichang, Jiangxi Province, China. Founded in 2014, with its own production plant since 2018. Certified to European Union and ISO quality system standards. See the factory<\/a> or view certification<\/a>.<\/p>\n<\/div>\n

A demo request is usually written in one line and answered with a calendar link, which is why most demos answer very little.<\/strong> The supplier brings a machine, runs a scan on whoever is standing nearby, shows a colourful report and leaves. Two weeks later the buyer remembers the colour and nothing else.<\/p>\n

That is not a failure of the machine. It is a failure of the test. A demonstration becomes useful at the moment the buyer decides in advance what would have to be true for the answer to be yes \u2014 and then designs a session that can produce that evidence or fail to produce it.<\/p>\n

This article sets out how we would run a demo if we were the buyer: what to send beforehand, how to structure the two passes, what to watch in the room, and how to close the decision before the memory fades. We build plantar pressure systems, so we have sat on both sides of this table many times, and the pattern is consistent.<\/p>\n

Why a demo is a test you design, not a visit you receive<\/h2>\n

The default demo is a product tour. It is designed by the seller, sequenced to show strengths in the order that flatters them, and it ends with a question about budget. It can still be informative, but only accidentally, because nothing in it is falsifiable. If the machine misbehaves, the operator simply moves to the next screen.<\/p>\n

A test is different in one respect: it has a hypothesis written down before the session. For a clinic, the hypothesis might be that a full foot record can be captured inside an existing appointment slot without a second staff member. For a shoe retailer, it might be that a scan shortens a fitting conversation rather than lengthening it. For a workshop, it might be that the output file is usable by the person who designs the insole without a translation step.<\/p>\n

Once the hypothesis is written, the demo has a pass and a fail, and the supplier can be told what is being tested. Good suppliers welcome this. It tells them which capability to bring forward and which to leave in the brochure, and it removes the awkward dance where the buyer watches politely and then goes quiet for a month.<\/p>\n

Write the hypothesis in one sentence and send it with the request. If a supplier cannot work with a stated hypothesis, that is the first useful data point of the whole process, and you have obtained it for the price of an email.<\/p>\n

Before the session: what to send the supplier<\/h2>\n

Send the constraint set, not the wish list. The constraint set is the list of things that cannot change: the size of the room, whether the floor is level, whether the machine has to be moved between rooms, whether the network reaches that corner, who will operate it and what language they read, and how long the appointment actually is once the client is seated.<\/p>\n

Send two or three real cases rather than one. A demo conducted on a healthy adult standing still is the easiest possible input; every instrument performs well on it. Ask instead for a session built around the kind of foot you actually see \u2014 a stiff midfoot, a very wide forefoot, a client who cannot stand unsupported for long \u2014 described in neutral terms and without any clinical history attached.<\/p>\n

Ask what the supplier needs from you. A pressure platform wants a clear run-up and enough space to walk through it; a posture capture wants a defined standing position and a camera line that is not blocked by a chair. If those conditions cannot be met in your room, better to discover it in an email than on the day.<\/p>\n

Finally, state the decision date. A demo without a date becomes a conversation; a demo with a date becomes a project. The date also forces you to invite the people who will actually use the machine, which is the single most common omission in equipment purchases. The operator who was not in the room is the person who later says the system does not fit the workflow, and they will usually be right.<\/p>\n

\"F2
FOOTWORK LAB F2 plantar pressure system. Product photography of our own output; specifications are confirmed in writing before an order.<\/figcaption><\/figure>\n

Running the first pass: the standard capture<\/h2>\n

The first pass should be boring. Ask the operator to run the routine exactly as they would with a paying client, at their normal pace, using their normal words. Do not help. Do not suggest shortcuts. Time it, with a phone, visibly, and note where the time goes: preparation, capture, data entry, explanation.<\/p>\n

While it runs, watch the client rather than the screen. How long are they asked to stand still? Is the position explained or demonstrated? Does the operator have to leave the room to fetch anything? These small frictions decide whether a system is used daily or reserved for special cases, and none of them appear in a specification sheet.<\/p>\n

Then look at the output with the operator, not with the salesperson. Ask the operator to explain the report as they would to a client, in their own language, without prompting. If the explanation is fluent, the interface is doing its job. If the operator hesitates and looks at the supplier for the right phrase, the report is written for engineers rather than for the room it will be used in.<\/p>\n

Record three things at the end of the first pass: the elapsed time, the number of manual entries, and the number of moments where the operator asked the supplier a question. Those three numbers describe the operational cost of the system better than any feature list, and they are comparable across suppliers if you run the same protocol with each one.<\/p>\n

Running the second pass: the same foot, different conditions<\/h2>\n

The second pass is where most demos are won or lost, and almost no buyer asks for it. Run the same person again, with one variable changed, and see whether the record moves in a way that can be explained.<\/p>\n

Useful variables are cheap. Change the stance: feet together, then a comfortable stride width. Change the surface: the platform as supplied, then with the thin mat the clinic actually uses. Change the footwear: barefoot, then in the sock a client would wear. Change the operator: let a second staff member run the routine from scratch after watching once.<\/p>\n

What you are testing is repeatability and sensitivity at the same time. A record that does not change at all when the stance changes is probably not measuring much beyond shape. A record that changes wildly when nothing meaningful changed is unstable, and unstable instruments create arguments in a clinic because two sessions produce two different stories.<\/p>\n

The operator change is the most revealing of the four. If a second person can run the routine after one observation and produce a comparable record, the system has a workflow. If the second person needs the supplier standing beside them, the system has a dependency, and that dependency will be priced into your staffing for as long as you own the machine.<\/p>\n

\"F2
FOOTWORK LAB F2 plantar pressure system. Product photography of our own output; specifications are confirmed in writing before an order.<\/figcaption><\/figure>\n

What to watch in the room that no datasheet records<\/h2>\n

Watch where the cable goes. Watch whether the machine has to be switched off between clients or can stay in a ready state. Watch how the operator cleans the surface between people, and whether that cleaning is a ten-second wipe or a five-minute procedure. Hygiene routines decide throughput in any room that sees more than a handful of clients a day.<\/p>\n

Watch the client’s face during the capture. A system that produces an audible noise, a long pause or a visible flash changes the atmosphere of an appointment. That matters commercially as much as clinically: a client who felt hurried is a client who does not book the follow-up.<\/p>\n

Watch what happens when something goes wrong. Ask the operator to deliberately break the routine \u2014 lift a foot mid-capture, stand on the edge of the platform, turn around. A well-built workflow recovers in one step and says so plainly. A fragile workflow requires a restart, and the restart is what stretches an appointment from ten minutes to twenty-five.<\/p>\n

None of this is a criticism of specification sheets. They answer a different question. But a buyer who only reads specifications is buying a bench instrument, and a buyer who watches the room is buying a working day. The two are not the same purchase, even when the invoice is identical.<\/p>\n

There is one more observation worth making during the session, and it is about the salesperson rather than the machine. Does the person demonstrating defer to the operator on workflow questions, or override them? A supplier who listens to the person who will actually run the system is a supplier who understands that the purchase belongs to the room, not to the buyer’s signature. That habit tends to survive the delivery.<\/p>\n

Questions that belong in the room, not in the follow-up email<\/h2>\n

Ask about the day the machine arrives, not the day it is demonstrated. Who unpacks it, who assembles it, who configures the language, and who trains the second shift. Ask for that sequence as a list with owners, and ask what happens if the crate is delayed at customs \u2014 because it will be, eventually.<\/p>\n

Ask what the software does when the network is down. Ask whether records are stored locally, whether they can be exported in a format another system can open, and who owns the data if the relationship ends. These questions sound administrative and are in fact the difference between a system you control and a system you rent.<\/p>\n

Ask how updates arrive and what they change. Ours reach connected units over the air, which turns a software change into a scheduled restart rather than a service visit. Whatever the answer, the question exposes the support model: a supplier who controls its own software can describe a roadmap, and a supplier who does not can only forward your request.<\/p>\n

Ask for the failure story. Not the worst story, the ordinary one: the most common reason a unit comes back, how often it happens, what the part costs and how long it takes to arrive. A supplier who answers this without flinching has seen their product in the field. A supplier who answers with a statistic has seen a slide deck.<\/p>\n

Ask about the second machine. If your plan includes opening another room in two years, ask now whether the software manages multiple units, whether the records are pooled, and whether the second unit can be a different model. Buying one machine twice is easy; making two machines behave like one system is a design decision that was made long before you arrived.<\/p>\n

\"F2
FOOTWORK LAB F2 plantar pressure system. Product photography of our own output; specifications are confirmed in writing before an order.<\/figcaption><\/figure>\n

After the demo: the three-day decision rule<\/h2>\n

Write the verdict within three days, while the details are still specific. A one-page note is enough: the hypothesis you wrote, what the session showed, the three numbers from the first pass, and the two things that surprised you. Send it to the supplier and ask them to confirm or challenge the factual points. Their reply is a free sample of how they will behave when something matters.<\/p>\n

Then separate the decision into two parts. The first part is fit: does this instrument answer the question your room actually asks, in the time your room actually has. The second part is the relationship: parts, spares, software, and the name of the person who answers the phone. Most buyers merge these into a single feeling and then wonder why the feeling changes after delivery.<\/p>\n

If the session failed, say so plainly and say why. A supplier who argues with a well-documented failure is telling you something valuable. A supplier who asks what would have made it pass is telling you something better, and it is often worth a second session with a different configuration rather than a different supplier.<\/p>\n

The point of the whole exercise is not to run a better demo. It is to arrive at the purchase with evidence you generated yourself, so that the machine in your room is the machine you tested rather than the machine you remember.<\/p>\n

Frequently asked questions<\/h2>\n
\n

Can we run a demo before placing an order?<\/h3>\n

Yes, and we prefer it. Machine orders start at one unit, so a demonstration or a trial unit is a realistic first step rather than a formality. Tell us the room, the appointment length and the kind of foot you see most often, and the session is built around that.<\/p>\n

What should we prepare for the session?<\/h3>\n

Send the constraints in advance: room size, floor, network access, who operates the machine, the language they read and the real appointment length. Bring two or three typical cases. We will bring the machine configured for the routine you described rather than for a stage demonstration.<\/p>\n

Can a second staff member run the routine during the demo?<\/h3>\n

That is one of the most useful things you can ask for. A workflow a second operator can follow after one observation behaves very differently in a busy week from one that needs the supplier standing beside them.<\/p>\n

Is the software included, and do updates cost extra?<\/h3>\n

The analysis software ships with the system, and connected units receive updates over the air. Anything beyond that scope \u2014 extra seats, custom report layouts, integrations \u2014 should be written into the quotation so that the comparison is made on the same basis.<\/p>\n

How long does delivery take after an order?<\/h3>\n

Every machine runs a seven-day test routine before dispatch. Transit then runs six to seven working days by express, ten to twelve by air and thirty to thirty-five by sea. Capacity runs three to five machines a day.<\/p>\n

What support is included after the demo becomes an order?<\/h3>\n

A dedicated WhatsApp group per customer with direct engineer access, remote assistance where the site allows it, and a twelve-month warranty on non-human damage with free replacement parts.<\/p>\n

Can we buy a single unit to evaluate in our own clinic?<\/h3>\n

Yes. Machine minimum order is one unit, and training can be repeated remotely when new staff join. We would rather a clinic evaluate a machine in its own room than commit to a fleet on the strength of a hotel meeting room.<\/p>\n<\/div>\n

What we would do next<\/h2>\n

If you are preparing a demo request, send us the hypothesis rather than a preferred date. The F2 plantar pressure system<\/a> page describes what the machine records, the factory page<\/a> shows where it is built, and the FAQ page<\/a> states minimums, warranty, support and transit in writing before any conversation starts. Use the contact page<\/a> to book a session and tell us which two passes you want to run.<\/p>\n

For a parallel read on the same decision from a different angle, see the sequence that keeps a scanner purchase simple<\/a> and how to turn a search phrase into a decision<\/a>.<\/p>\n

This article is intended for professional and educational reference. It is not medical advice. Foot assessment equipment produces measurements and images; clinical interpretation and any decision about care remain the responsibility of a qualified professional. Certification scope is limited to the documentation we hold: European Union certification and ISO quality system certification.<\/em><\/p>\n

\n

Related reading<\/h2>\n