Your client portal sits at 40% adoption. Support gets five password reset requests per week. New clients sign up, forget credentials after four days, and never come back. The problem isn't the portal itself—it's the password. We tested two onboarding flows over six months. The first: traditional email invite with a form field. The second: a one-click passwordless link delivered via SMS at signup, then WhatsApp for returning visits. The second doubled adoption to 80% and cut support password tickets by 90%. This isn't magic. It's friction removal. Here's how we did it, what we measured, and the exact support savings. Why passwords kill client portal adoption A password creates three failure points: Signup friction: Clients create a password they'll never remember. First return: They can't recall it. Support ticket or password reset email. Abandoned session: They log out (or the session expires), return next week, and can't get back in. Each failure point compounds. Of our 500 client accounts invited to the portal over six months, only 200 ever logged in. Of those, only 80 returned in week two. A 40% adoption rate and 60% churn. Support spend on password resets: ~₹15K per month (5 tickets × 20 mins each × our loaded rate). Over a year, that's ₹180K burned on a single preventable problem. The insight: Passwords don't protect client data in a low-stakes context—invoices, bookings, contracts. They just create friction. You're not Facebook. You don't need them. Passwordless links: the flow that works Instead of a password field, clients receive a one-click magic link. Here's the flow: Client signs up (name, email, phone). System generates a token (UUID, 24-hour expiry). SMS link sent immediately: "Your portal is ready: [your-domain.com/login/abc123xyz]. Link works for 24 hours." Client clicks. Logged in instantly, no password needed. For return visits, same flow: email or WhatsApp says "Need to check your invoice? Here's your link." No password manager confusion. No reset emails. No forgotten credentials. One click, and they're in. We piloted this with 100 new clients in January. Adoption hit 80% by day 7. By day 30, 68% had returned at least twice. Compare that to the 40% ever-logged-in and 10% repeat-visit rate from the old flow. SMS at signup, WhatsApp for returns The channel matters. SMS works at signup because it's immediate and intrusive enough to be noticed. But asking clients to retrieve an SMS every time they want to view an invoice is annoying. After the first login, we switched to WhatsApp for returning visits: Client saves the portal bot as a contact. They message "invoice" or "booking," get a link back instantly. Or we proactively send: "Your invoice is ready: [link]". Click, logged in, done. This mirrors how clients already use WhatsApp—as a direct-access tool. No new app. No new password to remember. They don't feel like they're logging into a system; they feel like they're messaging you. Adoption for repeat visits jumped to 78% with WhatsApp delivery. Clients who received an invoice link via WhatsApp opened it within 4 hours, 63% of the time. Clients who got an email with a link? 24 hours, 41% of the time. The implementation: no new platform required You don't need a specialized passwordless auth platform. If you have a unified messaging system that handles SMS and WhatsApp , you have the infrastructure. Here's the technical backbone: Generate a short-lived token on signup (UUID, encrypted with a secret key, 24-hour expiry). Store it in your database with the user ID and a used/unused flag. Create a login route: /login/[token] . It validates the token, checks expiry, sets a session cookie, and redirects to the dashboard. For returning users, show a "Send me a link" button. It generates a fresh token and dispatches SMS or WhatsApp via your messaging API. Token rotation: After use, mark the token as used. Tokens are single-use and expire after 24 hours. If you're using a modern backend (Node, Python, Go), this is 4–6 hours of engineering work. If you're on a platform with built-in messaging and auth , it may be a checkbox. Security notes: Tokens must be cryptographically random and at least 32 bytes (256 bits). Always send over HTTPS. Token should include a hash of the email or phone to prevent enumeration attacks. Log token generation and use for audit trails. Rate-limit token generation (max 3 requests per phone number per hour) to prevent SMS spam. Measuring the support cost savings Track three metrics: Adoption by day 7: % of invited clients who logged in at least once within a week. Repeat visits by day 30: % who returned at least twice in the first month. Password reset tickets: Count and cost per month. Our baseline (traditional flow, 500 clients invited over six months): Day 7 adoption: 40% Day 30 repeat: 10% Password reset tickets: 5 per week (~₹15K/month) After rolling out passwordless links (next 500 clients, January–June): Day 7 adoption: 80% Day 30 repeat: 68% Password reset tickets: 0.