A useful plan makes the next step clear.

1. Goal and people

Goal: give the client and the delivery team a shared view of one request, the agreed scope and its current status. This plan is an example, not a proposal for a real customer.

• Client: sends a request, reviews a proposal and checks progress.
• Coordinator: clarifies the request, prepares a proposal and records delivery progress.
• Owner: controls team access and resolves exceptions.

2. The core workflow

A client sends a request. The coordinator clarifies it and prepares a proposal. The client approves the latest proposal. The coordinator moves the project through agreed stages and records delivery.

• A proposal needing changes returns to the coordinator; the previous version remains in history.
• Only an approved proposal can move into delivery.
• The client and coordinator see the same status, with the next action clearly named.

3. First-version boundaries

The first production version covers request intake, proposal review, approval and a shared project status. A coordinator prepares proposals manually. Scope is confirmed after the demo review.

• Include: client and coordinator access, request records, proposal versions, approval history and project status.
• Include in production engineering: validation, access control, backups, monitoring and a recovery procedure.
• Defer: online payments, chat, advanced reporting, mobile apps and automatic accounting sync.
• Free demo only: fictional records and simulated role changes. It is not a production application.

4. System and information flow

A browser interface sends requests to an application API. The API checks access, validates changes and stores requests, proposal versions, approvals and project updates. Notifications are a separate delivery step; the stored record remains the source of truth.

Keep the architecture small until actual scale and integration requirements justify more components. The final technology choices follow existing systems, team ownership and operating constraints.

• Client interface → application API → request and project storage.
• Coordinator interface → the same API and records, with different permissions.
• Stored updates → notification delivery → email provider; failures remain visible for recovery.

5. Integration assumptions

For this example, no existing CRM is required for the first release. Email notifications are the only proposed external connection. This assumption must be checked with the client before an implementation estimate.

• Confirm which system owns client and company information.
• Confirm email-provider access, sandbox options and notification requirements.
• If CRM or accounting sync is essential, inspect the relevant API before committing to scope.
• No real provider calls or customer data are needed for the free demo.

6. Risks and open questions

These questions are deliberately visible. The initial plan identifies decisions to make; it does not claim that two days of discovery can answer every security, product or integration question.

• Can one client belong to several organisations, and who may approve for each?
• What exactly does proposal approval mean for the business, and what record is needed?
• Can the scope change after approval, and who must accept the revision?
• Which records need retention limits, export or deletion?
• Who owns the production accounts and responds when something fails?

7. Delivery stages and checks

Free stage: agree one workflow and a start date; deliver this initial plan by working day 2 and the demo by day 5. Review the result together. The document stays with the client and private demo access lasts 30 days.

Paid stage 1: confirm remaining assumptions, acceptance criteria, ownership, scope and price. Implement the core journey with real access control and durable data.

Paid stage 2: verify integrations and failure handling, prepare operating documentation and run an agreed release check. Launch only with the client's approval.

• A client can see only the requests they are authorised to access.
• Approval records the exact proposal version reviewed.
• A repeated submission does not create a second request when the same submission key is used.
• A failed notification does not erase the request or appear as confirmed delivery.
• A coordinator can see and recover incomplete work.

8. The review decision

Try the client-portal demo, note where the journey fits and where it needs to change, and resolve the questions that affect the first release. Then choose whether to continue with a priced development stage.

This sample includes no project price or launch-date commitment. Full specifications, security audits, production integrations and source-code handover are outside the free stage and must be agreed separately.