Understanding Services
Every ScopeStack project is built from a small set of content types that carry revenue, cost, and effort. Understanding how they work together is key to everything else on the platform.
The five content types
Professional Services
One-time services you provide to complete a project. Priced by effort (hours x rate) or by quantity with variable rates. Examples: network assessment, server migration, cloud architecture design.
Professional services are organized into Phases (the stages of your project, like Planning, Design, Implement) and grouped by Line of Business and Service Category.
Managed Services
Recurring services provided over a contract term and billed at a set interval (monthly, quarterly, or yearly). Priced by quantity with a per-period price and cost. Examples: ongoing monitoring, managed security, help desk support.
Managed services do not use phases. They are sequenced in whatever order you want them presented.
Products
Physical or digital items delivered to a client or consumed in the completion of services. Priced by quantity with a unit price and cost. Examples: hardware, licensing, equipment. Products can be one-time or recurring with the same billing frequency options as managed services.
Governance Items
Overhead items like project management, contingency, or documentation. They are added to a project automatically from your account’s governance settings (or optionally via a Survey). Each governance item either has a fixed number of hours or calculates its hours as a percentage of total professional services effort. Governance rolls up into professional services pricing.
Travel & Expense Items
Account for time or expenses to travel to and from the customer’s site. Each item can have a fixed default amount or a custom value per project. See Travel & Expense for details.
Third-Party Services
Services provided by a subcontractor, added through Vendor Quotes or Partnerships. Vendor-quoted services can be marked up and presented to your client as your own services in the generated document, while the platform tracks the actual vendor cost behind the scenes.
Services and subservices
Services and subservices are the two levels of hierarchy. Both can carry effort, pricing, and resource assignments independently.
A service is the top-level unit. Each service can have zero or more subservices beneath it.
Key behaviors
- Independent quantities: Changing a service’s quantity does not change its subservices’ quantities. A server rack installation (quantity 1) might have 10 blade server installs beneath it. Changing the rack to quantity 2 keeps the blade installs at 10.
- Independent effort: Both the service and each subservice carry their own unit hours. A service’s total hours is its own extended hours plus the sum of all its subservices’ extended hours.
- Resource inheritance: If a subservice has no resource assigned in Settings, it inherits its parent service’s resource when added to a project. You can override this per-project.
- Independent pricing: Each level calculates its own revenue and cost from its hours, quantity, and resource rate. The service’s total pricing rolls up both levels.
Three ways to allocate effort
| Pattern | Service hours | Subservice hours | Best for |
|---|---|---|---|
| Effort on subservices only | 0 | Per-subservice | Maximum granularity. You see exactly where time is spent. |
| Effort on service only | Set | 0 (or no subservices) | Simple work that can’t be broken down further. Subservices, if any, are used only for document language. |
| Effort on both | Base hours | Variable hours | Work with a fixed baseline plus variable components. The service carries the “regardless of scope” hours; subservices carry the parts that scale. |
Questions to guide your structure
- What is the minimum unit of effort that scales linearly? That’s probably a subservice.
- What is the most granular item you need to describe in your document? That determines whether you need subservices or if services alone are sufficient.
- Do different parts of the work require different resources? If so, those parts should be separate subservices with their own resource assignments.
- Does some effort always apply regardless of scope? Put that on the service level, with variable effort on subservices.
Lines of Business and Service Categories
Services are organized by Line of Business (the practice area, like Network or Cloud) and Service Category (a subcategory within the LOB). These are set when you create a standard service in Settings and can be changed per-project for custom services.
LOB and Service Category serve two purposes:
- Filtering and search: The service picker in the project editor lets you filter by LOB and category
- Document structure: Templates can group and loop over services by LOB or category
See Lines of Business for setup details.
How services appear in documents
How you structure services directly affects your generated documents:
- All service-level language (descriptions, language fields) renders at one level of hierarchy
- All subservice-level language renders at the next level down
- If you need content to appear at a consistent level in your document, it must sit at the same level in the service hierarchy
For example, if some deliverables need to appear as top-level items and others as sub-items, the top-level ones should be services and the sub-items should be subservices.
Standard vs custom
All content types can be pre-defined in Settings as standards (reusable across projects) or created custom on a per-project basis. Standards save time on repeated work; custom services handle one-off situations. You can also save a custom service as a standard after building it on a project.