A customer asks an MSP to automate employee offboarding. The demonstration works, the project is approved and the service goes live. Three weeks later, the customer adds another application and asks for urgent departures to be handled outside normal support hours. Is that part of the original service?

A managed automation service description should make this question answerable before the first request arrives. It explains the outcome being delivered, the conditions required to deliver it and the decisions that remain with the customer.

The document does not need to describe every technical component. It needs to help sales, delivery, support and the customer agree what they are buying and operating. The following is a practical content checklist for that description.

Lead with the outcome and the eligible request

Start with a specific result. For an illustrative offboarding service, that might be handling an authorised departure request across a named set of systems and reporting the verified outcome and any exceptions.

Then define what makes a request eligible: who can submit it, the required employee reference, effective date and time zone, approved action set and any prerequisites. An incomplete or disputed request should have a documented path back to the customer.

Keep the outcome realistic. If a third-party application provides limited confirmation, describe the evidence available and how an unresolved check is handled. Avoid promising a certainty the operating team cannot demonstrate.

Write the scope in a table people can use

Replace the examples with agreed decisions. A table full of words such as “appropriate”, “timely” and “as required” still leaves the operating team to negotiate the service during an incident.

Separate customer responsibilities from provider work

The MSP may operate the workflow while the customer owns employment decisions, application policy and approval authority. Make those responsibilities visible at each point where the service can stop.

For example, the customer supplies an authoritative departure event and resolves conflicting dates. The MSP validates the request against the agreed inputs, executes the permitted actions and investigates technical failures within its scope. An application owner decides whether a particular access exception is allowed.

Assign responsibility to roles with an escalation route, rather than relying entirely on named individuals. People change jobs and take leave. The service should continue to have an owner when that happens.

Also describe dependencies on other suppliers. The MSP may coordinate an incident involving a destination application without controlling that supplier’s restoration time. Keep that dependency visible when agreeing customer expectations.

Describe failure as part of normal delivery

Customers need to understand how the service behaves when only some actions complete. A useful service description distinguishes successful completion, a request awaiting customer input, a technical failure and an unresolved outcome that requires verification.

For each state, identify the communication and next owner. If three applications confirm access removal and a fourth is unavailable, report those facts separately. A generic “failed” label can conceal work already completed; a generic “done” label can conceal outstanding access.

Define how repeated requests are handled. A duplicate event should not automatically create a new chargeable project or trigger conflicting actions. The actual implementation needs a way to relate retries and updates to the underlying business request.

The production handover checklist provides a complementary view: whether the team receiving the service can operate these states without depending on the original builder.

Make the change boundary commercially clear

Separate normal operation from a change to the service. Correcting an expired connection, investigating a failed execution and adding a new application are different kinds of work. The description should explain how they are assessed and who authorises any additional scope.

Consider configuration changes as well as new features. A customer may change its approver group, business hours or evidence requirements. Some adjustments may fit the agreed service; others may change risk, effort or dependencies enough to require review.

Avoid a blanket promise of unlimited change. Instead, make the route understandable: submit the request, assess impact, agree scope, test and release. That gives the customer a predictable conversation and protects the delivery team from unplanned obligations.

The public onITnow case study illustrates integration delivered as a managed service. Its commercial approach is a useful discussion example, not a standard price or a promise that every customer has the same requirements.

Check the description against three difficult requests

• An urgent departure arrives after hours. Can the customer find the correct route, expected handling and authority requirements?
• A new application is added to the employee package. Can delivery explain what is included now and what needs assessment?
• The service owner leaves the customer organisation. Can support identify the replacement authority without inventing an approval chain?

If the answer requires several private messages between sales and engineering, revise the description. Test it with a person who did not attend the original project meetings. Their questions are a useful indication of where the service still relies on shared history.

Connect the description to the service economics

Scope determines operating effort. Review how exceptions, customer-specific changes and support coverage affect the cost of delivering the agreed outcome. The MSP automation ROI guide can support that calculation without replacing the scope discussion.

Choose one repeatable customer request and write its service description before expanding the offer. Bring that outcome, its boundaries and its support model to a discussion about building repeatable MSP services with Autom Mate.