> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/service-automation/define-a-service.md).

# Define a service

Start a service by describing the result you promise and how it will be verified. A useful definition lets a builder, operator, and AI assistant interpret the same outcome consistently.

## Before you start

Have a short service name, a measurable promised outcome, and explicit success criteria. You will also need a released Execute work item to continue through the Service Flow step.

## Complete the Definition step

<figure><img src="https://3857940684-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJcSHU5jP5GABQrGmWvW2%2Fuploads%2FowZki7yrXHBUe5WE0GCE%2F24-service-definition-11.jpg?alt=media" alt="The request-intake service definition specifies fictional request data and action-log success criteria."><figcaption></figcaption></figure>

Open **Execute → Services** and start **Create Service**. The wizard presents four steps: **Definition**, **Service Flow**, **Phase behavior**, and **Review & Publish**.

| Field                                | What to enter                                                             |
| ------------------------------------ | ------------------------------------------------------------------------- |
| **Service Name**\*                   | A concise, recognizable name for the service.                             |
| **Risk Context**                     | Relevant operational constraints or risks for the service being designed. |
| **Promised Outcome**\*               | The result the service commits to produce.                                |
| **Success Criteria**\*               | Observable conditions that demonstrate the outcome was achieved.          |
| **Value per Verified Outcome (USD)** | The value assigned to each verified outcome, where applicable.            |

An asterisk identifies a required field. **Promised Outcome**, **Success Criteria**, and **Value per Verified Outcome** appear together in **Outcome Definition**.

## Write a definition that can be tested

Use the request-intake example from [Build a Hyperflow](/userguide/build-automations/build-a-hyperflow.md) as a small first service. Its local work prepares the text `REQ-DEMO-001 | VPN access | Maya Chen`.

Use the following definition for a service built around that example:

| Field                      | Example                                                                                                                           |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Service Name               | Docs - Request intake service - 20261013                                                                                          |
| Promised Outcome           | Prepare a readable summary of the sample access request.                                                                          |
| Success Criteria           | Inspect the String Assign result in the linked Work Item action log. Its text must equal REQ-DEMO-001 \| VPN access \| Maya Chen. |
| Risk Context               | Local demonstration with fictional data and no external application changes.                                                      |
| Value per Verified Outcome | 0 for this non-commercial exercise.                                                                                               |

The service promise is to prepare the summary. Creating a VPN account would be a different, larger promise, requiring application actions and an independent check of the resulting account. Keep the first service small enough that its actual result is easy to inspect.

For a Prove step, the check should compare the actual summary against the expected request values. An action that always assigns “verified” cannot establish that the summary is correct. Build the output contract and comparison before adding that claim to the service definition.

The request-intake service's **v1.1.0** definition specifies the action log as the evidence for this local exercise. Check the assigned text and the Case's pinned version separately. The configuration screenshot is a design example; the captured service run SC-3 used the earlier **v1.0.0** service and Work Item.

## Continue to the lifecycle

Select **Continue** to configure **Service Flow**. Define an entry point, add the work needed in Govern, Execute, and Prove, and select released versions. The next step cannot be reached with an empty Execute phase: the designer reports **“Execute needs at least one work item.”**

The presence of **Review & Publish** in the wizard does not mean the draft has been published or deployed. Keep design, publication, deployment, and a completed service case as separate milestones.

Continue with [Configure entry points and service flow](/userguide/service-automation/configure-entry-points-and-service-flow.md).