E-commerce
July 1, 2026
"I received a login alert from abroad." "That was me traveling, how do I confirm?" "I don't recognize this device, what should I do?" Three tickets where a login alert worries the customer without necessarily being a confirmed hack.
The e-commerce suspicious logins support covers email or SMS alerts, unusual location, unknown device, and travel reassurance. Distinct from confirmed hacking (#841): here, the customer is reacting to a preventive alert, not yet an order incident.
This guide #843 deploys policy SUSLOGIN-SUP, flow SL-1 to SL-8, and matrix SUSLOGIN-MAP. Customer service duo of the future alerts bot (#844).
Summary
Why do connection alerts generate tickets?
Shopify new accounts and apps send login alerts for new devices or countries. The customer panics or ignores them. The agent escalates everything as hacking #841 or downplays a real signal without checking recent activity.
Five typical login alert frictions
Alert received: customer doesn't know if it's legitimate
Legitimate travel: login from abroad but it was them
Not me: alert signals a third party, no fraudulent order yet
Inaccurate location: IP displayed in a neighboring city or VPN
Too many alerts: customer wants to reduce security notifications
Auth best practices recommend unusual login alerts with a clear customer procedure in case of doubt (Shopify, customer accounts 2026).
DTC Example
Sport DTC, 17 suslogin_ tickets/month. After SUSLOGIN-MAP: suslogin_reassurance_resolution_rate 94%, unnecessary ACCHACK #841 escalations -52%.
SUSLOGIN #843 vs ACCHACK #841, TWOFACT #839, MAGICLINK #837 and bot #844
Seven contents, seven distinct login security paths.
Quick matrix
#843 SUSLOGIN: login alert, location, travel reassurance
ACCHACK #841: confirmed hacking fraudulent order LOCK
TWOFACT #839: blocked 2FA distinct from login alert
MAGICLINK #837: magic link distinct from security alert
LOGIN #294: login errors without received alert
Bot #844: check and route tier 1 alerts
#843 = I received a login alert, is this normal? #841 = my account has been hacked.
Promise #843
Policy SUSLOGIN-SUP, SUSLOGIN-GATE tree, 8 macros, reassurance vs escalate matrix, KPI suslogin_reassurance_resolution_rate.
Which typologies does suslogin_* classify?
Action-oriented classifier: reassure passenger ≠ revoke session ≠ escalate ACCHACK #841.
Eight SUSLOGIN-MAP typologies
suslogin_alert_received: alert received, explanation requested
suslogin_was_me_travel: legitimate connection VPN travel
suslogin_not_me: customer denies connection, no order fraud yet
suslogin_location_confusion: imprecise IP city or VPN
suslogin_device_unknown: listed device not recognized
suslogin_false_positive: system alert, normal connection
suslogin_disable_alerts: wants fewer security notifications
suslogin_escalate_hack: strong signals, route to ACCHACK #841
SUSLOGIN-SUP Policy: agents and escalation rules
The SUSLOGIN-SUP policy establishes proportionate reassurance and escalation in case of strong signals.
Six SUSLOGIN-SUP rules
48-hour activity lookup: logins, orders, profile changes prior to conclusion
Reassure if travel is confirmed: SUSLOGIN-TRAVEL-OK macro if was_me_travel
Revoke session if not_me: log out suspicious device before escalating
ACCHACK escalation if suspicious order: suslogin_escalate_hack → #841 AH-1
Explain imprecise IP: SUSLOGIN-LOCATION before panicking
Advise 2FA: SUSLOGIN-2FA-TIP if not_me or recurrent
Response matrix (agent)
Reassurance: travel, VPN, false positive, normal alert
Mild action: revoke session, preventive password change
Escalation: unknown order, email changed → ACCHACK #841
Flow SL-1 to SL-8: standard resolution
Eight sequential steps, P3 SLA alert < 8 h, escalate P1 if suspicious order.
Flow SL-1 to SL-8
SL-1 Triage: read alert, tag suslogin_*, was it you?
SL-2 Lookup: log connections 48 h, IP, device, orders
SL-3 Educate: SUSLOGIN-LOCATION if location_confusion
SL-4 Classify: suslogin_* via SUSLOGIN-MAP
SL-5 Execute: reassure, revoke session, 2FA tip, escalate #841
SL-6 Confirm: SUSLOGIN-DONE macro exact scope
SL-7 Test: ask to confirm understanding or normal activity
SL-8 Close: KPI suslogin_reassurance_resolution_rate
Eight ready-to-paste SUSLOGIN-* macros
Clear macros on alerts, travel, and next steps.
SUSLOGIN-* Library
SUSLOGIN-ALERT-EXPLAIN: "This alert signals a login from a new device or location. If this was you, no action is required."
SUSLOGIN-TRAVEL-OK: "Login from {{location}} confirmed as legitimate. Your account is secure. Consider 2FA while traveling."
SUSLOGIN-LOCATION: "IP location is approximate. A VPN or mobile carrier may show a different country."
SUSLOGIN-NOT-ME: "Suspicious session revoked. Change your password and enable 2FA. Monitor orders for 48 hours."
SUSLOGIN-2FA-TIP: "Enable 2FA: guide #839. Reduces risk if alert is recurring."
SUSLOGIN-ESCALATE: "Compromise signals detected. Security protocol #841 activated. An agent will follow up within {{sla}}."
SUSLOGIN-ALERTS-OFF: "Security alerts reduced according to account preferences. Logins are still logged on the store side."
SUSLOGIN-DONE: "Recap: {{action}}. Contact us if there is a new alert or unrecognized order."
SUSLOGIN-GATE tree and alert configuration
Decision tree before unjustified ACCHACK escalation.
SUSLOGIN-GATE
Client confirms travel? u2192 TRAVEL-OK + optional 2FA-TIP
Not me + no suspicious order? u2192 NOT-ME revoke + 2FA-TIP
Order or email changed? u2192 ESCALATE #841 immediate
Location alone is worrying? u2192 LOCATION then ALERT-EXPLAIN
Ops alerts checklist
Document Shopify alert thresholds. Train agents: alert u2260 automatic hack. Tag suslogin_* to measure escalate false positives. Link to ACCHACK #841 procedure if escalate_hack.
KPI, QA and handoff to bot #844
Measuring SUSLOGIN detects over-escalation and under-reaction not_me.
Four SUSLOGIN KPIs
suslogin_reassurance_resolution_rate: reassured customer or clear action / total
suslogin_false_escalate_rate: % ACCHACK #841 without strong signals
suslogin_not_me_revoke_rate: % not_me with revoked session
suslogin_repeat_7d: reopening of same alert within 7 days
Bot #844 handoff
Export SUSLOGIN-MAP to intents bot_suslogin_explain, bot_suslogin_not_me. Guardrail SUSLOGIN-ESCALATE-BOT: route #841 if modified order or profile is detected.
Edge cases: Pro VPN, family, delayed alert
Three cases outside the standard flow.
Corporate VPN
Connection via datacenter IP. LOCATION + TRAVEL-OK if customer confirms telecommuting.
Family on the same account
Spouse connected from another device. ALERT-EXPLAIN + advice on separate accounts.
Alert received days later
Expanded 7-day historical lookup. If suspicious activity persists → NOT-ME or ESCALATE.
Agent training: 20 minutes SUSLOGIN
Module: lookup 48 h, alert ≠ hacking, ESCALATE only if strong signals.
Exercises
Ticket A: confirmed travel → TRAVEL-OK not ACCHACK
Ticket B: not me, no order → NOT-ME revoke + 2FA-TIP
Ticket C: alert + unknown order → ESCALATE #841
How Qstomy structures SUSLOGIN in your stack
Qstomy route suslogin_*, displays connection log for 48h and escalates ACCHACK if strong signals are detected.
Three building blocks
Routing: intent login_alert vs account_hacked vs login_error
Guardrails: ESCALATE-GATE before auto ACCHACK
Bot #844: explain tier 1 alert
FAQ and SUSLOGIN deployment checklist
FAQ
Alert = hacked account?
Not automatically. Lookup 48 h. ESCALATE #841 if order or email changed.
Difference #843?
#843 = preventive reassurance alert. #841 = confirmed compromise incident.
Client traveling, what to do?
TRAVEL-OK + optional 2FA-TIP. Do not revoke if confirmed legitimate.
7-day Checklist
D1: SUSLOGIN-SUP + SUSLOGIN-MAP + reassurance escalate matrix
D2: 8 helpdesk macros
D3: agent access to 48 h Shopify connection logs
D4: 20-min agent training
D5: suslogin_* tags + KPIs
D6: test escalate #841 vs TRAVEL-OK
D7: brief bot #844 ESCALATE-GATE
Interlinking
Enzo
July 1, 2026
