Laravel Whatsapp Widget Laravel Package

Product Decisions This Supports

• Channel expansion for markets where WhatsApp is the default inbox (LATAM, MENA, Southern Europe, SEA, Indonesia). This supports a "meet users where they already are" bet instead of another contact form. Measure it as qualified WhatsApp conversations per 1,000 sessions against form-fill rate.
• Support deflection / triage. A floating entry point that routes to a human on WhatsApp before a ticket is opened. Ties directly to a ticket-volume-reduction OKR rather than to engagement vanity metrics.
• Lightweight agent routing, bought not built. The whatsapp_agents table (name, phone, text, image, active) gives you Sales / Support / After-hours buckets with an "Online" indicator out of the box. That is a routing capability you would otherwise spec as a mini-feature.
• Internationalization roadmap de-risking. 17 locales ship already (en, pt_BR/pt_PT, es, fr, de, it, nl, pl, ar, cs, fa, he, id, ja, sk, tr). If an expansion market is on the roadmap, this is a zero-cost proof point that the surface is localized — though RTL layouts (ar, fa, he) still need QA.
• Cheap experimentation without eng cycles. position (left/right), audio, and play_audio_daily (cookie-gated, once per 24h) are config flags. Position and sound-on-load are legitimate A/B variables on a conversion surface you can ship in an afternoon.
• Build vs. buy call. Scope here is genuinely small: one migration, one model, two Blade partials, two routes, one signed-URL redirect. That's a 1–2 day build. Buy when you want it this sprint on a marketing property; build when you need click analytics, CRM handoff, or consent gating — none of which ship here.
• Architecture decision it should force: because agent data is a table plus a token-gated JSON endpoint, the widget is decoupled from the layout. That is an argument against hardcoding a wa.me link and for keeping the data in a model you can later serve to a headless front end or mobile app.

When to Consider This Package

Adopt when:

• You are on Laravel 11/12/13 and PHP 8.2/8.3, and the surface is a marketing or brochure site — not checkout, not an authenticated app shell.
• You need multi-agent listing, locale coverage, and a floating widget in one sprint, and you're comfortable running a published migration and owning the views.
• You accept a single-maintainer dependency on a low-criticality surface and are willing to vendor/fork it if it goes quiet.
• Your WhatsApp presence is click-to-chat. You are not trying to send templated notifications or read delivery receipts.

Look elsewhere, or build, when:

• Maturity signal is the blocker. 9 stars, 0 dependents means no production battle-testing. Do not put this on a revenue path. Also verify the tagged release: the listed last release (2026-10-17) is future-dated, so confirm the version you actually pull.
• Auth model doesn't fit anything sensitive. The JSON API authenticates with ?token={key} as a query parameter — fine for a public agent listing, wrong for anything with PII, and it will land in access logs. Don't reuse it as a pattern.
• You need measurement. Click tracking, conversion attribution, CRM/lead handoff, and consent management are absent. The redirect auto-forwards via JS, so instrumenting intent requires custom work — budget for it.
• No admin UI. Agents are managed through Eloquent or your own Filament resource; the package doesn't ship a panel. If non-technical staff must edit agents, that scope is yours.
• You need real messaging. This is a deep link, not the WhatsApp Business Cloud API. No inbound messages, no templates, no delivery status, no omnichannel inbox. If support needs a shared inbox, this is not a substitute.
• One number is all you have. A static wa.me link in a partial is less code and less dependency than this package.
• Compliance posture is strict. The only cookie is for audio playback; there's no consent gate around it and no rate limiting documented on the routes.

How to Pitch It (Stakeholders)

For executives: A one-sprint, no-contract experiment to open WhatsApp as an inbound channel on our public site. Because it is click-to-chat, there are no per-conversation messaging fees and no WhatsApp Business API onboarding — we are handing the visitor off to their own WhatsApp client. It ships already localized into 17 languages, so it doubles as a low-cost signal for expansion markets. Success criteria to agree up front: incremental qualified conversations and a measurable dip in contact-form/ ticket volume, with a kill decision at 60 days if neither moves.

For engineering: One Composer dependency built on spatie/laravel-package-tools, following the standard Laravel package conventions — service provider, publishable config/migrations/views, named routes, signed-URL redirect. Blast radius is two @include partials in the layout; removal is an afternoon. Two things to plan for: (1) treat it as vendored code and be ready to fork — it has no meaningful downstream adoption, so we are the test suite; (2) it is not a foundation. Analytics, consent, and the admin UI for agents are our work, and the query-param token on the JSON endpoint should not become a house pattern. Recommended posture: adopt behind a small internal wrapper so we can swap the implementation without touching layouts.