Channels
Web and app: signed-in customers
How a customer who is already signed in to your website or app is recognised by the agent without identity questions, how their identity is passed securely, and what the agent can then see and do.
On this page
A customer who has signed in to your app has already proved who they are. Asking them for a booking reference and a date of birth before answering is friction with no benefit. When a signed-in customer opens a conversation, your systems pass their identity to the agent, so the conversation starts with their account: their booking, their unit or their policy. Authenticated sessions are configured during implementation for the website and app journeys you choose.
What changes when a customer is signed in
| Not signed in | Signed in | |
|---|---|---|
| Who the agent knows it is talking to | An unconfirmed contact, until an identity check is passed | The customer your systems have identified |
| First question | "Could you confirm your booking reference and date of birth?" | "Welcome back, Leila. Is this about your motor claim from 3 October?" |
| Account details | Shared only after an identity check | Available from the start, within your rules |
| Actions | Available once identity is confirmed | Available from the start, within your rules and the customer's role |
How the customer's identity reaches the agent
Your website or app already knows who the customer is, because they signed in with your own sign-in process. When they open a conversation, your systems create a signed token: a short digital statement saying who the customer is, which only your systems can issue and nobody can alter without the change being detected. The token travels with the conversation, and your Telonic deployment checks it before the agent treats the customer as identified.
The customer's password never leaves your systems, and the agent never asks for it.
The technical detail
| Item | How it works |
|---|---|
| Token | A signed token issued by your back end (the server side of your website or app), such as a JSON Web Token (a widely used standard format for a signed set of statements about a user) |
| What it contains | Your identifier for the customer, an expiry time, the deployment it is intended for, and optionally the customer's role |
| How it is signed | With a key your systems hold. Your deployment checks the signature with the matching verification key agreed during implementation |
| What is checked | The signature, the expiry time and the intended deployment. A token that fails any check is not accepted, and the customer is treated as not signed in |
| Lifetime | Short, so a copied token is of little use. A new token is issued as the customer continues to use your site or app |
| In transit | Every connection uses TLS (Transport Layer Security) version 1.2 or higher |
| What is not shared | Passwords, and any sign-in secrets your systems use |
What the agent can see and do
Once the customer is identified, the agent looks up that customer's own records in your systems, and only theirs. A policyholder signed in to an insurer's app can ask about their own policies and claims. They cannot ask about someone else's, because the agent's lookups are made for the identified customer.
What the agent can do is also limited by the customer's role, where your systems have roles. You decide what each role allows:
| Industry | Role | What the agent can do for them |
|---|---|---|
| Property | Unit owner | Payment schedule, handover appointments, snagging items for their units |
| Property | Tenant | Maintenance requests for the unit they rent. No payment plan details |
| Travel and hospitality | Loyalty member | Their bookings, points balance and redemptions |
| Insurance | Policyholder | Their own policies and claims |
| Insurance | Broker | Status and documents for the clients the broker is authorised for |
These limits sit alongside the permissions each connection to your systems already has, set with your IT team. See Permissions.
A signed-in session as one of your identity checks
A signed-in session is one of the identity checks you can set for your deployment, alongside knowledge checks, such as a booking reference with a date of birth, and a one-time passcode sent by SMS or WhatsApp. You decide which requests a signed-in session is enough for.
For most requests, it is enough on its own. For requests you consider higher risk, such as changing the phone number or email address on an account, you can require a further check, such as a one-time passcode to the number already on record. See SMS and Matching contacts to customers.
The agent never sees or handles card details, whether a customer is signed in or not. Payments are made through a payment link from your payment provider, so card data stays with that provider.
In practice
Wadi Assurance, a motor insurer in Dubai, adds the agent to its policyholder app.
- Leila is signed in to the app. She opens the conversation, and the app's back end issues a signed token with her customer ID and the role "Policyholder".
- The deployment checks the token. The agent greets her by name and asks whether she is getting in touch about her open claim.
- She asks what is still needed. The agent looks up her claim and replies that the garage invoice is outstanding. She uploads it in the conversation, and it is attached to the claim.
- She asks to change the mobile number on her policy. The insurer requires a one-time passcode for contact detail changes, so the agent sends a code to the number on record, and makes the change once she enters it.
- The conversation, the document and the change are recorded in her customer record, with the identity checks that were passed.
What your team controls
- The website and app journeys where signed-in customers are recognised.
- Which requests a signed-in session is enough for, and which need a further check.
- The roles the agent recognises, and what each role allows.
- The key used to sign tokens, held in your own systems.
Related
- Web and app: website widget, in-app and browser voiceChannels
- Matching contacts to customersCustomer record
- PermissionsIntegrations
- Access control and single sign-onSecurity and data protection
- SMSChannels
Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.