Companion Robot Setup Checklist: 24 Tests Before the Return Window Closes

A companion robot can make a strong first impression in a carefully controlled demonstration. The harder question is whether it behaves predictably in an ordinary home, on your network, with your phone, under the privacy settings you actually want. A return period is the rare moment when that question can be investigated while the purchase remains reversible.

The goal is not to stress hardware recklessly or to defeat security controls. It is to use documented features and normal consumer settings to see what is local, what depends on a cloud account, what data can be removed and what help exists when something fails. The same process also separates a product limitation from a setup mistake. A feature that needs a paid plan should be identified as such; an inaccessible control should not be accepted merely because the robot can hold an impressive conversation.

This checklist is deliberately product-neutral. No named companion robot has been certified by BizarreSexuality.com, and a successful test on one unit does not prove that every unit or future software release will behave identically. Follow the manufacturer’s safety instructions, avoid opening enclosures, do not interfere with batteries or motors, and preserve packaging until the seller confirms that you can discard it.

Before test one: preserve your right to return

Save the product page, order confirmation, advertised feature list, warranty, privacy notice, subscription terms and return policy as dated files. Record the delivery date and the last day on which the seller must receive a return request. Note whether opened products, personalized items, software activations or hygiene seals change eligibility. If the language is unclear, ask the seller in writing before continuing.

Use a temporary, unique password and the smallest amount of personal information the service accepts. Do not upload private images, intimate conversations, household schedules or biometric samples merely to see whether personalization works. A first-week test should create disposable data. For broader purchase criteria, start with the 12-point companion robot buying checklist.

Tests 1–4: account creation and ownership

1. Identify the contracting company. Confirm the legal entity operating the account, not just the consumer brand printed on the box. Record its support address and country. 2. Verify email and recovery. Complete normal recovery without sharing extra information and confirm that recovery messages clearly identify the request. 3. Inspect multi-factor authentication. If it is offered, enable it and save backup codes securely. If it is absent, record that limitation rather than assuming the device itself protects the account. 4. Locate ownership-transfer rules. Ask whether the robot and account can be transferred to another adult, and whether a factory reset actually releases the serial number from the first account.

These tests reveal whether the physical object can become stranded behind an account. They also help estimate resale and service risk. Never try to register another person’s identity or bypass an activation lock; the point is to verify the supported process.

Tests 5–8: permissions, sensors and indicators

5. Refuse optional phone permissions. Deny contacts, precise location, photos and nearby-device access unless the requested feature genuinely needs them. Document which core functions still work. 6. Inspect camera and microphone controls. Find the hardware switch, software toggle or indicator described by the manual. Test whether the status remains visible when the room is dark. 7. Review notification settings. Disable marketing and keep only security or service alerts if the app allows that separation. 8. Check household consent. Determine whether the product warns visitors that audio or video may be processed and whether sensors can be disabled before someone enters the room.

A permission prompt is not evidence that data is uploaded, and a friendly indicator is not proof that collection is impossible. Treat the result as observed behavior and compare it with the privacy notice. The camera and microphone privacy guide explains how to document gaps without making unsupported surveillance claims.

Tests 9–12: network and offline behavior

9. Use a guest network. Where your router supports one, place the robot on an isolated guest or IoT network and check whether setup succeeds. 10. Interrupt internet access normally. Disconnect the router or use its device-pause control; do not jam signals. Record whether movement, local controls, alarms and saved settings remain available. 11. Restore the connection. Note whether the robot reconnects automatically and whether queued audio, images or telemetry appear to upload afterward. 12. Change the Wi-Fi credential. Follow the official re-pairing process and confirm that the device can be moved to a new network without support intervention.

Label every outcome carefully: works offline, requires cloud, failed unexpectedly or unknown. Do not infer that an offline animation proves local conversational AI, or that a brief outage predicts permanent shutdown behavior. See the site’s offline versus cloud companion robot guide for a feature-by-feature map.

Tests 13–15: subscriptions and paid features

