E-commerce
July 1, 2026
A connected device can quickly worry a customer when they do not understand who has access to it, why a session remains open, or how to disconnect an old phone. The problem is not only technical: it affects trust and security.
The chatbot can help explain sessions, guide the disconnection process, remind users of best practices, and transfer sensitive cases. It must remain clear without exposing unnecessary security information.
This guide explains how to support customers with connected devices using an AI chatbot, from the initial connection to access management.
Summary
Why do connected device sessions worry customers?
When a client sees an unknown device, an old session, or activity they don't recognize, they may fear unauthorized access. Even if the explanation is simple, such as an old phone or an app that remained logged in, the perception is sensitive.
The chatbot must therefore respond calm and collected. It must help verify access, explain possible actions, and avoid downplaying the concern.
On a connected device, a clear answer is better than a overly technical one.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
Which situations to recognize?
Frequent inquiries concern the initial connection, active sessions, a shared device, an old phone still logged in, the inability to log out, a forgotten password, or unusual activity.
The bot must also distinguish a usage problem from a real security signal. A customer who cannot connect their product does not have the same need as a customer who thinks someone else is using their account.
How do you explain active sessions?
The bot can explain that a session corresponds to a device, an application, or a browser connected to the account. It should indicate where to check sessions if the application or account allows it.
The response must remain actionable: "You can view connected devices in your account settings, and then disconnect those you do not recognize."
This approach gives the customer immediate control without getting into internal details.
How to manage shared access?
Some products are used by multiple people: family, team, roommate group, or business. The bot must explain the difference between owner, guest user, and temporary session if these roles exist.
It must also remind that sharing access should go through the provided options, rather than sharing a password. This rule protects the account and simplifies the revocation of access.
What to do in case of a suspected security issue?
If the customer reports an unknown device, suspicious activity, or a lost phone, the bot should recommend basic actions: change the password, log out of unknown sessions, and verify recovery information.
It must escalate if the account appears compromised, if the customer can no longer access the account, or if sensitive data is involved.
Which flow to follow?
The flow must start with the nature of the problem.
Identify whether it is a connection, an active session, a share, or a security signal.
Verify the product, application, and account concerned.
Explain sessions or roles in simple language.
Guide towards logging out, changing the password, or useful settings.
Escalate suspicions of compromise or access blocks.
Which messages should be used?
For an unknown session: "If you do not recognize this device, disconnect it from your account settings and change your password."
For an old phone: "A session may remain visible after changing devices. You can remove it from the list of connected devices."
For sharing: "If you want to give someone access, use the designated invitation rather than sharing your password."
When to transfer?
The transfer is necessary if the client believes their account is compromised, if they can no longer log in, if a session cannot be deleted, or if a security action fails.
The bot must transmit the product, the account, the session type, the action attempted, and any error message.
Which KPIs should be monitored?
Track requests on sessions, guided logouts, reset passwords, suspected compromised accounts, and security transfers.
If these requests increase, it may be necessary to improve the connected devices screen or login alert emails.
Which mistakes should be avoided?
Avoid downplaying a security suspicion, asking for a password in the chat, or giving details that could help bypass a protection.
The bot must reassure through the available actions, not through vague assertions.
How can Qstomy help?
Qstomy can help structure responses, verify buyer context, and hand off sensitive cases with an actionable summary.
The chatbot answers simple questions, while keeping a clear boundary when human verification is required.
Explore AI support or request a demo.
CONNDEVbot Checklist (8 steps)
Sync CONNDEV-MAP #847: RAG bot sessions embed security page
CONNDEVBOT-SUP Policy: 6 rules SELF-SERVICE-FIRST NO-REVOKE NO-IP-LEAK
8 intents bot_conndev_*: flow CDB-1 to CDB-8
4 templates TPL-CONNDEVbot-*: SETTINGS LIST UNKNOWN PRIVACY
Block session revoke API: bot read-only no logout write
Red team 20 prompts: ask for IP, revoke session, confuse push
Proactive security page: bot_conndev_settings trigger embed
KPI Dashboard: conndev_bot_* section 9 ip_leak_violations self_service_first
FAQ
Difference #847?
#847 = agents revoke device CD-5 document. #848 = bot guide self-service tier 1.
Bot disconnects the device?
No. CONNDEV-NO-REVOKE-BOT. CONNDEV847-HANDOFF humans CD-5.
Session = push notification?
No. PUSH835-REROUTE if client talks phone alerts.
Unknown device?
bot_conndev_unknown TPL-CONNDEVbot-UNKNOWN. ACCHACK841 if suspicious command.
Going further
This week: deploy CONNDEV-MAP RAG security page embed, red team ip_leak_violations audit, sync bot_conndev_unknown proactive unknown device scenario self-service test.
Enzo
July 1, 2026
