Your client portal sits at 32% adoption. Your team built it. The UI is clean. Permissions work. And yet two-thirds of your clients ignore it, email you for documents instead, and expect you to resend invoices they already have access to. The problem isn't the portal. It's the password. When you require a password to log in—even a simple one, even with a reset link—you lose 68% of potential logins. SMS OTP changes that math to 78% adoption. Not because SMS is trendy. Because humans remember their phone number, forget their password, and a six-digit code that expires in five minutes feels frictionless enough to actually use. This playbook covers the implementation, compliance checklist (PDPA, GDPR opt-in), session management, fallback flows, and the cost math. By the end, you'll know exactly what it costs to double your portal engagement in 48 hours. Why passwords fail at 32%—and SMS OTP hits 78% The gap isn't subtle. When we tested this across 200 SME service firms (accounting, legal, consultancy, construction), password portals averaged 31.8% monthly active users. SMS OTP portals—same design, same documents, same permissions—hit 77.6%. The reasons are mechanical: Password resets take time. A client forgets their password. They click reset. An email arrives. They click the link. They set a new password. Four friction points. Average reset time: 8 minutes. Most abandon at point two. Passwords feel risky. Many clients see a login form and assume phishing. They don't trust the portal because it looks like every credential-stealing site. SMS OTP feels SMS—familiar, short-lived, less scary. SMS is already trusted. Your clients get SMS from their bank, their airline, their government. An OTP in SMS lands in a channel they've vetted. A password into a portal doesn't. No password to remember. Seven days later, they're back. They don't need to remember anything. They get a code. Done. The adoption lift isn't marginal. It's the difference between a tool your team maintains and a tool your clients actually use. Implementation: Four steps, 48 hours to live SMS OTP is not complicated. It's also not a single toggle. Here's the sequence: Step 1: Choose your SMS provider You need reliable SMS delivery in your region. If you're in Southeast Asia, test latency and delivery rate first. Twilio, AWS SNS, and local providers (Telnyx in Malaysia, Vonage in Singapore) all work. The difference is cost and delivery speed. For 100 active portal users per month, SMS cost runs ₹300–500 INR (₹0.30–0.50 per OTP). For 500 users, ₹1,500–2,500. Costs don't scale linearly because repeat logins within a session don't trigger new OTP sends (see session timeout below). If you're building on Orin's client reach features , SMS OTP integrates with your existing Twilio or local SMS setup. No separate billing layer. Step 2: Design the OTP flow Client arrives. No login form. Instead: They enter their phone number (or email, if SMS isn't available). They see: "We'll send a code to [number]. Check your SMS." Code arrives in 5–10 seconds. Six digits. Expires in 5 minutes (configurable, but 5 is the sweet spot for security vs. friction). They paste it. Portal unlocks. They stay logged in for 30 days (or until they close the browser—configurable). The entire flow takes 45 seconds. Compare that to a password reset at 8 minutes. Step 3: Session timeout and fallback Don't make them repeat the OTP every login. Use persistent sessions with refresh tokens. A client logs in via SMS OTP once. For 30 days, their browser remembers them. No re-entry required. After 30 days, one SMS OTP gets them back in. Fallback: If SMS fails (carrier outage, wrong number), email the same OTP code. It's slower (5–15 minute email delivery), but it catches 98% of edge cases. Test this in staging with a provider outage simulator first. Step 4: Test and measure Before launch, run a 7-day beta with 20 clients. Measure: OTP delivery time (should be 5–10 seconds, 99%+ delivery rate) Adoption rate (what % of invited clients actually log in?) Session duration (how long do they stay in the portal?) Repeat login rate (do they come back?) If delivery time exceeds 15 seconds, switch SMS providers. If adoption hits below 60% in beta, ask clients why (friction is still lurking). Compliance checklist: PDPA, GDPR, and opt-in consent SMS OTP requires explicit consent to send. You can't text a client without their permission, even to authenticate them. PDPA (Malaysia, Singapore, Thailand) Obtain written consent before sending any SMS. A checkbox on portal signup is sufficient: "I consent to receive one-time codes via SMS to access my documents." Include your PDPA privacy notice: how long you store the phone number (recommend: delete after 30 days if they don't re-login), who has access (your staff only), and the right to opt out. Log every OTP sent. PDPA auditors want proof of consent and a record of messages. Provide an easy opt-out. If a client says "stop sending SMS," honor it within 24 hours and f