Map the first request
Start with the information needed to decide whether you can help. A name, reply address, project type, and description are often more useful than a long form full of questions the customer cannot answer yet. Distinguish required details from optional ones, and explain what will happen after submission.
Confirm the request was received
A customer needs to know whether a submission actually reached the business. Show a clear confirmation only after the request is saved. A reference number helps with follow-up. If the customer will use a private project page, explain how to keep and reopen it. Do not promise an email or text notification unless that notification is actually connected.
Make statuses mean something
Choose a small number of useful states such as received, under review, proposal ready, in progress, and completed. Each should describe a real stage. “Confirmed” should not simply mean a form was submitted. Where appropriate, explain the next action and who is responsible for it.
Keep proposals and payments connected
A payment request should relate to an agreed scope or milestone. Show what the amount covers and the relevant invoice or request. Payment status and project progress are separate: a customer can pay a deposit while development has not begun, or finish a review while a balance remains due. Opening a payment page is not proof that money arrived.
Protect the private part
Public project examples and private client records serve different purposes. Keep proposals, contact information, conversations, and payment details behind the correct access controls. Limit the information exposed in notifications and links. A private access link should be treated like a key, and shared only with the people who should see the project.
Build for the moments that fail
Consider duplicate submissions, interrupted connections, a changed proposal, or a lost access link. A customer should be able to retry safely and get a useful explanation. The business needs a way to verify identity and recover access. These details are part of the workflow, not finishing touches after the page looks good.
A status map the customer can understand
This example separates the business decision from payment and delivery. Adapt the labels to your service; do not display a stage until the underlying event has actually happened.
| Stage | Trigger | Customer’s next step | Owner’s next step |
|---|---|---|---|
| Received | The request was saved successfully. | Keep the reference and private access route. | Check whether enough information was provided. |
| Needs details | The owner identifies a specific missing decision. | Answer the focused question. | Review the answer before promising a scope. |
| Proposal ready | A versioned scope, price, and terms are available. | Review, ask questions, or approve the version shown. | Record the decision against that proposal. |
| In progress | Agreed start conditions are met and work has begun. | Review the next milestone when it is ready. | Keep milestones and unresolved decisions current. |
| Delivered | Agreed deliverables and access have been provided. | Run the acceptance checks and report discrepancies. | Resolve defects within the agreed support scope. |
Keep payment status independent
A proposal can be approved while a deposit is outstanding. A deposit can be verified while the project is still scheduled for a future start. Use a separate payment record with amount, currency, invoice reference, and verification source. An opened checkout page or a customer’s statement does not establish settlement. Avoid publishing private financial records in a public progress page.
Try the workflow with fictional records
- Submit a test inquiry, record its reference, and check the owner can find the same request.
- Interrupt one submission and retry. Check for both lost work and duplicate requests.
- Revise a proposal after a customer approves it. Check that the revised scope does not inherit approval automatically.
- Open two independent customer sessions. Verify that messages and documents remain with the correct request.
- Rehearse lost-link recovery through the documented support route. Do not recover access merely because someone knows a customer’s name.
Record the actual result for each exercise, including failures. Use the scope and handoff guide to decide which checks are required before launch and who will own the unresolved work.
Have a project in mind?
Share what you know. We’ll review the idea and discuss a clear scope before any payment.
Start a project inquiry ↗