Agree service scope, milestones, and revisions

A service Deal needs a clear description of the work. “Design my brand” or “repair the room” leaves too much to interpretation. Record the promised result, what is included, what is excluded, and what the Buyer needs to provide.

For example, a design Deal might include two logo concepts, one agreed final version, specified file formats, and a delivery date. It should also state the included revision rounds. This is an example of clear scope, not a standard package that every service Deal must follow.

A Professional Office describes the service identity. The person fulfilling the work is the Seller in the Deal, and the person paying is the Buyer. Both sides review the same agreement before the work begins.

Where milestones are included, give each stage its own deliverables, amount, timing, and completion conditions. A milestone should describe something the Buyer can actually review, rather than a vague percentage of effort.

The Buyer secures the full agreed amount before work begins. Milestones then follow their agreed completion and release rules in sequence. A completed later stage does not skip an earlier unresolved stage.

The Seller should check that Shyld protection is active before starting. An accepted draft or a message saying payment is coming does not replace that step.

Record the included revision rounds and any correction window before activating protection. A revision changes the work within the accepted scope; a new request may change the scope itself. Discuss that difference before extra work begins.

Keep feedback specific. “The final file is missing the agreed colour version” gives both sides something to check. “I want something different now” needs a conversation about whether the new request was included.

Service completion depends on the agreed path for the work. A deliverable handover can include preview review, final files, and an access-check window. Work presented for Buyer review requires the Buyer to review that presentation and authorize release with their private release passcode.

Some deliverable Deals ask the Buyer to approve the identified preview with their release passcode. That approval authorizes release when the agreed final work is handed over within the accepted conditions. Read that consequence before approving: later help with file access does not reverse a completed release.

Do not assume that attendance, a message saying “done,” or silence during a review always authorizes release. Equally, do not assume every service waits indefinitely for a final confirmation. Read the particular completion and release conditions in your Shyld Agreement.

Keep the requested evidence and feedback in the Deal. If work is missing, access is broken, or the result differs from the agreement, raise the concern within the applicable window and before releasing the affected amount. Use a Support Request if you need help with the next step.