Crm Hangouts Call Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for in-CRM communications: The 1.0.0 notes spell out the full "click-to-call from a record" workflow: a hover-revealed action button next to email/phone fields (alongside Send Email and Log Call), call initiation, OAuth consent on first use, and a Log Call dialog that opens when the call starts and auto-populates date/time, number-or-email dialed, and duration when it ends. That is a realistic MVP footprint and a useful baseline when scoping an embedded-communications feature.
• Cost model / market gating: This is the most decision-relevant new detail. Calling emails and US/Canadian numbers is free; other numbers incur per-minute charges drawn from a Google Wallet balance, and calls fail to start if the balance is insufficient. That is a direct input to the roadmap question of whether telephony ships domestically in v1 and internationally in phase 2, and to whether we want prepaid-balance mechanics or a per-seat/per-minute billing surface at all.
• Build vs. buy framing: Unchanged and reinforced. The 1.0.0 label is the initial release of a 2016-era, single-maintainer, effectively unmaintained asset (1 star, 0 dependents, no subsequent release). It informs the decision to build a thin internal integration rather than adopt a dependency. Treat it as a design reference, not a package to vendor.
• Activity/entity schema decisions: The auto-capture contract is now explicit — date & time, target (number or email), and duration are written back automatically, with free-text notes captured during the call. That is the minimum viable activity record for a call event and the starting schema for our own activity table.
• UX pattern decisions: Two details worth copying or deliberately rejecting: (a) note-taking during the call, not after — the dialog opens at call start; (b) presence-dependent "calling" over an email address — a Hangout only connects if the recipient is online, otherwise it degrades to an emailed invitation. The second is a meaningful product constraint: email-as-dial-target is really "start a chat/meeting," not telephony, and should be positioned separately in our UX.
• Integration architecture decisions: Surfaces the real cost centers early — per-user OAuth consent and permission prompts, activity schema changes, call-record ownership, audit logging, and (new) balance/usage monitoring and failure handling when funds are insufficient. That is the input for estimating effort and for deciding whether the CRM or the communications provider owns the call record.
• Ecosystem-fit decision: Confirms the platform mismatch. This is a Symfony/OroPlatform bundle, not a Laravel package. For a Laravel roadmap it supports using Laravel-native primitives (HTTP client, queues, events, notifications) against Google's REST APIs rather than porting bundle code.

When to Consider This Package

Consider it (as a reference, not a dependency) when:

• Your team is on OroPlatform/OroCRM or Symfony and needs precedent for wiring a Hangouts/Meet action into an entity detail view, including the hover-action placement beside existing record actions.
• You need a worked example of the activity-logging contract — how a third-party call becomes a first-class CRM activity record tied to an account/contact, including auto-populated duration and in-call notes.
• You're running a timeboxed discovery spike to sanity-check scope for an in-app calling feature and want prior art, particularly for the pricing/free-tier and OAuth consent story.
• You require fully self-hosted or legacy-compatible behavior and are evaluating what an older OAuth-era integration implies for migration.

Look elsewhere when:

• You are on Laravel. This package will not install or work as-is; there is no service provider and no Laravel-compatible dependency graph. Use Google's current REST APIs (Calendar/Meet) behind a Laravel service class instead.
• You need maintained code, security patches, or support — the 1.0.0 release is the original publication, not a modernization; no release since 2016, negligible adoption, and Google's auth and Hangouts/Meet surface have changed substantially since.
• You need modern capabilities: Meet REST API, recording, transcripts, webhook-driven call events, per-tenant OAuth with revocation handling, or usage/balance APIs for cost controls.
• You need vendor flexibility — a Hangouts-only integration locks you in, and its pricing is tied to Google Wallet. Prefer a provider-agnostic interface (Twilio, Vonage, Zoom, Meet) behind an internal abstraction.

How to Pitch It (Stakeholders)

One-line summary: A small, decade-old OroCRM bundle that embedded Google Hangouts calling into CRM records — valuable to us as a scope and cost reference, not as software to adopt.

For executives: This is not a build-vs-buy decision in the usual sense — the library is unmaintained and effectively unused, so there is no support or security posture to inherit. What it gives us is a cheap, low-risk way to pressure-test the scope and unit economics of an in-app calling feature before we commit engineering time. The 1.0.0 notes confirm the shape of a credible MVP: call from a record, note-taking during the call, automatic duration logging — and they also show the commercial catch, namely free domestic (US/Canada) calling with metered international usage against a prepaid balance. Recommend a short, timeboxed spike (days, not weeks) and a build decision: our own thin integration over current Google APIs, behind a provider-agnostic interface so we are not tied to one vendor or one billing model.

For engineering: Do not vendor this. It targets Symfony/OroPlatform, predates modern OAuth and Meet APIs, and has no maintenance. Read it for two patterns: the hover action on contact fields and the call-lifecycle activity write-back. Then implement in Laravel with the Google REST APIs wrapped in a service layer, an event/webhook-driven job to populate duration and end-time (do not rely on a client-side dialog to capture it), queued jobs for post-call processing, and a webhook endpoint for call lifecycle events. Budget the real effort against OAuth consent per user, activity schema, audit logging, and usage-cost monitoring / insufficient-funds failure paths — not against the integration itself.

Recommendation: Reference only. Spike, extract the pattern and the pricing model, build internally.