Service Requests
A Service Request (SR) is a task or ticket created against an entitlement. It represents a discrete unit of work: a support question, a configuration change, a bug fix, a feature request, or any other deliverable. Service requests have SLA tracking, credit-based billing, and a defined workflow from creation to billing.
The SR code
Every service request has a unique code in the format SR-YYYYNNNN (e.g., SR-20260042). The code is generated atomically and is used in all communications -- portal, emails, Jira, and invoices.
Workflow
Service requests move through a defined set of states:
| State | What it means |
|---|---|
| Draft | Created, not yet submitted for approval. |
| Pending approval | Awaiting client approval (with estimated credits). |
| Approved | Client approved, ready for execution. |
| In progress | Work is actively underway. |
| On hold | Blocked by an external dependency or waiting on the client. |
| Completed | Work finished. Actual credits recorded. |
| Billed | Included in the client's invoice. Terminal state. |
| Closed | Rejected or cancelled without execution. Terminal state. |
Pre-approved work
If the estimated credits fall within a pre-approved threshold for the entitlement, the SR skips the approval step and goes directly from draft to approved. This reduces friction for routine, low-cost tasks.
SLA tracking
Each service request is subject to SLA targets determined by the service class of its parent entitlement (Free, Basic, Flex, Business, Enterprise, or Government):
| SLA metric | What it measures |
|---|---|
| Response time | Time from SR creation to first meaningful response. |
| Resolution time | Time from SR creation to completion. |
SLA clocks are managed by Jira (which has native SLA rule enforcement). MIDDAG Account reads the SLA state via webhooks and displays it in the portal. MIDDAG Account does not run its own SLA clocks to avoid drift.
Priority levels
| Priority | When to use |
|---|---|
| Low | No urgency. Can wait for the next available slot. |
| Normal | Standard request. Default priority. |
| High | Business impact. Needs attention within the current day. |
| Urgent | Critical issue. Service degradation or outage. |
The customer suggests a priority when creating the SR. The admin can reclassify it based on actual impact.
Credit billing
Service requests consume credits from the customer's credit balance:
- On creation -- estimated credits are reserved (soft-locked) from the balance.
- On completion -- actual credits are debited. If actual exceeds estimated, the difference is debited from available balance or billed separately.
- On cancellation -- reserved credits are released back to the balance.
The billed value is calculated as: actual_credits x complexity_multiplier x base_credit_value. The base value is captured as a snapshot when the SR is created, so future price changes do not affect existing SRs.
Analysis as a separate SR
Some services require a detailed analysis phase before execution (requirements analysis, impact assessment, technical specification). In these cases, the analysis is created as a separate SR linked to the execution SR:
- The analysis SR is billed independently.
- If the client approves the analysis but rejects the execution, only the analysis is billed.
- This protects both parties: the client pays only for work done, and MIDDAG is compensated for the analysis effort.
Two operating modes
| Mode | Context | Who creates |
|---|---|---|
| Standalone | Linked directly to an ENV entitlement. Used for environment maintenance. | Customer (from portal) or admin. |
| Service-linked | Linked to a Service container under a SVC entitlement. Used for project work. | Admin only. |
In standalone mode, the customer clicks "Request Service" on an environment's detail page and fills in title, description, and priority. In service-linked mode, the admin creates SRs as part of the project workflow.
Jira integration
Service requests sync bidirectionally with Jira:
| Data | Source of truth | Direction |
|---|---|---|
| Status | Jira | Jira --> MIDDAG Account |
| Estimated credits | MIDDAG Account | MIDDAG Account --> Jira |
| Actual credits | MIDDAG Account | Calculated from worklogs |
| Billed value | MIDDAG Account | Not synced (billing only) |
| Tasks and subtasks | Jira | Not synced |
| SLA rules | Jira | Jira --> MIDDAG Account (display) |
MIDDAG Account is the financial authority. Jira is the operational authority.
What customers see
In the portal, customers see:
- SR code, title, and description
- Status, priority, and due date
- Client notes (communication thread)
- Credits consumed (after billing)
Customers do not see: internal notes, actual hours, team assignment, or billed value before the SR reaches the billed state.
What admins see
In the WordPress admin, the SR list shows:
- SR code and title
- Organization and linked entitlement
- Service (if service-linked)
- Priority and status
- Estimated and actual credits
- Jira issue key
- Assignment
Related pages
- Services -- the service container that groups SRs
- Environments -- the installations that standalone SRs target
- Credit Balance -- how credits are reserved and consumed
- Entitlements -- the parent access record
- Contracts -- the agreement whose SLA governs the SR