13. Match the demo to the plan. List each advertised capability and the plan required to use it after any trial. 14. Cancel a trial through the documented path. Confirm the effective date and save the acknowledgement. A cancellation test should not erase the whole account unless the seller says it will. 15. Observe the free or base state. Record which features remain after cancellation, whether stored settings persist and whether the app repeatedly blocks basic device controls with upgrade screens.

Do not assume a feature is included forever because it worked on day one. Equally, do not describe a disclosed paid service as a hidden fee. The useful evidence is a dated matrix of hardware functions, recurring prices and cancellation effects.

Tests 16–18: updates and support

16. Install one official update. Use stable power and the documented method. Record the version before and after, the release notes and whether settings changed. 17. Find the security contact. Confirm that the company publishes a support or vulnerability-reporting route and provides a ticket number. Do not probe for vulnerabilities or run scanning tools against the service. 18. Ask a concrete support question. Request the promised support period for the exact model and app, plus what remains usable if the cloud service ends.

NIST’s consumer IoT baseline treats secure software update, data protection, configuration and cybersecurity-state awareness as core capabilities. It is guidance, not a certification of a particular companion robot. Use it to shape questions rather than to award a badge. Our five-year software support checklist gives a longer ownership framework.

Tests 19–21: export, deletion and reset

19. Create disposable test data. Use a fictional preference and a harmless test conversation, then look for it in the app’s memory controls. 20. Request or download an export. Check whether it contains readable conversations, profile settings and device identifiers, and record what is omitted. 21. Delete the test data and perform a supported reset. Confirm separately what disappears from the phone, robot and cloud account. If a reset would void the return or require unsafe handling, stop and ask support.

Deletion controls can have different scopes. Removing a chat from the interface may not close the account, and closing the account may be subject to legally required retention. The test is whether the product explains those distinctions. The step-by-step AI companion data deletion guide provides an evidence log.

Tests 22–24: daily use, accessibility and exit

22. Run a quiet-room and noisy-room test. At safe volume, check whether speech controls work in ordinary background noise and whether captions or text alternatives exist. 23. Test a complete power cycle. Use the documented shutdown, disconnect only as instructed, restart and verify that time, permissions, pairing and privacy settings persist. 24. Rehearse the exit. Locate return authorization, remove disposable data, sign out, unpair the phone, disable subscriptions and confirm how the serial number is released.

Accessibility is part of product fit, not an optional polish test. Check text size, contrast, button reach, hearing alternatives and whether a caregiver can assist without gaining permanent account access. Document failures with screenshots or ticket numbers while avoiding images that reveal private household information.

How to score the results without inventing a safety rating

Use four labels: documented, observed, claimed and unknown. “Documented” means the seller commits to the behavior in current materials. “Observed” means your unit did it under a recorded condition. “Claimed” means support or marketing states it without a test or durable commitment. “Unknown” means you could not establish an answer. A product may pass a convenience test while leaving a long-term policy unknown.

Do not convert the labels into a universal percentage. Weight them according to your intended use. Someone who needs reliable offline controls may reject a cloud-only device that another buyer accepts. Someone who shares a home may treat sensor indicators and guest consent as essential. The scorecard should make the dependency visible, not manufacture scientific certainty.

Return, keep or ask for remediation?

Return the product when a required capability was materially misrepresented, normal setup cannot be completed, essential privacy controls are absent, or the seller cannot provide a workable path within the return deadline. Ask for remediation when the issue is documented, reversible and the seller gives a specific resolution date that does not sacrifice your rights. Keep the product only after pricing its unknowns realistically.

Do not continue troubleshooting past the deadline merely because support promises to reply. Send a clear written notice before expiry and preserve proof. Consumer rights differ by country and purchase channel, so official local guidance and the seller’s contract matter more than a generic online checklist.

Sources and editorial method

This guide uses the NIST consumer IoT cybersecurity profile, the US Federal Trade Commission’s connected-product support disclosure review, and the UK National Cyber Security Centre’s device security guidance. These sources provide evaluation principles, not endorsements of any robot. The original hero image was generated for this article and depicts a fictional unbranded device.