Filament Help Desk Laravel Package

Product Decisions This Supports

• Build vs. buy for the support surface. This package is effectively a "buy cheap" option: it gives you a three-panel ticket UI (End User, Operator, Admin) on top of an existing Laravel/Filament app, so the build-vs-buy question narrows to "scaffold vs. Zendesk/Intercom/Freshdesk integration" rather than "build a help desk from scratch."
• Roadmap sequencing. It lets you ship an in-app support feature for an internal tool or early customer base without committing a sprint or two to CRUD, tables, forms, and role-segregated panels. Useful when support is a supporting capability, not the product.
• Feature scoping by persona. The three-panel split forces an explicit decision on who gets what: end users submitting and tracking tickets, operators triaging and replying, admins configuring queues/assignments. That's a permissions and information-architecture decision worth making deliberately, not discovering mid-build.
• Multi-company portals: label vs. tenancy. 1.10.0 surfaces the company name (column, filter, ticket detail) instead of a raw company_id, and ships a README section on multi-company portals. That supports a "one help desk, many client companies, filterable" model — but the release is a display change plus docs. Treat it as a labelling and filtering capability, not tenant isolation: no evidence of row-level scoping, per-company operator assignment, or data separation guarantees. Decide explicitly which of those you're promising before it lands in a customer conversation.
• Denormalization policy for company data. company_name is supplied by a column or accessor on your User model and copied onto each new ticket at creation. That's a product decision with legs: renames, mergers, and company-structure changes won't retroactively update historical tickets. Fine for operational triage ("who is this from?"), wrong for billing or contractual reporting. Pick one deliberately.
• Taxonomy design and migration. Category hierarchy (child categories grouped under parent, grandchild paths rendered as Child › Grandchild) forces a decision about whether categories are a flat tag list or a navigable tree — and 1.10.0 enforces a leaf-node policy: a parent with active children can no longer be selected, validated server-side. Existing tickets filed under a parent keep it on edit, which means the taxonomy can drift unless you plan a cleanup.
• MVP validation of a support workflow. If you're unsure whether customers want in-app ticketing vs. email vs. chat, this is a low-cost way to put something real in front of users and measure volume, response time, and channel preference before investing in an omnichannel stack.
• Internal ops/IT queue use case. The strongest fit: an internal request queue (IT, facilities, HR requests) living inside an existing Filament admin panel, where "good enough ticketing" removes a spreadsheet and nothing more is needed.
• Dependency and platform timing decisions. The 1.x/2.x/3.x matrix (Filament 3 / 4 / 5, Laravel 10–12, PHP 8.1 / 8.2 / 8.3) makes this a forcing function for the "do we upgrade to Filament 5 and PHP 8.3 now?" conversation — adoption is coupled to a platform upgrade. 1.10.0 adds a second coupling: the company-name feature requires jeffersongoncalves/laravel-help-desk ^1.13, so plugin and core package now version-lockstep with each other.

When to Consider This Package

Consider it when:

• You are already standardized on Filament and Laravel; the marginal cost of a plugin is genuinely low.
• Your stack can meet the pinned requirements for the version you need — note 3.x requires PHP ^8.3, Laravel ^11.28, and Filament ^5.0, so the newest line is for teams already on the leading edge. Check the core package constraint too: the 1.10.0 company-name feature needs laravel-help-desk ^1.13.
• You can add a company_name column or accessor to your User model, and you're comfortable with the value being snapshotted onto tickets at creation (tickets without one fall back to showing the id).
• Your company model is "operator convenience" rather than contractual data boundary — a filter and a readable column, not a compliance boundary.
• The ticket model is close to your needs out of the box: create, assign, reply, status, with a two-level category tree. No SLA clocks, no multi-brand routing, no complex escalation trees.
• The blast radius is small and internal — an ops queue, an internal IT desk, a pilot for a handful of accounts.
• You have PHP/Filament depth in-house and are comfortable reading the source, filing issues upstream, or forking. MIT licensing makes the fork option explicit rather than theoretical.
• You are willing to pin versions deliberately and re-evaluate at each plugin release rather than floating on ^.

Look elsewhere when:

• You need real help-desk substance: email/omnichannel ingestion, SLA and escalation engines, CSAT surveys, knowledge base, reporting/analytics, macros, or multi-tenant isolation. None of that is implied by the README — and the new multi-company docs describe portals, not isolation.
• You need enforced per-company data separation. Company filtering in the operator UI is a view concern until proven otherwise; if a client must never see another client's tickets, verify the authorization code yourself or buy a vendor with a tenancy story.
• Company attribution must be historically accurate (billing, invoicing, regulatory reporting). The snapshot-at-creation behaviour will show stale names after a rename or reorg unless you write reconciliation.
• A category policy that blocks parents with active children would break your current filing flow, and you can't reorganize the taxonomy — users will hit server-side validation errors on submit.
• The tickets contain regulated or high-sensitivity data. A ~12-star, single-maintainer package with zero dependents means no external scrutiny of its authorization logic — you would be the auditor.
• You need vendor support, an SLA, security disclosure process, or a maintenance guarantee.
• Your team is not on Filament 5 / Laravel 11.28 / PHP 8.3 for the current line, and pinning to an older major line creates a second upgrade liability you don't want to own.
• Ticket handling is core to your product. Anything customer-facing at scale should justify a buy decision with a real vendor or an owned build.
• You are a small team without spare PHP capacity to absorb an abandoned dependency. Zero dependents is a leading indicator that fixes will land slowly or not at all.

How to Pitch It (Stakeholders)

To executives: This is an MIT-licensed Filament plugin that gives us a working three-panel ticket interface — end users, operators, admins — on top of the Laravel help desk package, at zero license cost. It's the fastest path to replacing a manual/spreadsheet support process with something users can actually see. The latest release (1.10.0) makes it materially more usable for client-facing pilots: operators see company names instead of database ids, and categories can be organized as a parent/child tree instead of a flat list. Two things to accept knowingly. First, it is still a single-maintainer project (~12 GitHub stars, no downstream dependents), so treat it as a starting scaffold we own — budget a few days of engineering review and a fork-if-needed contingency — not a vendor relationship. Second, "multi-company portals" means the company is a label and a filter, not an enforced data boundary; do not let that phrase reach a customer as a isolation guarantee until engineering has confirmed it. Recommended for internal tools and early pilots; not recommended for regulated or high-volume customer support without that review.

To engineering: The 1.10.0 bump adds real behaviour, not just cosmetic changes. Adoption means adding jeffersongoncalves/laravel-help-desk plus this Filament plugin layer, on Filament 5 / Laravel 11.28 / PHP 8.3 for 3.x (older majors map to Filament 3/4 if we can't move yet). This release needs laravel-help-desk ^1.13 for the company-name feature — verify the pair resolves together before pinning. Please do four things before we commit: pin exact versions for both packages and confirm the matrix against our stack; review the panel authorization and data-scoping code (nobody else has) and specifically confirm whether company filtering restricts access or only filters views; decide the company_name source (column vs. accessor) and how we handle existing tickets, which will show the raw id until touched; and confirm the test suite covers the operator/admin boundaries plus the new server-side validation that blocks selecting a parent category that has active children — that validation is a potential support-ticket generator if our taxonomy is mid-reorganization. If it holds up, we ship a pilot; if it doesn't, we fork and own it — MIT makes that a real option, and the scope is small enough that a fork is cheaper than a rewrite.