Filament Service Desk Laravel Package

Product Decisions This Supports

• Build vs. buy for a support/ITSM surface. The package removes the largest chunk of undifferentiated work in a service desk: departments, categories, tags, canned responses, ticket lifecycle with comments/attachments/history/watchers, SLA policies with targets and escalation rules, business-hours schedules with holidays, email channels, a knowledge base with versions and feedback, and a service catalog with dynamic request forms. That is months of CRUD and admin UI you don't have to specify, design, or build.
• Roadmap sequencing for a new support function. The three-panel model (Admin / Agent / End-user) is an opinionated answer to "who needs what screen," letting you commit to a phased rollout instead of debating personas: internal configuration first, then agent queue and SLA enforcement, then a self-service portal.
• Scope discipline via feature toggles. knowledgeBase(), sla(), emailChannels(), and serviceCatalog() can be enabled per panel (and globally in config). This supports a deliberate "tickets only" launch (v1), with KB and service catalog as follow-on releases, without re-architecting.
• Platform consolidation decision. If the product already runs on Filament, this is additive rather than a second admin stack: same auth, same design language, dashboard widgets swappable via config (admin.*, agent.*, user.* widget arrays). The decision shifts from "adopt a helpdesk tool" to "extend our existing panel."
• Use-case fit to evaluate against your actual jobs-to-be-done: internal IT/ops helpdesk, employee request portal (service catalog wizard), SaaS in-app support portal for existing customers, and a scoped agent queue with claim-from-unassigned workflow and SLA breach visibility.
• Internationalization scope. 19 locales including pt_BR and en, with publishable translations. If support is multilingual or LatAm-focused, this removes a localization workstream from the plan.
• Reporting baseline. Ships overview, SLA compliance, tickets-by-department, agent stats, and SLA-breach widgets — enough to answer "are we meeting SLA and who is overloaded" without a BI project. Decide explicitly whether that is sufficient or whether analytics is a separate roadmap item.

When to Consider This Package

Adopt when:

• You are already on Filament and the version lines match: 1.x → Filament ^3 / Laravel 10 / PHP 8.1; 2.x → Filament ^4 / Laravel 11 / PHP 8.2; 3.x → Filament ^5 (Livewire 4) / Laravel 11.28+ / PHP 8.2. Mismatched lines are the single biggest adoption trap.
• The desk is internal or low-stakes — IT helpdesk, employee requests, an MVP support queue — where a bug is an annoyance, not a contractual breach.
• You have engineering capacity to read the source and own a fork. With 18 stars, 0 dependents, and a single maintainer, you are effectively adopting a codebase, not a vendor.
• A 1–2 week spike can validate the underlying jeffersongoncalves/laravel-service-desk core (SLA math, escalation behavior, ticket state machine) against your requirements before you commit.
• You need the domain model more than the polish: the resource inventory is genuinely comprehensive for a package this size.

Look elsewhere when:

• You need a vendor. No commercial support, no SLA, no security disclosure process, no third-party dependents as social proof. For customer-facing support with uptime and data-handling commitments, use a commercial platform or budget for in-house ownership.
• Upgrade stability is a hard requirement. The plugin class was renamed ServiceDeskPlugin → ServiceDeskAdminPlugin and the plugin ID changed in 1.2.0, again in 2.2.0, and again in 3.2.0, alongside a config restructure from feature-scoped to panel-scoped keys. Three breaking lines in a young package is a signal about change cadence, not a one-off.
• You are on Filament 3 and unwilling to move. The 3.x line targets Filament 5 / Livewire 4, which is bleeding-edge; verify the rest of your plugin ecosystem is ready before standardizing on it.
• Requirements extend beyond the box: omnichannel (chat, voice, social), AI triage/routing, advanced analytics, custom SLA hierarchies beyond policy → target → escalation, or complex approval workflows inside service requests. These are roadmap items you would own, not configuration.
• You cannot pin and test. If you deploy floats on ^3.0 without a regression suite around the ticket flow, the changelog history suggests you will be surprised.

Recommendation to record: treat as an accelerator for an internal tool or MVP, gated behind a spike and a fork-and-own decision — not as a foundation for a revenue-critical, customer-facing support product.

How to Pitch It (Stakeholders)

For executives (one paragraph): "There's an MIT-licensed Laravel package that gives us a complete service desk — admin configuration, an agent queue with SLA tracking, and an end-user self-service portal — as drop-in panels on the admin framework we already run. It could take a support function from idea to usable in weeks instead of a quarter, with no license cost. The caveat is maturity: it's a young, single-maintainer project with no downstream adopters and a history of breaking renames, so I'm recommending a two-week evaluation spike and, if it passes, adopting it as internal code we own and fork rather than as a dependency we rely on. I would not put it under a customer-facing SLA without that ownership plan."

For engineering:

• It is a Filament plugin over jeffersongoncalves/laravel-service-desk; three plugins (ServiceDeskAdminPlugin, ServiceDeskAgentPlugin, ServiceDeskUserPlugin) register into panels, with fluent feature toggles and a publishable panel-scoped config.
• Coverage is unusually broad for the size: resources for department, category, tag, canned response, ticket (+ comments, attachments, history, watchers relation managers), SLA policy/targets/escalation, business hours with time slots and holidays, email channel, KB article versions and feedback, KB category, services with form fields, service category. Agent side adds a ticket queue claim page and dashboard; user side adds a service-request wizard.
• Operational surface is configurable: attachment extensions/MIME resolution, 10 MB default cap, storage disk; dashboard widgets overridable per panel or disabled with an empty array.
• Test infrastructure uses Pest, translations are publishable, and there is Laravel Boost tooling — all of which lowers onboarding cost.
• Ask: pin exact versions, run the spike against our SLA definitions, and decide fork-vs-depend before the first production ticket. Include an upgrade path review at each minor release.