MIDDAG Account

English

Portugues

English

Portugues

Appearance

Service Provisioning ​

When an SVC (Service) or ENV (Environment) entitlement is created, the system provisions a service delivery structure: a Service record, a Contract, a CreditBalance, and a channel for Tickets. This page explains how that structure is built and how service delivery operates day to day.

SVC entitlement activation ​

Service types and lifecycles ​

Each Service has two key attributes:

  • Lifecycle: ongoing (continuous contract, renews periodically) or project (defined start and end date).
  • Type: Categorizes the nature of work -- hosting, support, infrastructure, consulting, development, mobile apps, migration, upgrade, or project management.

What gets created ​

When an SVC entitlement is provisioned:

  1. Service -- A container for all work performed under this entitlement. Linked to the Organization and the entitlement.
  2. Contract -- Created automatically if the ProvisioningPolicy enables it. Contains SLA terms, billing value, start/end dates. See Contract Lifecycle.
  3. CreditBalance -- Initialized for UST-based consumption tracking. Even if the initial balance is zero, the record exists to measure cost from the start.
  4. Jira project link -- If the service maps to a Jira project, the jira_project_key is stored for two-way sync.

ENV entitlement activation ​

ENV entitlements follow a different pattern -- the system tracks the record, but infrastructure provisioning is a manual process:

  1. The system creates an Environment record linked to the entitlement and Organization.
  2. The admin receives a notification to provision the actual infrastructure.
  3. The admin configures: server, primary URL, staging URL, platform type (Moodle, WordPress, custom), backup schedule, DNS records.
  4. The environment status is set to active and becomes visible in the customer portal.

Environments are linked to contracts for SLA coverage. Service requests for maintenance are opened directly against the environment.

The UST consumption model ​

UST (Unit of Technical Service) is the standardized unit for measuring service work. Instead of billing by the hour, each service catalog item has a fixed credit cost:

ConceptHow it works
CreditThe commercial unit. 1 credit = 10 internal units
Catalog itemsEach service type has a base credit cost
ComplexityThree levels: low (1x), medium (1.5x), high (2x)
ConsumptionFIFO -- oldest credits are consumed first

When a Ticket is opened, credits are reserved from the balance. When the request is completed, credits are debited. This prevents overspending while work is in progress.

The CreditPolicy governs expiration, grace periods, limits, and what happens when the balance runs out. See Policies for configuration details.

Ticket workflow ​

Service requests are the operational units of work within a Service or Environment:

Each Ticket has a unique code (SR-YYYYNNNN) and is linked to either a Service or an Environment. The workflow:

  1. Customer creates the request from the portal, selecting the service or environment, describing the work, and setting priority.
  2. Admin reviews the request and approves, rejects, or converts it to a quote if it exceeds the contract scope.
  3. Admin assigns a team member and moves it to in-progress.
  4. Work is performed with progress comments visible to the customer in real time.
  5. Customer approves the completed work.
  6. Credits are debited from the CreditBalance.

SLA tracking ​

SLA targets are determined by the support_class field on the entitlement (Free, Basic, Flex, Business, Enterprise, Government). Jira runs the SLA clocks; MIDDAG Account reads the state via webhooks and displays it in the portal.

MetricWhere it runsWhere it displays
Response timeJiraPortal + admin panel
Resolution timeJiraPortal + admin panel
Uptime targetMonitoringAdmin panel (ENV only)

The SLAPolicy allows customization per level -- response time, resolution time, support hours, escalation rules, and priority levels available to the customer.