How omotto knows who a customer is: verification and names
omotto separates what someone says about themselves from what they have proved. This guide maps the different kinds of evidence, what they can unlock, and how omotto chooses a customer’s name. Use it when a familiar-looking profile still needs a code, or when the name your team sees differs from the name used in chat.
How it works
Section titled “How it works”Evidence: from a claim to proof
Section titled “Evidence: from a claim to proof”A phone number typed in a message is a claim. A successfully entered code proves control of its destination. Neither a familiar name nor a matching order automatically proves ownership of a whole store account.
The table starts with weaker evidence and moves toward proof. The last two rows answer a separate question: does this person have an account in your business’s system? They are not higher verification scores. Recognized can be weaker than Verified.
| Evidence or level | How the customer reaches it | What it can unlock | What it does not unlock |
|---|---|---|---|
| A detail said in chat | The customer supplies a name, phone number or email. | A detail to use in the conversation; a possible account lookup if you explicitly allow unproven lookups. | Proof of control, private order access or membership just because they said so. |
| Evidence from the channel | The customer writes through WhatsApp with a confirmed account identity. When a phone number is available and confirmed, that number can also be used. | WhatsApp can satisfy identity-verification checks without a redundant code. A confirmed phone can support access to orders carrying it. | Control of an unrelated email or phone, or ownership of every store account. Other channels do not receive this automatic WhatsApp proof. |
| A match from store orders | Contact details or checkout evidence suggest a store customer. | A clue for staff, such as a possible name or store history. | A same-person link or permission to disclose private records from the match alone. This is not the same as choosing Recognized for an action. |
| Resource verified: proof for one order or record | Qualifying proof is tied to that particular record; stronger identity proof can also meet this requirement. | A requirement scoped to that record. | Other records or membership. The order-only proof flow is not currently available; knowing an order number is not a verification method. |
| Verified: control has been proved | The customer completes a code to a phone or email, or has qualifying WhatsApp channel proof. | Actions that require verification, if their separate ownership and timing checks also pass. | Automatic membership, every store account, every action, or permission to skip approvals. |
| Recognized: an account matches | An enabled user source returns an eligible, current account match. This may use an unproven detail if you allow it. | An action you deliberately set to accept Recognized. | Proof that the person in the chat owns the matching email, phone or account. |
| Verified user: proof plus an account match | Qualifying verification and a current account match tied to that person’s verified detail both pass. | An action requiring Verified user, including any selected source or role restriction. | Access to unrelated accounts, actions that are off, or an exemption from other safety checks. |
A user source checks your business system for an account, such as a student account or a store customer account. See User identification for proof versus membership, source setup and the complete access-choice table.
What that means for everyday features
Section titled “What that means for everyday features”These are built-in starting rules, not a promise that every customer can use every feature. Features must be available and enabled. Where a verification control is offered, you can change its requirement.
| Feature | Starting rule and important limit |
|---|---|
| Order lookup | No extra skill-verification requirement by default, but ownership is still checked. A number alone is not enough. A verified phone or email carried by an order can allow that order’s status and contents without proving the whole account. In that limited case, the order email is masked and the store’s order-status-page link is withheld. |
| Find my orders | Requires qualifying identity proof by default; an earlier proof can count if still valid. Account-level access is separate from access to individual orders. Every order, with addresses needs account-level authority, not merely a store match. Search limits can still leave out orders. |
| Store credit lookup | Reads balances for accounts the customer has account-level access to. A delivery or billing-detail match alone does not reveal that account’s balance. Verification of an unrelated detail is not enough. |
| Order changes and other store actions | The shared verification default for these writes is qualifying identity proof, with a still-valid earlier proof accepted. Order ownership, the store’s change rules and approvals still apply. Item edits start with an account-level ownership requirement; some other change types accept a verified detail on the order. You can change the applicable requirement in the store’s controls. See Shopify actions and approvals. |
| Conversation memory across channels | Requires identity proof in the current conversation by default. The current channel’s own history remains available without that cross-channel check. Linked profiles and group-shared history have separate sharing rules. |
| Appointments | The default is qualifying identity proof; a still-valid earlier proof can count. This does not expose everyone’s calendar. The customer profile distinguishes changes to appointments booked for this customer from read-and-cancel-only access when new booking or rescheduling is unavailable. See calendar availability. |
| An operation in Custom API | This is a connection to your own business system. Each operation has its own access choice; see operation settings. Resource verified currently requires identity-level proof in chat because no particular record is passed to that check. A membership match alone cannot satisfy Verified user. |
If proof is missing, the bot can ask the customer to complete a code before retrying the protected action. It does not send a code to everyone on arrival. A code does not fix a missing account, an unavailable service or a denied role.
For the actual customer, read What the assistant will share in their profile. Its scope and explanation matter: a row for one number or channel is not a promise of access in every chat. It is an explanation, not a switch that grants access.
Same person, related people and adopted store accounts
Section titled “Same person, related people and adopted store accounts”These are connections, not extra verification levels:
- Identity linking says that profiles in different channels belong to one person. Their histories can become shared context. Links can come from your team or eligible automatic matching; not every automatic link involves a fresh code. Use the linking guide to review or separate profiles.
- A customer group connects related but different people, such as family members. Their profiles stay separate. Sharing follows the group’s rules, not an assumption that they are one person.
- Store-account adoption associates an additional store account with the customer. The bot judges the conversation and evidence connecting an order to verified contact details; the system checks that the supporting proof is still usable. This can give account-level access, including order-history and credit reads, subject to each feature’s checks. It does not prove control of the account’s own phone or email, automatically move credit, or replace the default account for existing store actions. The association follows the same-person profiles, not other group members. See adopted store accounts and Undo.
How omotto chooses a name
Section titled “How omotto chooses a name”A name is useful for addressing someone. It is not identity proof. The bot judges whether a customer has introduced themselves; the system stores that name separately from proof of phone or email control.
For the name shown to your team, the usual priority is:
- A name your team set on the profile.
- A name the customer stated in chat and the bot recorded.
- Live channel profile names, with the most recently active first.
- Imported profile names, with the most recently active first.
- A Shopify customer name with supporting account evidence.
- An eligible checkout name, for staff display only.
- An older stored name.
- A phone number, email or other suitable contact identifier.
- A generic label such as “Customer #123”.
Same-person links can also supply names from linked profiles. A name set or stated on the profile itself takes precedence over a linked profile’s name. In the bot’s current conversation, the current channel profile takes priority within the live-profile tier.
The staff label always has a fallback. The name supplied to the bot for addressing the customer is different: phone numbers, emails, identifiers and placeholder labels are withheld as names. An automatic profile label is only a hint; the bot is instructed to use it only if it reads like a person’s name, not to claim that the customer introduced themselves that way. If there is no suitable name, the bot need not use one.
A checkout payer’s name can appear to staff with a staff display only caveat. That checkout source is never used as the name for addressing the customer or as proof of who is chatting. An independently stated or otherwise eligible name can still be used.
A customer saying a different name does not replace a name your team set. Use Edit name in the profile header to correct it, or Reset to automatic to remove the local name choice. Reset also removes a stored chat-given name; it does not erase names in the connected services. See the name controls and editing steps.
Where to find it
Section titled “Where to find it”Customers → All customers → open a customer profile for Who this is, How we know and What the assistant will share; Customers → User identification for sources. For access requirements, open the relevant skill’s rule in Bot → Handbook → What [assistant name] does when… → Who is this for and review Required verification, or open the Custom API operation.
Set it up
Section titled “Set it up”- Open the customer profile described above and compare the identity evidence with the sharing explanation.
- Follow the user-source guide if an action must distinguish a verified person from a member of your business’s system.
- Review the relevant action’s requirement and proof timing. Do not lower them just because a name or store match looks familiar.
There is no single customer-level switch that unlocks everything.
Settings
Section titled “Settings”How recent must the proof be?
Section titled “How recent must the proof be?”In a skill’s Who is this for control, Required verification chooses the proof needed and Proof recency chooses when it must have happened.
| Proof recency choice | Meaning |
|---|---|
| Any time | A still-valid earlier proof can count. It does not revive an expired or invalid proof. |
| This conversation | Proof must have been recorded in this conversation, not just another conversation with the same customer. |
| Within a set time | Proof must be no older than the number of minutes you set. Even a WhatsApp customer can need a fresh code when the last qualifying proof is too old. |
The defaults differ by feature, as shown above. Recognized is an account-match condition, not a timed code proof. Verified user requires both its proof timing and a current account match. A source that is unavailable, disabled or no longer matches cannot be repaired just by entering another code.
Phone confirmation validity (days) is a separate matching setting. Its default is 120 days; 0 means unlimited. It governs when an old phone association can identify someone on its own, not whether a chat message can be delivered. See phone validity and profile matching before changing it.
What happens when…
Section titled “What happens when…”Someone types another person’s email
Section titled “Someone types another person’s email”The email remains a claim until control is proved. If you explicitly allow unproven user-source lookups, a matching account may meet an action set to Recognized. It does not make the speaker Verified or Verified user. Use the source guide’s disclosure warning when deciding whether to allow this weaker check.
A WhatsApp customer has no phone number available
Section titled “A WhatsApp customer has no phone number available”omotto can have proof of their WhatsApp account identity without a usable phone number. A phone-based account lookup still needs a phone; the account identity cannot stand in for one. The customer may need to verify a phone or email separately.
Verification happened in an earlier conversation or expires
Section titled “Verification happened in an earlier conversation or expires”An earlier proof may meet Any time, but not This conversation. An expired proof no longer counts. A time-limited requirement can ask for a fresh code even while the profile still shows past verification. Inspect the proof date and the action’s requirement rather than assuming the profile’s history unlocks the action forever.
An action’s verification check uses the proof that is valid now, not an earlier status. If store sign-in renews while the bot prepares a reply and the new proof meets the action’s requirements, the earlier proof expiring is not a reason to ask for another code.
Two profiles turn out to be the same person
Section titled “Two profiles turn out to be the same person”Review them through identity linking. Confirming the same person can join access to their histories; it is not just tidying the directory. If they are different people who share details, keep separate profiles and consider a customer group instead.
A gift order carries another person’s phone
Section titled “A gift order carries another person’s phone”A verified phone appearing on an order can support access to that order. It does not by itself prove that the recipient owns the buyer’s store account. Do not confirm a same-person link just because the details match. Store-account adoption is a separate, evidence-based decision, not an automatic consequence of receiving a gift.
The bot uses the wrong name
Section titled “The bot uses the wrong name”Inspect Where names came from in the name editor. Correct a staff-set name there; the customer cannot overwrite that choice by introducing themselves again. If the wrong name comes from a linked person’s profile or a store match, review the connection too. Renaming is not a way to correct mistaken access.
Troubleshooting
Section titled “Troubleshooting”- The profile looks familiar, but the bot asks for a code: compare the action’s requirement, proof date and account ownership. A staff-visible store match is not permission.
- The customer entered a code but an action is still unavailable: check the required source and roles, the actual account or order, and whether the feature is enabled. Do not keep asking for the same code to solve a membership or connection problem.
- A number appears instead of a name: the team-facing label has fallen back to a contact detail. The bot should not use that detail as the person’s name. Set a real name with the profile’s name controls if you know it.
- The expected panel or control is missing: ask the workspace owner to check your permissions and enabled features.
If the evidence and sharing explanation still appear inconsistent, contact omotto support with the feature, displayed warning and time of the problem. Do not send passwords, verification codes or unnecessary customer details.