Budget for a decision, not a demonstration
A pilot should answer a question that matters to the household, lab, developer, care organization, or partner. Start with a written decision such as whether KOKO can support a named routine in a particular environment with an acceptable level of assistance. Homebot One says KOKO is moving through in-home testing and engineering validation, so a pilot plan should preserve the distinction between observed behavior and a future product promise.
Write success, stop, and extension criteria before assigning money. Success might require a minimum number of useful completions under agreed room conditions. A stop condition may involve a safety concern, an unmanageable privacy issue, or repeated inability to complete the test. An extension should require a specific new question, not a general desire for more time. The decision statement also helps Homebot One understand what evidence the buyer needs and prevents unrelated showcase features from consuming the session.
Create five budget categories
The hardware or access fee is only one pilot category. Add preparation, operation, evaluation, and closeout. Preparation includes contracts, room review, network work, privacy review, participant communication, and training. Operation includes supervision, support calls, routine setup, charging, consumables, and schedule coordination. Evaluation includes observations, interviews, analysis, and the decision meeting.
Closeout often gets omitted. Budget for returning or relocating hardware, restoring the space, closing accounts, exporting or deleting data, reconciling invoices, and documenting lessons. Use ranges for uncertain costs and assign an owner to resolve each range. This produces a budget that can be approved without hiding labor in unrelated departments or relying on unpaid household effort. Add a modest contingency line with an approval rule rather than silently inflating every category, so the team can see where uncertainty actually sits.
- Hardware or program access
- Preparation and room or network readiness
- People time for training, operation, and supervision
- Measurement, analysis, and issue resolution
- Closeout, return, data handling, and reporting
Test in conditions that resemble intended use
Use NIST’s AI Risk Management Framework to organize trustworthiness questions throughout the pilot. A lab-perfect route may not answer a question about a changing family room. Describe flooring, thresholds, lighting, furniture, pets, children, visitors, connectivity, noise, and privacy expectations that could influence the result.
Budget enough repetitions to observe variation without presenting the pilot as proof of universal performance. Include normal interruptions and agreed edge cases, but do not deliberately create unsafe situations. If the intended location cannot be used, record the gap and identify what would still need validation there. The budget should buy relevant evidence, not merely more test hours. When conditions vary, note which variation was intentional and which was incidental; both can influence how confidently the result transfers to daily use.
Count the people and support work
List every role: pilot owner, primary users, household members, IT or facilities staff, privacy reviewer, safety contact, Homebot One support, and decision maker. Estimate preparation and participation time separately. A routine that appears efficient can create poor value if it transfers substantial work to another person or requires continuous expert supervision.
Agree on an issue process before testing. Define how users pause the pilot, who receives technical or safety reports, how quickly urgent issues are escalated, and which events consume extra paid support. NIST’s framework also emphasizes feedback from users and affected communities. Compensated interviews or accessible participation may therefore belong in the budget, especially for research or care settings. Include time for accessible instructions and alternative feedback methods so participation does not depend on one interface or communication style.
End with a costed next-step decision
At the end, compare the budget to actual spending and explain the variance. Then summarize useful completions, required assistance, failures, interruptions, user feedback, support incidents, and unresolved risks. Do not convert a short pilot into an annual savings claim without evidence about frequency, durability, maintenance, and changes in real operation.
Present three next steps with costs: stop and close out, run a narrowly targeted follow-up, or proceed to a defined deployment discussion. Each option should name the evidence it uses and the uncertainty it retains. This gives stakeholders a disciplined way to decide when the price is right in the ordinary purchasing sense, without pretending that a pilot establishes a public KOKO price. Archive the protocol, measurements, incidents, invoices, and assumptions together so a later team can understand why the decision was made.
Frequently asked questions
Has Homebot One published a standard KOKO pilot price?
No standard pilot price was displayed on the reviewed official pages. Contact Homebot One for current access, scope, eligibility, and written costs.
How long should a KOKO pilot run?
Long enough to answer the predefined decision under relevant conditions. Duration should follow the routines and evidence needed rather than an arbitrary number of days.
Should staff or family time be included in the budget?
Yes. Preparation, training, supervision, issue handling, evaluation, and closeout time are real resource costs even when they are not vendor charges.
What should a KOKO pilot budget report at closeout?
Report actual spending against the approved budget, explain material variance, document unpaid or internal labor, record closeout costs, and connect the evidence to a stop, follow-up, or deployment decision.
Sources & further reading
From Homebot One, the team building KOKO in Fremont, California.
