Laravel Service Desk Laravel Package

Product Decisions This Supports

• Build vs. buy for support tooling. This package occupies the middle ground between "buy Zendesk/Freshdesk/Intercom at per-seat pricing" and "build a helpdesk from scratch." It lets a Laravel team self-host the domain layer and avoid seat-based SaaS costs, at the price of owning maintenance. That is a genuine strategic tradeoff worth putting on the roadmap.
• Whether ticketing/SLA/KB is core or commodity. Ticket lifecycle, SLA policies, knowledge base articles, and approval-gated catalog requests are well-understood patterns. If the package covers your requirements, this is commodity logic you should not be writing; if your differentiation lives in routing, triage, or automation, keep those in-house and let the package own the CRUD and state machine.
• Scope of a new internal tool. Concrete candidate products: internal IT helpdesk, HR/people-ops request portal, facilities and maintenance requests, employee onboarding with approval chains (the service catalog), and embedded customer support inside a B2B SaaS product.
• Deployment topology across products — now an explicit fork in the road. v1.2.0 introduces a third ticket-sharing strategy (UsesServiceDeskConnection, service-desk.connection) alongside the existing database and api transports. The PM-level question is no longer just "headless or not" but "do satellite apps talk to the service desk over a signed HTTP API, or share one physical schema?" Shared-DB is the cheapest to ship and the most expensive to evolve: it couples migrations, upgrade timing, and rollback plans across every consuming app. Decide this before the second app integrates, not after.
• Front-end and surface strategy. Still headless at the core, but the API transport is now materially more capable: satellites can post public replies (POST tickets/{uuid}/comments) and discover valid departments/categories rather than hardcoding IDs. That moves embedded/partner surfaces from read-mostly to genuinely bi-directional, which changes the staffing and timeline calculus for a widget or embedded support experience. Note the transport is deliberately asymmetric — internal notes are unreachable from this surface by construction — so "customer-facing reply" and "agent-facing note" remain separate product surfaces. Good default; confirm it matches your intended exposure.
• Integration contract as a product decision. Department/category discovery endpoints imply a stable, documented taxonomy that satellites can rely on. That makes department/category structure a shared contract with external consumers, not an internal config detail — worth assigning an owner and treating taxonomy changes as a versioned change.
• SLA as a business policy, not a code detail. SLA tracking forces explicit decisions about support tiers, response/resolution targets, business-hours calendars, and breach escalation. Adopting the package is an opportunity to ratify those policies with support/CS leadership before implementation.
• Channel strategy. Multi-channel email integration encodes an assumption that email is the primary intake. Validate that against actual request volume by channel before committing; if chat or in-app forms dominate, the package's value proposition weakens.
• Self-service vs. live support ratio. A knowledge base with deflection is a lever on cost-per-ticket. If deflection is a stated goal, this package gives you the article model cheaply; measure it or the KB becomes shelfware.
• Data ownership and residency. Self-hosting supports compliance, on-prem, and data-residency decisions that SaaS helpdesks can block, particularly for regulated or EU-resident customers.

When to Consider This Package

Consider it when:

• You are already on Laravel/PHP with auth, queues, notifications, and mail infrastructure in place — this is a force multiplier only inside that stack.
• You want a headless domain layer and intend to build your own UI. If you want a working helpdesk on day one, this is the wrong shape.
• Your requirements map closely to the standard service-desk model: tickets with status/priority/assignment, SLA policies and breach tracking, KB articles, catalog items with approval workflows, and email-to-ticket ingestion.
• You have (or anticipate) satellite applications that need to raise tickets or add replies — the API transport plus comment and taxonomy-discovery endpoints now cover a realistic embedded integration, not just a stub.
• Data ownership, on-prem deployment, or per-seat cost avoidance are real constraints, not hypotheticals.
• You are comfortable treating it as a reference implementation and accelerator — reading the source, forking or vendoring it, and hardening it yourself.
• You need a validated schema and state model quickly, and a 2–3 week spike is cheaper than a month of greenfield design.

Look elsewhere when:

