Filament Help Requests Laravel Package

Product Decisions This Supports

• Build vs. buy for in-product support capture. This package is a credible "buy" (adopt-and-configure) answer to the recurring "should we build our own feedback/help widget?" question. v1.1.0 closes the biggest functional gap that would otherwise justify a custom build: rich, annotated visual context on first contact, not just a text box.
• Support-friction roadmap bets. Screenshot annotation with numbered pins and per-pin notes directly attacks the highest-cost part of a support cycle — the clarification round-trip. This is a measurable bet: track median replies-to-resolution and "% of requests resolved without a follow-up question" before/after rollout.
• Bug triage quality as a product outcome. Pasted/dropped screenshots plus structured notes improve the fidelity of what engineering receives, and the existing GitHub issue integration means the artifact lands where engineers already work. That makes "reduce time-to-reproducible-bug" a defensible roadmap line item rather than a support-team nicety.
• Scope decisions on the request workflow itself. Configurable storage.max_files (default 5) is a product-facing policy knob, not just a config value: it's the trade-off between storage cost/abuse and users having enough room to show multi-step bugs. Treat it as a decision to be made deliberately, not left at default.
• Prioritising in-admin vs. external support tooling. Because requests, replies, and status updates live in the same admin panel the team already uses, this supports deferring investment in a standalone helpdesk for internal/low-volume scenarios.
• UX pattern choices in the widget. The "My Requests" accordion (one thread open, notification-linked request auto-opens) is a small but real onboarding/navigation decision that affects whether users find their existing thread or file a duplicate. Worth instrumenting duplicate-request rate.
• Upgrade scheduling as a roadmap commitment. v1.1.0 ships a migration and renames Livewire properties (screenshot/replyScreenshot → arrays). That's a scoped engineering task to slot in, plus a check on whether anyone has extended or test-covered the widget.

When to Consider This Package

Consider it when:

• The product is already a Laravel app running Filament; the cost of adoption is a composer require, a migration, and a config publish — near-zero integration surface.
• Support volume is low-to-moderate and handled by the same people who administer the panel (internal tools, B2B back-offices, early-stage SaaS).
• Visual context is genuinely the bottleneck — UI bugs, layout issues, configuration errors — so annotated screenshots move resolution time materially.
• You want requests to flow into existing engineering channels (email, GitHub issues) rather than adding a new SaaS vendor, procurement review, and data-processing agreement.
• You are comfortable owning migrations and vendor-published config, and can absorb occasional breaking changes on a minor version.

Look elsewhere when:

• The product is not on Filament, or is a public consumer app where help must live outside the admin panel and work on mobile without a browser extension.
• You need SLA management, routing/assignment rules, CSAT reporting, or a knowledge base — this is a request widget, not a helpdesk.
• Screenshot annotation on customer-submitted images creates a data-handling obligation you can't meet (PII visible in screenshots, retention policy, redaction requirements). Annotating and storing images is a compliance decision, not just a feature.
• You need high availability, multi-language UI, or accessibility certification for the support surface.
• Your team extends or unit-tests the widget heavily. v1.1.0 renames public Livewire properties on a patch-level-minor bump, which signals the internal API is not a stable contract — budget for that on every upgrade.
• Volume is high enough that per-request screenshots (up to 5 each) materially change storage cost; model that before enabling at default.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can adopt a Filament package that puts a help-request widget directly inside the tools our team and customers already use, with no new vendor, no procurement cycle, and no separate support platform. The new release adds annotated screenshots — users mark exactly where something went wrong and describe each pin — which is the single biggest lever on the cost of a support ticket: the back-and-forth to establish what the user actually saw. Cost is one migration and a config entry; the strategic upside is faster resolution and higher-quality bug reports reaching engineering. Recommendation: adopt, set storage.max_files deliberately, and baseline resolution-time metrics so we can prove the improvement.

For engineering (the honest version): Low integration cost — a Composer update, a published migration (add_screenshot_paths_to_help_requests_tables), an npm run build, and cache clears. Two caveats: existing pre-migration requests keep their single screenshot, so there's a data-shape inconsistency to handle in any custom reporting; and the widget's public Livewire properties were renamed from screenshot/replyScreenshot to screenshots/replyScreenshots and are now arrays. Anything extending or testing the widget needs updating. If we do extend it, treat those properties as unstable across releases.

For support/ops: Requests and replies can now carry up to 5 annotated screenshots, surfaced consistently in emails, GitHub issues, and the admin view, including admin-driven replies and status updates. The "My Requests" view is now an accordion and opens the thread a notification points to, which should cut duplicate requests — worth measuring after rollout.

Ask: approve the upgrade window, decide storage.max_files explicitly, and agree two baseline metrics (replies-to-resolution, duplicate-request rate) so this is an evaluated bet rather than a nice-to-have.