Wanna Speak Bundle Laravel Package

Product Decisions This Supports

• Channel expansion / roadmap: Informs whether to add a voice channel (outbound campaigns, click-to-call, IVR menus, appointment reminders, verification calls, customer reactivation) to a product that today is likely email/SMS/CRM-only. The package maps the vendor's functional surface — auth, campaign creation, contact list upload, call triggering, and status/reporting — which is the same surface you would scope in a PRD.
• Build vs. buy vs. wrap: Shows the concrete integration shape for buying telephony from a provider (WannaSpeak, a French vendor) instead of building telephony infrastructure. Useful for estimating integration effort, not for estimating run cost.
• Vendor evaluation: As a reference implementation it reveals the WannaSpeak API's contract and ergonomics — request/response models, sync vs. callback-based status, error handling. That feeds a scoring of WannaSpeak against Twilio, Vonage, Sinch, or OVH on DX, coverage (France/EU), pricing, and compliance (call recording consent, DNC lists, GDPR).
• Architecture decisions: Supports the call on whether to depend on a vendor SDK bundle directly, or to introduce your own thin abstraction layer so providers can be swapped for pricing or coverage reasons.
• Feature prioritization input: A low-maintenance integration here means per-feature cost is mostly vendor fees plus a small adapter — which makes small, contained voice features (click-to-call in a CRM, one-off reminder campaigns) economically testable before committing to a full voice platform roadmap.

When to Consider This Package

• Framework fit first: This is a Symfony bundle, not a Laravel package. Adoption only makes sense on a Symfony application already standardized on WannaSpeak; Laravel teams would be pulling in a foreign service container contract.
• As a reference, not a dependency: Reasonable to read for API shape, DTOs, and endpoint coverage during a discovery spike — especially if you must ship a WannaSpeak integration quickly and want a head start on the request/response mapping.
• Maintenance signals are disqualifying for production: archived repository, zero stars, zero dependents, last release September 2021. Expect no fixes for PHP 8.x deprecations, no security patches, no upstream API drift handling, and no support if WannaSpeak changes auth or endpoints. There is no community to de-risk the dependency.
• Where your own client is cheaper: If the integration is a handful of endpoints (place a call, upload contacts, read a campaign report), a thin HTTP client (Guzzle/Saloon in Laravel, HttpClient in Symfony) with your own tests is lower total cost than adopting an abandoned bundle and owning it.
• Look elsewhere if: you need multi-provider failover, inbound IVR with complex state machines, recording/consent management, or SLAs. In those cases use a maintained vendor SDK or a telephony abstraction layer, and treat this repo only as documentation.
• Also look elsewhere if the vendor is not already chosen. Zero dependents is a signal that this integration path is not widely validated; do not let a sample bundle drive a vendor commitment.

How to Pitch It (Stakeholders)

• For executives: Voice is a candidate channel for reminders, verification, and reactivation campaigns, and buying it from a provider like WannaSpeak avoids building telephony. This repository is a small, archived sample integration — it tells us what the vendor's API looks like and roughly how much glue code is required, but it is not a dependency we should build a revenue feature on. Recommendation: fund a short spike plus a thin in-house client, and decide the vendor on pricing, French/EU coverage, and compliance rather than on the existence of this bundle.
• For engineering: Treat WannaSpeakBundle as a reference implementation only. It is a Symfony bundle, last released in 2021, archived, with no dependents — assume PHP 8 incompatibilities, no CI guarantees, and stale API coverage. Extract the endpoint/DTO map, then implement a minimal typed client behind our own interface so the provider is swappable, with contract tests against the live sandbox.
• For product/GTM: A contained adapter keeps the per-feature cost low, so we can pilot one voice use case (e.g., click-to-call or appointment reminders) with a measurable success metric before committing roadmap capacity or a multi-year vendor contract. The decision gate is pilot conversion/answer-rate and cost per successful call, not integration completeness.