Laravel Help Desk Laravel Package

Product Decisions This Supports

Build vs. buy for the support surface. The package ships a working ticket domain — tickets with uuid + human reference_number, departments, categories, priority, a validated status machine (Open → InProgress → Resolved → Closed, with Closed only reopening to Open), assignment, comments vs. internal notes, attachments, watchers, and a history log that records every status, priority, assignment, comment and attachment event. That is the majority of what a team would otherwise spend 6–12 weeks rebuilding, so it turns "build a help desk" into "configure and skin a help desk."

Multi-product, multi-company and white-label architecture. The most strategically interesting decision this enables is the driver model: a central support application can serve multiple "satellite" applications either by sharing one database connection or by signed HTTP (HELPDESK_DRIVER=api), with per-app scoping (HELPDESK_SCOPE_TO_APP, Ticket::forApp('app-a')). v1.13 adds the second axis: tickets now carry a company identity — HelpDesk::createTicket() accepts an optional company_name, persisted as a snapshot in metadata.company.name alongside company_id, exposed as $ticket->company_name with fallback to the id. Combined with the documented multi-company setup (including mapping a differently named column such as empresa_id through an accessor), this means one support core can serve a B2B2C/agency book of business — or one white-label install per customer — without per-tenant deployments. That is a real cost and operational argument, and it is now a supported path rather than a schema you'd have to invent.

Roadmap sequencing. Because it installs into an existing Laravel app and shares your User model via HasTickets / IsOperator traits, support can be a v1 feature rather than a standalone product launch. Reasonable roadmap increments on top of it: customer-facing ticket forms and status pages, SLA/due-date surfacing (due_at, overdue() scope already exist), company-scoped agent views and reporting, and notification tuning. Anything genuinely differentiating — CSAT, workflow automation, knowledge base — is additive, not foundational.

Data ownership and unit economics. MIT-licensed, self-hosted, no per-seat or per-ticket pricing. This supports a decision to keep support data — and requester PII — inside existing infrastructure and existing database backups, which matters for EU data-residency positioning and for procurement reviews at larger customers. Company scoping is what makes that position defensible once you're holding support data for more than one legal entity.

Operational design decisions it forces (usefully). Adopting it requires answering: what departments and routing exist, what the priority taxonomy is, whether internal notes are permitted in regulated workflows, how long history is retained, and — newly — whether tickets are company-scoped and how a company with no id is handled. The package's opinionated structures make those conversations concrete rather than abstract.

Migration/exit posture. Every model routes through help-desk.connection and a facade (HelpDesk::createTicket, changeStatus, addComment) rather than raw Eloquent, so business logic sits against a narrow interface. That is a favorable lock-in profile for a package-based bet. v1.13's company_name is a further case of a snapshot in the existing metadata column rather than a new relation — no migration, no schema coupling added.

When to Consider This Package

Adopt when:

• The stack is Laravel/PHP and you have in-house Laravel capacity — this is a library, not a product. There is no admin UI in evidence, no vendor support desk, and integration means writing controllers and views.
• Ticket volume is modest-to-moderate (roughly hundreds to low thousands per month) where a clean queue, assignment, and email-in loop is sufficient.
• You need email-to-ticket and email notification to requesters, and you're comfortable configuring mail rather than relying on a managed inbound-email vendor.
• Support must live inside your app's auth model and branding, must span multiple applications you operate, or must attribute tickets to different companies/customers from a single support core.
• Data residency, self-hosting, or predictable cost is a stated requirement.
• You can absorb maintenance: pinning the version, reading release notes, and owning upgrades.

Look elsewhere when:

