How to Run a 30-Day J25 Pilot: A Week-by-Week Acceptance Plan
Prepared by the ChatField Editorial Team. Evidence reviewed August 18, 2026.
A one-hour demonstration can confirm that equipment turns on. A 30-day pilot can show whether the complete phone-paired workflow fits representative users, routes, shifts, support processes and purchasing requirements.
The objective is not to produce the largest possible number of messages. It is to make an evidence-based buy, revise or stop decision.
Short answer
Use week 1 for scope and bench qualification, week 2 for safe route evidence, week 3 for representative shift use, and week 4 for exceptions, retest and commercial decision. Freeze versions at the start, define pass criteria before testing, and keep required emergency communication systems outside the pilot.
Before day 1: authorize the scope
Name the procurement owner, operations lead, IT or phone-management contact, safety reviewer and ChatField contact. List intended users, phones, destination market, routes, supported message types and prohibited uses.
For current J25 use, the smartphone is the interface. Bluetooth pairs it to the carried J25 terminal, and the configured terminal carries supported traffic through the local LoRa mesh to another equipped terminal and paired phone.
The How It Works page should be attached to the pilot brief.
Week 1: bench qualification
Record every phone model, operating-system version, application build, J25 hardware identifier, firmware and regional configuration. Label phone-terminal pairs and create the approved groups.
Test installation, permissions, Bluetooth pairing, supported PTT, text, image and location workflows, phone restart, terminal restart and reconnection. Use non-sensitive test content.
Confirm the product and evidence identity. Current public J25 evidence includes FCC ID 2BVP9-J25. The authorization does not prove the buyer's route or application workflow.
Week 1 exit gate
- Exact versions and assignments recorded
- Every selected phone completes the required bench workflow
- Pairing and recovery steps are understood
- Safety, privacy and prohibited-use rules are approved
- Week 2 route and checkpoints are authorized
Week 2: route and range evidence
Test the actual safe route in both directions. Record terrain, structures, vegetation, vehicles, device placement, message type, delivery, delay, acknowledgement and human understanding.
Current J25 evidence includes 5 km in urban-obstructed testing and up to 10 km in ideal open terrain. Use those figures as bounded planning evidence, not a universal guarantee.
Establish the direct path first. For current planning, evaluate no more than two participating relay nodes where the tested layout and configuration permit. Do not multiply headline distance by hop count.
Review the J25 specifications page before setting the route acceptance criteria.
Week 2 exit gate
- Every required checkpoint is pass, marginal or fail
- Direct and relay results are separated
- Both directions and repeated trials are recorded
- Fallback exists at marginal and failed zones
- No user entered an unsafe area to improve a result
Week 3: representative shift use
Run the approved routine workflows with trained users during representative activity, without turning the pilot into a safety-critical dependency. Record device checkout, start battery, message mix, exceptions, end battery and handoff.
Test different roles and normal noise, PPE, vehicles and occupancy while preserving attention and safety rules. No one should read, type or troubleshoot while driving or performing an attention-critical task.
Observe whether users choose the correct group, understand PTT, acknowledge requests and recognize a disconnected phone-terminal pair.
Week 3 exit gate
- Required workflows fit the user roles
- Phone and terminal power meet the tested shift
- Checkout and handoff prevent assignment errors
- Users follow recovery and fallback procedures
- Privacy and data-handling rules are practical
Week 4: exceptions, retest and decision
Review every marginal result, failed checkpoint, wrong recipient, delayed message, unclear PTT event, disconnection, power issue and user error. Retest only after documenting what changed.
Separate product issues, phone-policy issues, training gaps, route limitations and unsupported expectations. Do not erase failed evidence when a workaround succeeds.
Finalize the proposed quantity, spares, phones, accessories, application scope, customization, documents, training, freight, support and acceptance terms.
Week 4 decision gate
- Buy: mandatory workflows and evidence gates passed with acceptable exceptions.
- Revise: the pilot identified bounded changes that can be retested.
- Stop: a mandatory route, workflow, evidence or commercial requirement is not met.
What the final report should contain
- Scope, users, routes and prohibited uses
- Phone, application, hardware and firmware matrix
- Direct and supported relay evidence
- Message and human-understanding results
- Battery, checkout and handoff results
- Failure, recovery and fallback evidence
- Safety, privacy and IT exceptions
- Open issues and retest records
- Recommended quantity and bill of scope
- Buy, revise or stop decision with approvers
CISA's communications-system lifecycle guidance emphasizes planning across design, acquisition, implementation, operations, maintenance and replacement. A 30-day pilot is one decision stage, not the entire lifecycle.
Connect the pilot to a B2B quotation
ChatField's current B2B discussion begins at a minimum order quantity of 100 units. Standard hardware, branding, packaging, custom application work and system engineering should be scoped separately. Final price, lead time, payment, Incoterm and delivery remain quotation-specific.
Contact ChatField procurement support with the destination market, phones, route, team roles and 30-day acceptance plan to scope a bounded J25 evaluation.
Sources reviewed
CISA and NIST do not endorse ChatField or J25. Their materials provide lifecycle and support context, not approval of a particular pilot plan or field result.