# Partner delivery guide

Use this guide for ERP, finance, HR, CRM, inventory, projects or another business system. Begin with an available system, adapt a suitable starting point or define a new build. Check the chosen system's current capabilities before committing to a client scope.

## Name the people who make it work

| Role                       | Responsibility                                                                                                    |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Client sponsor             | Owns the business outcome, priorities and acceptance decision.                                                    |
| Partner implementer        | Defines the scope, configures or builds the system, validates changes and prepares the handover.                  |
| Client administrator       | Owns day-to-day access, configuration and operating guidance after delivery.                                      |
| Employees using the system | Explain the real work, try representative tasks and report obstacles. They do not need to become system builders. |

One person can hold more than one role. Record who has each responsibility.

## Start with one complete process

Describe the trigger, records, decisions, handoffs and expected result. For example: a purchase request becomes an approved order, a new employee completes onboarding, or a warehouse transfer reaches its destination.

Agree what belongs in the first release and what will wait. Inspect the starting system together and separate existing behavior from changes still needed. For a new build, agree the records, relationships, roles and first workflow before expanding the scope.

## Build against an agreed brief

Give Proto the relevant system or builder skills and a brief with the required changes. Ask it to propose a plan before making changes. Review the affected records, permissions, workflows and integrations with the client administrator.

Use a separate test workspace and sample data where available. Keep passwords, API keys and sensitive client records out of the brief. Let authorized administrators configure access through the appropriate settings.

## Demonstrate the result

Test the normal path and an exception with representative employees. Check both permitted and restricted actions. Compare imported totals and record counts with the agreed source, and confirm who handles failed integrations or incomplete work.

Write acceptance criteria as observable results: who performs which action, what changes and what evidence proves it. Record remaining gaps and the sponsor's decision before the agreed go-live step.

## Hand over an operating system

Deliver the accepted scope, configuration notes, data mapping, employee instructions and known limitations. Confirm the client's control of its workspace, business data and access decisions. Agree the partner's continuing responsibilities, the support route and how future changes will be reviewed.

Use the discovery worksheet to capture the brief and the handover checklist to close the delivery.