• You need omnichannel support — live chat, voice, social, in-app messaging with real-time presence. This is ticket-shaped, not conversation-shaped.
• You need SLA engines, escalation automation, CSAT/NPS surveys, knowledge bases, or a mature reporting layer out of the box. None of that is in scope here — company scoping gives you the key to report on, not the reports.
• You need 24/7 vendor SLAs, SOC 2-adjacent assurances, or a procurement-friendly support contract. A single-maintainer MIT package will not clear that bar.
• You have no PHP/Laravel engineer who can own it long-term — the cost of self-hosting a help desk is maintenance, not licensing.
• Your support team expects a mature agent workspace; you would be funding UI development that hosted tools already ship.
• Non-Laravel or polyglot environment, or you need the help desk to be an independent service with its own release cadence rather than a composer dependency.

The honest maturity caveat to state plainly: ~12 stars, zero known dependents, and a single maintainer mean no community validation. Signals remain mixed but have tilted slightly positive: the release history is now a steady minor cadence (v1.13 lands a requested feature — company name snapshots — plus multi-company documentation, with explicitly no migration required), and the repo has added standardized CI, Dependabot and auto-merge for GitHub Actions, which is the kind of hygiene that makes single-maintainer risk cheaper to live with. That still reads as "thoughtful, deliberately engineered package" rather than "proven ecosystem dependency." Treat adoption as a spike-and-validate decision, not a drop-in: run a two-week proof of concept on the API driver and shared-database paths, exercise the company-scoping model against your real org/tenant hierarchy, verify the status machine and history log match your compliance needs, and watch upgrade cadence over one or two release cycles before committing roadmaps to it.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. We can ship customer support inside our product in weeks instead of a quarter, with no per-seat subscription and no support data leaving our infrastructure. It is an MIT-licensed Laravel component we install and own: tickets, departments, assignment, internal notes, attachments, email in and out, company attribution and a full audit trail come with it. The trade-off is that we maintain it and there is no vendor to call. The recommended commitment is a short, contained evaluation — not a platform bet — and we should decide after seeing it work on our own data model.

For engineering — what you're actually taking on. A facade-driven domain layer (HelpDesk::*), traits on User, publishable config and migrations, an event/subscriber-based history log, and a storage-abstracted attachment service. Business logic stays behind the facade, so it's replaceable. Three things to review before we commit: (1) the ticket tables declare no foreign key to users or to companies — identity is read through snapshot accessors (requester_name, author_name, and now company_name) with a morph map, and v1.13 continues that pattern by storing company_name in metadata.company.name with fallback to company_id (so pre-1.13 tickets render an id where a name should be). That's a deliberate design for multi-app use and safe deletion, but it means no database-level referential integrity on people or companies, so we must never read the raw morph relations; (2) company_id is nullable and the null-company case is a documented caveat — decide up front how unscoped tickets are routed and reported, and expect to map a differently named column (e.g. empresa_id) via an accessor if our schema doesn't use company_id; (3) the api driver is end-user only — operator actions and getUrl() on attachments are unsupported there — so any satellite using it has a reduced feature surface by design. The upgrade to 1.13 is unusually cheap: no migration, new fields are optional, and it adds API parity (company_id/company_name accepted on signed POST tickets, returned on TicketResource). Budget: about a week for the spike, plus ongoing maintenance of roughly one dependency upgrade per quarter and any UI we build.

For the support/ops lead — what changes day to day. Queues by department, priority, categories, assignment and unassignment, internal notes that requesters never see, watchers for visibility, and a per-ticket timeline of who changed what and when. Email becomes a real intake channel and requester replies thread onto tickets. If we serve multiple brands or business customers, tickets can now be attributed to a company, which gives us a clean axis to filter and report on later. What they will not get on day one: canned responses, SLA breach alerts, customer satisfaction surveys, or a reporting dashboard — plan for those as phase two, or as a thin layer we build.

The risk framing, stated once and clearly. Low adoption (no known dependents) and a single maintainer are the material risks; the license, the code's replaceability, and now a visible CI/dependency-automation setup are the mitigations. Our exposure is capped if we keep business logic behind the facade and avoid deep schema coupling. If the spike disappoints, we lose a week; if it works, we avoid a per-seat bill and a third-party data processor.