1. Introduction
1.1 Purpose
This document defines the functional requirements, user roles, and user stories for the Services Module of the DSP platform. It is intended to serve as a reference for product, development, and quality assurance teams to understand what the module must do, who it must do it for, and the acceptance criteria that define successful delivery.
1.2 Scope
The scope of this document is strictly limited to the Services Module — the configuration and lifecycle of sellable services, including pricing models, trials, recurring/subscription behaviour, add-ons, pricing variants, quantity handling, team assignment, deadlines, and catalogue organization. It covers the module’s behaviour across all three access levels defined in Section 2: Super Admin, Workspace Admin, and Client Portal. Adjacent modules — Order Forms, Order Management, and Workspace Management — are referenced only where necessary for context and are out of scope for detailed requirements in this document.
1.3 Document Conventions
- Each functional requirement is identified with a unique ID in the format FR-SVC-##.
- Each user story is identified with a unique ID in the format US-<Role Code>-##, where Role Code is SA (Super Admin), WA (Workspace Admin), or CP (Client Portal).
- Priority levels follow the MoSCoW method: Must Have, Should Have, Could Have, Won’t Have (this release).
2. User Roles & Access Levels
The Services Module is used by three distinct classes of users, each with a different purpose and level of access, as summarized below.
| Role |
Description |
Access Level |
| Super Admin |
The agency owner / top-level account holder with unrestricted access to the entire workspace, including all Services Module configuration. |
Full — create, read, update, delete, publish |
| Workspace Admin |
Internal team member operating under a configured role (e.g. Admin, Manager, Contractor, or a custom role) with permissions granted by the Super Admin. |
Permission-based — ranges from full management to read-only or assigned-items-only |
| Client (Client Portal) |
An external customer who browses, purchases, and manages subscriptions to services through the client-facing portal. |
Purchase & self-service only — no configuration access |
3. Functional Requirements
The following requirements are grouped by functional area within the Services Module.
3.1 Service Creation & Pricing Models
| Req ID |
Requirement Description |
Priority |
| FR-SVC-01 |
The system shall allow a Workspace Admin to create a new service with a name, description, and image. |
Must Have |
| FR-SVC-02 |
The system shall support a One-Time price type, requiring a single fixed price. |
Must Have |
| FR-SVC-03 |
The system shall support a Recurring price type, requiring a price and a billing interval (e.g. monthly, yearly). |
Must Have |
| FR-SVC-04 |
The system shall allow a service to be marked as Free ($0), bypassing any payment step at checkout. |
Must Have |
| FR-SVC-05 |
The system shall validate that a price is provided unless the service is explicitly marked Free. |
Should Have |
| FR-SVC-06 |
The system shall allow a Workspace Admin to edit or delete an existing service, subject to dependency checks (see FR-SVC-31). |
Must Have |
3.2 Trials
| Req ID |
Requirement Description |
Priority |
| FR-SVC-07 |
The system shall allow a Free Trial (no charge) to be configured on a recurring service, with a defined trial length. |
Must Have |
| FR-SVC-08 |
The system shall allow a Paid Trial (reduced introductory price) to be configured on a recurring service, with a defined trial price and length. |
Should Have |
| FR-SVC-09 |
The system shall not charge the full recurring price until the configured trial period has elapsed. |
Must Have |
3.3 Recurring Billing Behaviour
| Req ID |
Requirement Description |
Priority |
| FR-SVC-10 |
The system shall support a ‘No Action’ recurring behaviour, under which renewal does not generate any order. |
Must Have |
| FR-SVC-11 |
The system shall support a ‘Reopen the Same Order’ recurring behaviour, under which the existing order is reopened into the active work queue on each renewal. |
Must Have |
| FR-SVC-12 |
The system shall support a ‘New Order Every Cycle’ recurring behaviour, under which a new, independent order is created on each renewal. |
Must Have |
| FR-SVC-13 |
The system shall support a ‘Service Requests’ recurring behaviour, under which the subscription is allocated a fixed number of requests per billing cycle. |
Must Have |
| FR-SVC-14 |
The system shall reset the available request quota automatically at the start of each new billing cycle for request-based services. |
Must Have |
| FR-SVC-15 |
The system shall prevent (or clearly flag) a client from submitting a new request once the cycle’s quota is exhausted. |
Must Have |
3.4 Add-on Services
| Req ID |
Requirement Description |
Priority |
| FR-SVC-16 |
The system shall allow one or more services to be configured as add-ons to a parent service. |
Should Have |
| FR-SVC-17 |
The system shall allow a client to select a parent service and any of its linked add-ons together on an order form. |
Should Have |
| FR-SVC-18 |
The system shall group a parent service and its selected add-on(s) into a single order upon checkout. |
Should Have |
3.5 Pricing Variants
| Req ID |
Requirement Description |
Priority |
| FR-SVC-19 |
The system shall allow a Workspace Admin to define one or more pricing variant categories for a service (e.g. Word Count, Turnaround Time). |
Must Have |
| FR-SVC-20 |
The system shall automatically generate the full combination matrix of variant options and allow a distinct price per combination. |
Must Have |
| FR-SVC-21 |
The system shall allow specific variant combinations to be disabled so they are not selectable by clients. |
Should Have |
| FR-SVC-22 |
The system shall display the correct combination-specific price to the client in real time as variant options are selected. |
Must Have |
3.6 Quantity Handling
| Req ID |
Requirement Description |
Priority |
| FR-SVC-23 |
The system shall allow a ‘Group Multiple Quantities’ option to be enabled on a service. |
Could Have |
| FR-SVC-24 |
When grouping is enabled, the system shall combine a quantity greater than one into a single order. |
Could Have |
| FR-SVC-25 |
When grouping is disabled, the system shall create one independent order per unit of quantity ordered. |
Must Have |
3.7 Team Assignment & Deadlines
| Req ID |
Requirement Description |
Priority |
| FR-SVC-26 |
The system shall allow a service to be configured with a default team member auto-assignment. |
Should Have |
| FR-SVC-27 |
The system shall automatically assign new orders for the service to the configured team member, while still allowing manual reassignment. |
Should Have |
| FR-SVC-28 |
The system shall allow an internal deadline (turnaround time) to be configured per service. |
Should Have |
| FR-SVC-29 |
The system shall start the deadline countdown only once the client has submitted the required project/intake data, and shall not expose the deadline in the client portal. |
Should Have |
3.8 Catalogue Organization
| Req ID |
Requirement Description |
Priority |
| FR-SVC-30 |
The system shall allow services to be reordered via drag-and-drop, with the new order persisted and reflected on client-facing pages. |
Could Have |
| FR-SVC-31 |
The system shall allow services to be grouped into folders for internal organization, with each folder supporting its own description and image. |
Could Have |
| FR-SVC-32 |
The system shall display only active/published services to clients; draft, disabled, or archived services shall be excluded from all client-facing views. |
Must Have |
3.9 Validation, Permissions & Deletion Rules
| Req ID |
Requirement Description |
Priority |
| FR-SVC-33 |
The system shall prevent deletion of a service that has active subscriptions or open orders without an explicit confirmation/warning step. |
Must Have |
| FR-SVC-34 |
The system shall enforce that only authorized roles (per configured permissions) can create, edit, or delete services. |
Must Have |
| FR-SVC-35 |
The system shall log or otherwise make auditable any change to service pricing, ensuring existing active subscriptions are not silently altered. |
Should Have |
4. User Stories & Acceptance Criteria
User stories are grouped by role to clarify who benefits from each capability and what conditions must be met for the story to be considered complete.
4.1 Workspace Admin User Stories
| ID |
User Story |
Acceptance Criteria |
| US-WA-01 |
As a Workspace Admin (Admin role), I want full access to create and manage services, so that I can maintain the service catalogue on behalf of the agency. |
- Admin-role users can create, edit, and delete services.
- Access matches Super Admin capability unless explicitly restricted.
|
| US-WA-02 |
As a Workspace Admin (Manager role), I want to view and edit services within my granted permissions, so that I can support catalogue management without full administrative control. |
- Manager can access the Services module.
- Restricted settings (per role configuration) are hidden or disabled.
- Unauthorized actions are blocked server-side, not just hidden in the UI.
|
| US-WA-03 |
As a Workspace Admin (Contractor role), I want my access limited to my assigned orders only, so that I only see work relevant to me and client/business data stays protected. |
- Contractor cannot access Services configuration screens.
- Order lists are filtered to assigned orders only across all status tabs.
|
| US-WA-04 |
As a Workspace Admin, I want to be auto-assigned as the responsible team member when a client purchases a service configured with my name, so that I immediately know what work is expected of me. |
- New orders for the configured service appear in my assigned list without manual intervention.
- I can still reassign the order if needed.
|
| US-WA-05 |
As a Workspace Admin with a custom role, I want my Services permissions to be precisely scoped (e.g. view-only), so that the Super Admin can safely delegate catalogue visibility without giving edit rights. |
- Custom role permissions for Services (view/edit/delete) can be independently toggled.
- A view-only user can see service details but cannot save changes.
|
4.3 Client Portal User Stories
| ID |
User Story |
Acceptance Criteria |
| US-CP-01 |
As a client, I want to see only active, published services when browsing the pricing page or order form, so that I’m never confused by unavailable or draft offerings. |
- Draft/disabled services never appear in client-facing views.
- Only currently active services and their current prices are shown.
|
| US-CP-02 |
As a client, I want the price to update automatically as I select pricing variant options, so that I always know exactly what I’ll be charged before checkout. |
- Selecting any variant combination instantly reflects the correct configured price.
- Disabled/invalid combinations cannot be selected.
|
| US-CP-03 |
As a client, I want to add relevant add-ons alongside the service I’m purchasing, so that I can customize my order to my exact needs in a single checkout. |
- Available add-ons are shown alongside the parent service.
- Selected add-ons are itemized in the cart and combined into one order after purchase.
|
| US-CP-04 |
As a client, I want to purchase a free service without being asked for payment details, so that low-friction offers (like consultations) are quick to claim. |
- Checkout for a $0 service skips the payment step entirely.
- Order is created immediately upon submission.
|
| US-CP-05 |
As a client, I want to know clearly when my trial ends and full billing begins, so that there are no surprise charges on my account. |
- Trial terms (price, length, next billing date) are clearly presented at signup and on the receipt/confirmation.
- No charge beyond the trial price occurs before the trial ends.
|
| US-CP-06 |
As a client on a request-based subscription, I want to submit a request against my monthly quota and see my remaining balance, so that I can plan my usage across the billing cycle. |
- Remaining request count is visible and accurate after each submission.
- Attempting to exceed the quota is blocked with a clear message.
|
| US-CP-07 |
As a client, I want my purchase of multiple quantities of a groupable service to result in a single, organized order, so that I don’t have to manage several disconnected orders for one purchase. |
- Quantity > 1 on a grouped service produces exactly one order reflecting the full quantity.
|
5. Business Rules & Assumptions
- A service’s price type (One-Time or Recurring) cannot be changed after active orders/subscriptions exist against it without administrative override.
- Only one recurring behaviour (No Action / Reopen / New Order / Service Requests) applies to a given service at a time.
- Deadlines are always internal; the client portal never displays a due date or turnaround countdown.
- Folders are an organizational construct for the workspace admin side only and do not alter what a client sees on the order form.
- Disabling a pricing variant combination does not affect clients who purchased that combination prior to it being disabled.
- Role-based permissions (Workspace Admin, Manager, Contractor, or custom roles) are enforced server-side, not only hidden in the UI.
6. Non-Functional Requirements
- Usability: Service configuration screens shall be usable by non-technical agency staff without developer assistance.
- Performance: Pricing calculations (including variant combinations) shall reflect on the client-facing form in real time, with no perceptible lag.
- Security: Only authenticated, authorized roles may create, edit, or delete services; all such actions shall be auditable.
- Data Integrity: Changes to an active service’s pricing shall not retroactively alter amounts already billed to existing subscribers.
- Availability: The Services Module shall be available whenever the client portal and order forms are available, as service data underpins both.
7. Assumptions & Constraints
- This document assumes the Services Module operates within the existing DSP platform architecture and integrates with the Order Forms and Order Management modules described separately.
- Payment processing itself (Stripe/PayPal integration) is assumed to be handled by the platform’s payment layer and is out of scope here.
- Multi-currency and multi-language behaviour for service pricing/descriptions is governed by workspace-level settings and is referenced but not detailed in this document.
Appendix A: Glossary
| Term |
Definition |
| Service |
A sellable unit of work or deliverable configured by the agency, offered to clients via order forms or the pricing page. |
| Pricing Variant |
A configurable option (e.g. word count, package tier) that changes the price of a service based on the client’s selection. |
| Recurring Behavior |
The rule that determines what happens to a subscription’s order when it renews: no action, reopen the same order, create a new order, or reset service-request quota. |
| Service Request |
A single unit of work drawn against a subscription’s monthly quota for request-based recurring services. |
| Add-on |
An optional supplementary service that can be attached to and purchased alongside a parent service. |
| Trial |
A free or reduced-price period offered before full recurring billing begins on a subscription. |
| Folder |
An organizational grouping of services used for internal/admin-side structuring of the service catalogue. |