• Maturity is a blocker. Nine stars, zero dependents, and a low composite score mean essentially no third-party validation: no public case studies, no ecosystem of extensions, no proven upgrade path. Single-maintainer risk is real. If you need an SLA-backed dependency, this is not it. The v1.1.0 → v1.2.0 release is a mildly positive signal on cadence and additive/non-breaking change discipline, but one minor release is not evidence of a track record.
• You need capabilities the description does not promise — rigorous SLA analytics and reporting, CSAT/NPS surveys, omnichannel (chat, voice, social, WhatsApp), AI triage/summarization, or enterprise identity (SAML/SCIM) and CRM/issue-tracker sync. Assume they are absent until proven otherwise.
• Your support need is genuinely shallow (a shared inbox, a few hundred tickets a month). Gmail plus a lightweight SaaS will beat the total cost of owning a custom helpdesk.
• You are not on a Laravel version the package supports, or you cannot accept its PHP/framework version constraints.
• You require vendor-backed guarantees: SOC 2, HIPAA BAA, 24/7 support, contractual uptime. A community MIT package cannot supply these no matter how good the code is.
• You have no capacity to fork and maintain. The moment you adopt it, you own it.
• You cannot coordinate deploys across apps. If you would pick the new shared-database mode, every schema change becomes a multi-app release event. Teams without coupled release trains should stay on the API transport.

Vetting checklist before committing: release cadence and semantic-versioning discipline (v1.2.0 is cleanly additive and non-breaking — verify that pattern holds), test coverage and CI status of the new addComment and discovery endpoints, open-issue responsiveness, migration stability across releases (note: v1.2.0 adds a uuid column to TicketComment — confirm the backfill path for existing comments before upgrading), dependency footprint (does it drag in a UI framework you don't want?), whether "headless" truly means no routes/views (it now does not — an opt-in signed-request JSON API ships with configurable prefix; verify it is off or unreachable unless you opt in), how SLA clocks handle business hours, time zones, and pauses, and — for the shared-DB mode — whether the connection trait covers all models you will touch (six core models only; anything you add yourself inherits none of it).

How to Pitch It (Stakeholders)

For executives. We can stand up an internal or embedded service desk on the Laravel stack we already run, keeping the data in our own infrastructure and avoiding per-agent SaaS licensing that scales badly as we add support staff. Ticket management, SLA clocks, a knowledge base, approval-gated service requests, and email intake are pre-built; the latest release also adds a working integration surface so other products in our portfolio can open tickets and reply to them without us building a bespoke connector. That removes an estimated several weeks of greenfield work and, more importantly, gives us a proven data model and set of requirements. The honest caveat is unchanged: this is an early-stage, single-maintainer open-source project with negligible adoption — nine stars, zero dependent projects. The 1.2.0 release is a good sign on maintenance discipline, but one release is not a track record. We should treat it as a head start, not a finished product, and budget engineering time to fork, test, and harden it. Recommendation: approve a short, time-boxed spike (2–3 weeks, one engineer) against our top five real support scenarios, and use it to settle one architectural question early — whether satellite apps integrate over the API or share our database. If the spike passes, we proceed with a clear cost avoidance; if it fails, we exit with a validated schema and a requirements document that makes any build-or-buy decision afterwards cheaper and better informed.

For engineering. MIT-licensed, Composer-installable, and headless at the core — expect domain models, migrations, events, and config rather than views, so we retain full control of the UX. 1.2.0 is additive and non-breaking, but three things need eyes during the spike. First, TicketComment gains a uuid column — dry-run the migration and backfill against realistic comment volume before committing to an upgrade. Second, the API transport is now a real integration surface: POST tickets/{uuid}/comments for public replies only (internal notes are excluded by design — a good default, but verify that boundary holds through any wrapper we write), plus departments/categories discovery so satellites stop hardcoding IDs. Treat departments and categories as a published contract with an owner, not internal config. Third, the new UsesServiceDeskConnection shared-database mode is a genuine architectural commitment: it couples our migrations and release cadence to every consuming app, covers only six core models, and is a no-op unless configured. Prefer the API transport unless we can honestly commit to coordinated deploys.

Beyond that: vendor or fork it, pin versions, wrap it behind our own service interfaces so we can swap or replace it later, and never expose its models directly through our API. Add test coverage and upgrade gates before the first production ticket. Remaining risks to verify in the spike: migration stability between releases, Laravel/PHP version constraints, how SLA timers handle business hours and pauses, email ingestion idempotency and threading, and the actual completeness of the approval-workflow and KB features. This is an accelerator and a reference architecture, not a dependency we should adopt uncritically.