Sales Management Laravel Package

Product Decisions This Supports

• Feature prioritization on lead engagement: The addition of preferred_contact_method and preferred_contact_time makes contactability a first-class, structured data point rather than something buried in free-text notes. This unblocks roadmap items around outreach sequencing, call-time optimization, and channel mix reporting (email vs. phone vs. SMS).
• Build vs. buy: These fields arriving upstream means we do not need to custom-build lead preference capture, validation, controller wiring, and UI display. Treat the package as the source of truth for the lead schema and reserve in-house effort for the differentiated layer (scoring, routing rules, analytics).
• Use cases this enables immediately: Contact-center and sales teams can respect customer-stated channel and time preferences, which is a concrete compliance and CSAT lever. It also feeds simple operational reporting — "what share of inbound leads prefer phone, and in what window?"
• Data model decisions: Two new nullable-by-default fields on leads are a cheap, reversible schema change. Low migration risk, so this can be piloted on a single funnel or tenant before broad rollout.
• Scope discipline: Note that the release touches model, controller, Blade/JS component, and compiled asset manifest — a full vertical slice. That is convenient, but it also means the package owns both the data contract and the presentation. If we intend to build a custom lead UI, we should confirm which parts we can override cleanly rather than forking.

When to Consider This Package

Adopt when:

• You are running Laravel and want lead capture, storage, and basic contact-preference display without writing your own model/controller/view stack.
• Your team is small and the value is in time-to-market rather than bespoke UX — you want the vertical slice (schema + controller + component) delivered together.
• Your contact-preference requirements are simple: one method, one time window per lead. If you need multiple windows, per-channel opt-in/opt-out history, or timezone-aware scheduling, this schema is likely too thin and you should look at a dedicated CRM or communications platform instead.
• You can live with the package's release cadence and asset pipeline (each release appears to version manifest.json assets, so expect to re-publish assets on upgrade).

Look elsewhere when:

• You need auditable consent records, TCPA/GDPR-grade provenance, or per-channel suppression lists — a preference string field is not a consent system.
• You require timezone handling, recurring availability, or calendar integration for "preferred contact time." A single stored value will not survive contact with real scheduling.
• Your front end is not the package's component — heavy reliance on the bundled LeadItem component creates coupling risk across releases.
• You need guarantees about semantic versioning. The 1.1.x patch cadence carrying new features suggests features and fixes ship in the same channel; plan for regression testing on every bump rather than trusting patch-level stability.

How to Pitch It (Stakeholders)

For executives: A small upstream release adds two fields that let us record how and when a lead wants to be contacted, and surfaces them in the UI. The business value is straightforward — better outreach timing, fewer unwanted calls, and a foundation for channel-performance reporting. Cost is near zero: no custom development, no migration risk, no new vendor. The main caveat is scope: this is preference capture, not consent management, so compliance still needs its own solution.

For engineering: Non-breaking additive change — two new lead attributes persisted through ContactsController and rendered in LeadItem, plus regenerated front-end assets. Two things to verify before upgrade: (1) confirm the schema change is nullable/backfill-safe on existing lead rows, and (2) re-publish and cache-bust the updated manifest.json assets as part of deploy. Because features are landing on patch versions, add this to the standard regression pass rather than assuming a frictionless composer update. Also flag that the package now owns both the data contract and the presentation layer — if we plan a custom lead UI, we should decide now whether to override or fork before the coupling deepens.