Lock Language

Users were getting their cards and accounts locked in a variety of ways (risk, fraud, manual in-app locks, lost cards...) but product experiences didn’t help users avoid unexpected scenarios, or even a way to know what scenario they were in.

Support didn’t have resources to enhance agent insights into customer scenarios, so we designed language into the product to make the distinctions clear for a better user and support experience.

Locked account messaging architecture

Problems

  • CK Money has 6 different lock types, but in-product we called all of them "locks"

  • Members would call MS to see why their card was "locked" and agents had no way of seeing the reason or the type of lock

  • MS relied on customer input to identify the type of lock and course of action 

  • Only with manual locks can member support actually help users solve their issue

Approaches

  • Align with various stakeholders across the organization to understand lock types and support efficacy with each type

  • Develop a language system for locked accounts to differentiate lock types

  • Train member support and include documentation in SOPs

  • Help members know when they’ve manually locked the card and direct them to the control

Helping support with language clues

Content design solution

  • Reference only the user-initiated manual lock as “locked” in product (eg. “account is locked” “card is locked”)

  • A system-imposed temporary and restorable state is called "disabled" (eg. account disabled” or “card disabled”)

  • A system-imposed permanent “hotlisting” of a card is called “deactivated” (eg. “your card has been deactivated”)

Outcomes

Member support solution scores for locked accounts went up and over time we were able to reduce calls by building cautions into experiences about circumstances that could put them at risk and finding other ways we could reduce risk in our backend equations.