> ## Documentation Index > Fetch the complete documentation index at: https://docs.menaia.com/llms.txt > Use this file to discover all available pages before exploring further. # Handle the Customer's Response > What happens after you send — opened, signed, changes requested, rejected, or expired — and exactly what to do next. After you send a proposal, the customer takes it from there. You don't have to sit and watch — Menaia **notifies you** each time they act, and the proposal itself always shows its current state. This page covers every response and your next move. You're notified when the customer **opens**, **signs**, **requests changes**, or **rejects** a proposal — and, where WisePick is enabled for your branch, when they **upload competing proposals**. Each notification includes a button that takes you straight to the proposal. ## The customer opened it The first time the customer opens the proposal, you're notified that they viewed it, along with when. Nothing is required of you — it's a great cue to follow up while the proposal is fresh in their mind. ## The customer uploaded competing proposals When **WisePick** is enabled for your branch, the customer can upload competing quotes from their proposal page for an AI side-by-side comparison. When they do: * You're notified that the customer uploaded competing proposals. * Opening the proposal shows a banner: *"Your client uploaded competing proposals. Leverage our analysis or view documents."* * **View WisePick** opens the same side-by-side analysis the customer saw — pricing, materials, scope, terms, credentials, warranty, and overall quality. * The **view documents** link takes you to the uploaded files themselves, in the project's **Competing Proposals** media folder. * Admins, Sales Admins, and Sales Members also see the uploaded files in the **Documents** section of the project page, each labeled with the customer's original file name so you can tell them apart. This is a strong signal the customer is actively comparing options — read the analysis before you follow up, so you can speak directly to how your proposal stacks up. ## The customer signed (approved) This is the goal. When the customer signs and approves: * You're notified that the proposal was **signed**, with the signer's name and date. * The proposal records the **signature, name, date, and the payment option they chose**, and shows **Approved Proposal**. Open the proposal from your notification and check the signature and the payment option the customer selected. Go to the estimate and mark it **Sold**. This is what turns the won deal into a real job and work order for your team. A signed proposal is a record. Re-editing the underlying estimate reopens it for a **change order** and removes the signature, so a **Start a change order?** dialog asks you to fill in **Change order notes** describing what's changing first — they're required and visible to your client. The signed proposal is preserved as a read-only earlier version, so you don't lose the record — see [Version history and change details](#version-history-and-change-details). Don't reopen a signed estimate unless you truly need to change the scope. ## The customer requested changes If the customer wants something adjusted, they choose **Request Changes** and write a note describing what they'd like. Then: * You're notified that the customer **requested changes**, and the notification includes their message. * The proposal shows the request so anyone on the team can see it. Open the proposal and read exactly what they asked for. Adjust the estimate or proposal as needed — revise scope or pricing in the Calculator (or on the proposal itself, for an estimate built from scratch), tweak the note, or update the payment options. Click **Resend Proposal** to send a fresh secure link with the updated version. Resending clears the earlier "changes requested" state so the customer is looking at the current proposal. ## The customer rejected it If the customer declines, they choose **Reject Proposal**. They can pick a reason and add a note, though both are optional. The reasons they can choose from are: | Reason | | - | | Budget concerns | | Not what I'm looking for | | Not ready to sign | | Terms not acceptable | | Other (please explain below) | You're notified that the proposal was **rejected**, along with the reason and any note they left. The proposal records the rejection. A rejection isn't always the end. The note often tells you what to fix — adjust the proposal and **Resend** to give them an updated version, or follow up directly to talk it through. ## The link expired Secure links are time-limited to protect the customer's information, so a link can **expire** before the customer acts. If they click an expired link, they see a page explaining it expired and, when self-service is available, an option to request a new one that's emailed immediately. You can also just click **Resend Proposal** to send a fresh link yourself. Expiration only affects opening the page again — it never changes a signature that's already recorded. While the customer hasn't responded yet, the action bar on their proposal stays open with **Approve**, **Request Changes**, and **Reject** available. Once they pick one, the proposal reflects that state. ## Version history and change details Every time a proposal is signed or its estimate is marked **Sold**, Menaia saves a read-only copy of it as a numbered **version**. If the scope later changes through a change order, you and the customer can look back at what was agreed before and see exactly what changed. If you don't see version history on a proposal that's been through a change order, it isn't turned on for your workspace. ### When a version is saved A version is saved automatically when: * **The customer signs the proposal.** The version records who signed and when. * **The estimate is marked Sold** without a signed proposal, for example when you sell it by hand or re-sell it after a change order. The version shows as **Marked sold**. Versions are never edited after they're saved. If a proposal was signed before version history was available, reopening it for a change order saves its signed state as **Version 1** first. ### Open the Version History panel The **Version History** panel appears once a proposal has more than one version to compare — typically after its first change order. Open or close it with the **version history** button (a calendar-and-clock icon) at the top of the proposal. On a phone, the button is labeled **Version history**. The panel lists versions newest first. The top card is the **Current** version, and what it says depends on where the proposal is: | Current card shows | What it means | | - | - | | **In progress** | A change order is underway. "Edits made in the estimate apply to this version." It becomes a saved version once it's signed or sold. | | **Awaiting client signature** | You've sent the updated proposal and the customer hasn't signed it yet. | | **Signed** or **Sold** | The newest saved version is the active proposal. | Every earlier version has a **Signed** or **Sold** badge, who signed it (or "Marked sold") and when, and "View only — editing disabled." ### View an earlier version Click an earlier version's card to open it in place of the live proposal. A banner names the version and the date it was signed, followed by "It was replaced by an updated proposal and can't be approved or changed." Nothing on an earlier version can be edited or sent. Click **Go to current version**, or the Current card, to return. ### See what changed Each version that followed an earlier one has a **Change order history** section on its card, and so does the Current card while a change order is in progress or awaiting signature — once there's at least one change. It lists: * The **change order notes** entered when the estimate was reopened (on saved versions). * Each change, marked **Added**, **Changed**, or **Removed** — line items and work areas (including quantity changes), tax, attachments, **Notes to client**, and **Project allowances** — with the dollar difference where there is one. * The **Total** before and after, with the difference. These summaries are generated for you. For more detail, click **View full change details**. The panel switches to **What changed in Version 2** (for example), with every field change, the total difference, and a **View Version 1** button to open the version it's compared with. Click **Done**, or the back arrow, to return to the version list. For a pending version, the details show what's changed so far and update as you edit. ### What the customer sees The customer gets the same **Version History** panel on their proposal page. Their Current card reads **Awaiting your signature** until they sign the updated proposal. They can open earlier versions read-only, and use **View full change details** on a version's change history — including the version they're being asked to sign — to review the changes before they approve. ### The change order banner While a signed estimate is reopened for a change order, the top of the proposal shows a banner: "Signature removed — this estimate was reopened for a change order." It names who signed the earlier version and when, the version number it was saved as, and your change order notes. On the **Estimates** list, an estimate with saved versions shows how many under its status, for example "2 signed versions." Photos and videos used by a saved version stay available to that version. If you delete one from the project's media, it's removed from the gallery, but earlier versions that include it still show it. ## Response states at a glance Emailed to the customer; waiting for them to open it. The proposal shows a **Sent Date**. The customer viewed the proposal at least once. You're notified of the first open. The customer approved and signed. Confirm the payment option, then mark the estimate **Sold**. The customer asked for an adjustment and left a note. Update the proposal and **Resend**. The customer declined, optionally with a reason and note. Follow up or revise and **Resend**. The secure link timed out. Click **Resend Proposal** (or let the customer request a new link) to restore access. ## What's next The sending flow, resending, and the secure access link. Review, payment options, and signing — from their side.