An EosHQ Pack turns industry knowledge into an installable operating model. A customer can add the Pack to EosHQ and start with terminology, records, views, reports, Skills, and draft Agents that already fit the work. A partner can encode a method learned through years of implementations and apply it consistently across more than one customer.
The distinction matters because customers often ask whether a Pack is a separate application. It is part of the same EosHQ organization. Users keep the same Projects, Tasks, Assignments, Time Log, Approvals, Reports, Notifications, Chat, integrations, and access model. The Pack configures those capabilities and adds industry records where the main application would otherwise be too general.
What comes from EosHQ, and what comes from a Pack?
The EosHQ platform provides the horizontal capabilities used by project-driven organizations. Projects hold the work, Assignments connect people to it, Time Log records effort, Approvals preserve human decisions, and Agents coordinate permitted Skills. Those concepts remain useful across consulting, property services, implementation work, engineering, and other sectors.
A Pack supplies the industry-specific model around those capabilities. The table shows the practical boundary.
| Shared EosHQ capability | Example supplied by a Pack |
|---|---|
| Project | A property-service Job with loss type and restoration stage, or a professional-services engagement with an approved commercial baseline. |
| Task and Assignment | A site-visit follow-up assigned to a technician, or a resource request matched to a consultant with the required role. |
| Custom records | Field Captures and Moisture Readings, or Estimates and Change Requests. |
| Approval | Review an evidence-package draft, or approve a scope change before it affects the delivery forecast. |
| Report and dashboard | Documentation exceptions by Job, or projected margin and capacity by engagement. |
| Skill | List field captures awaiting review, or calculate the staffing and margin impact of a proposed change. |
| Agent | Prepare a documentation review, or assemble an invoice-readiness brief for a manager. |
The platform handles access, persistence, approvals, reporting, simulation, and Agent execution. The Pack describes how those capabilities should appear and work together for its target industry.
A Property Services Pack changes what a Job contains
Consider a restoration contractor documenting work at a property. A generic Project can hold dates, Tasks, Assignments, files, and time. The contractor also needs a structured record of each visit, the property area involved, readings taken, media captured, missing documentation, and the package eventually shared with the customer.
The Property Services Pack adds six record types for that operating model: Site Visits, Field Captures, Documentation Requirements, Field Readings, Documentation Exceptions, and Evidence Packages. It adds Job tabs that present those records through timelines, galleries, checklists, tables, and exception queues. It also adds mobile capture actions and Skills that retrieve the documentation state without granting a Pack direct access to the database.
The customer still uses an EosHQ Project underneath the visible Job language. The Pack supplies the additional structure. As a result, a manager can open one Job and answer a specific question: which required evidence exists, which items still need review, and what can safely enter the customer package?
A Professional Services Operations Pack follows the commercial thread
Now consider a 120-person consultancy preparing a new engagement. The team needs to define services, estimate the work, request resources, deliver through Projects and Tasks, handle scope changes, prepare billing evidence, and forecast margin. EosHQ already provides much of the delivery foundation. The Pack connects that foundation to the commercial decisions surrounding the work.
The Professional Services Operations Pack adds a Service Catalog, Estimates, Resource Requests, Change Requests, and a RAID register for risks, assumptions, issues, and dependencies. It extends Projects, Assignments, and Time Log with service economics and engagement context. Its reports show demand against capacity, estimate-to-actual movement, unapproved scope, billing readiness, and projected margin.
Its Agents then work across explicit records. A Staffing and Capacity Agent can compare a Resource Request with availability and qualifications. A Scope and Margin Guard Agent can identify delivery activity outside the approved estimate and prepare a Change Request draft. A Time and Billing Readiness Agent can assemble supporting records for a manager without issuing an invoice by itself.
The 11 parts a Pack can contribute today
EosHQ currently materializes 11 contribution types through the package installer:
- New Object Definitions create Pack-owned record types, including their fields, layouts, relationships, and access policy.
- Existing-Object Extensions add fields, layouts, semantics, relationships, or clone behavior to records already present in EosHQ.
- Experiences define views, forms, actions, and placements inside web and mobile screens.
- Navigation adds or replaces menu entries that lead people into the Pack’s workspaces.
- Terminology supplies the industry’s default names while preserving stable object identities underneath.
- Dashboards arrange operational widgets around the decisions the Pack is designed to support.
- Reports provide reusable columns, filters, grouping, calculations, and sorting.
- Reporting Projections define supporting read models for analytics that need prepared dimensions and measures.
- Skills expose typed, testable operations through declared EosHQ capabilities.
- Agents arrive with an intent and Skill dependencies, then require compilation and review before activation.
- Index Requirements declare the database indexes needed by Pack views and queries.
Every contribution carries the Pack ID, version, and publisher provenance. Package versions are immutable, and installation can be planned before anything is written to the organization. Disabling a Pack preserves the customer’s operational records.
What a prospective Pack partner brings
A strong Pack starts with an operating model the partner understands in detail. The useful knowledge usually appears in the questions asked during implementation: which records are repeatedly missing, where approvals become ambiguous, which handoffs delay revenue, and which exceptions need a manager’s judgment.
A prospective partner can bring:
- A repeatable delivery method for a defined industry or operating function.
- Record definitions and terminology that practitioners already recognize.
- Reports that lead to a decision instead of decorating a dashboard.
- Skills that perform bounded operations with clear inputs and outputs.
- Agent instructions that coordinate those Skills while preserving review boundaries.
- Implementation guidance that explains what the customer must configure.
EosHQ supplies validation, package planning, versioning, provenance, installation, disablement, and rollback behavior. Sandboxed Pack Skills call declared EosHQ capabilities; they cannot import modules, read secrets, contact arbitrary network services, or bypass organization access.
Can a partner sell an EosHQ Pack?
A Pack can form the product layer of a partner offering. The commercial offer may combine Pack access, implementation, configuration, migration, training, and ongoing operating advice. That gives a specialist a reusable product while leaving room for the work that depends on each customer’s structure.
Marketplace distribution requires publisher verification, artifact signing, support terms, upgrade commitments, and a commercial agreement with EosHQ. Those controls are part of preparing a partner channel; a package file alone does not establish marketplace approval or a right to sell through EosHQ.
The practical first step is a bounded design review. Bring one operating process, the records it touches, the people involved, and the decision the process should improve. EosHQ can then determine which parts belong in the shared platform, which parts belong in the Pack, and whether the current package contract can express the model.
Start with one process customers can recognize
A credible Pack should make one real process visibly better during the first review. For Property Services, that process runs from field capture to a reviewed evidence package. For Professional Services Operations, it runs from estimate through staffing, delivery, approved change, and billing readiness.
Bring a representative process to a Pack discussion, and include the records, screens, decisions, and handoffs people use today. We will map it to the current EosHQ package contract and identify the smallest Pack that produces a coherent operating result.