An RFID consulting engagement should leave your team able to make a decision or operate a defined part of the system. State that outcome first, then identify the deliverables and evidence needed to accept the work. Hours of advice and a working deployment are different scopes.
This guide provides a practical statement-of-work outline for discovery, site assessment, pilot design and handover. Adapt commercial and contractual terms through your organization’s usual procurement process.
Describe the business decision and its boundaries
Name the process, objects, sites, current problem and decision owner. Record the baseline with a defined measure: manual search time, missed movements, inventory discrepancies or another observable result. Identify the systems and people that must participate, and the access and samples the client will provide.
Ask a consultant to explain the proposed method, relevant experience and dependencies. The GS1 US provider profiles illustrate distinct hardware, encoding and application services. Use those categories to identify capability gaps, then evaluate the actual team and deliverables for your project. Directory presence alone does not establish suitability for your site.
State exclusions explicitly in the working brief: for example, a feasibility study may end before production integration. Identify the person responsible for work outside the engagement so an exclusion does not become an unnoticed gap.
Make each milestone reviewable
On a small screen, scroll sideways to read all columns.
| Milestone | Deliverable | Evidence to accept it |
|---|---|---|
| Discovery | Process map, baseline and prioritized requirements. | Operations owner verifies the mapped workflow and measures. |
| Site assessment | Documented observations, constraints and candidate read points. | Photos/plan references, assumptions and unresolved access limits. |
| Pilot design | Equipment/configuration proposal and test protocol. | Representative samples, metrics, denominators and agreed thresholds. |
| Pilot execution | Raw results, configuration exports and findings. | Repeatable runs, failures, exclusions and comparison with requirements. |
| Handover | Decision report, operating notes and training. | Client can reproduce the agreed task and owns remaining actions. |
Specify formats that the client can use: editable process diagrams, machine-readable results and configuration files alongside the report. Agree whether scripts, label formats and integration examples are included, and clarify permitted use and maintenance responsibility through procurement.
Define success before the demonstration
Choose measures tied to the business workflow. A tag read becomes useful when it produces the intended event for the right object and context. Include missed events, false events and operator recovery in the test protocol. Agree sample variation, repetitions and treatment of excluded observations before execution.
Keep the acceptance decision separate from the recommendation. A well-executed feasibility study can conclude that a proposed approach is unsuitable. That is useful work when the evidence is complete and the decision criteria were agreed in advance.
Assign the work between organizations
- Client process owner: provides representative workflow, baseline and acceptance authority.
- Consultant: owns the agreed method, records, analysis and deliverables.
- Hardware/media supplier: supports exact equipment and material compatibility.
- IT or integration team: provides approved interfaces, environments and deployment ownership.
- Operations team: participates in trials, exception handling and handover.
- Procurement/project owner: tracks scope, schedule, deliverable acceptance and changes.
Write dependencies with a due date and consequence. If test samples arrive late, the report should identify which conclusions remain provisional. If network access is unavailable, a standalone reader demonstration should be described at that scope.
Control changes and finish the handover
Use a simple change record: requested change, reason, affected deliverable, added effort, schedule effect and approving owner. Examples include another site, a new tag construction, production integration or a different object population. Record changes before combining their results with the original trial.
At handover, walk through the files with the people who will maintain them. Confirm equipment ownership, configuration backup, software access, source-data location, support contacts and open issues. Have the receiving team reproduce an agreed task while the consultant can answer questions.
Close with a decision, its evidence and a next-action list. Retain the assumptions that would cause a revisit, such as changes to packaging, routes, readers or customer requirements. The value of the engagement is the usable knowledge and evidence the organization can carry forward.
Keep a working record
Download the editable working record (plain text). It includes purpose, instructions, evidence fields and this guide's source links. Save a separate copy for each evaluation and record unresolved issues with their owner.
Related reading
Researched and updated September 20, 2026. Recheck source documents when equipment, software or applicable requirements change.