Hemory TeamOn this page
A customer says the display units must now be assembled by one person without tools. Your approved proposal assumed two installers. Before changing the proposal, you need to establish the new need, which parts of the baseline it affects, and whether your team has agreed to deliver it.
Review the change against the accepted baseline. Use earlier conversations to recover the reason and limits, then separate the customer’s requirement from your team’s investigation or delivery commitment. The result should tell the proposal owner what can be carried forward and what still needs a decision.
Start with the baseline the proposal actually uses
Find the accepted proposal, specification, or scope record. Record the relevant behavior and constraints, not every item in the document. A new request only becomes meaningful as a change when you know what it differs from.
Then locate the exchange that raised the need. Read the response too. “We need this” may establish the customer’s position; “we will assess it” establishes a different commitment on the supplier side.
If you need to reconstruct the full history first, use tracing requirement changes across meetings. This review uses that history to decide what belongs in the next proposal.
Ask what changes, what stays, and what is still undecided
| Review question | What to establish |
|---|---|
| What does the customer need now? | Required behavior, users, conditions and customer-side confirmation |
| How does it differ from the baseline? | The specific addition, removal, clarification or priority change |
| What remains unchanged? | Existing constraints that the new request does not replace |
| What did our team accept? | Investigation, design work, delivery, or no commitment yet |
| What decision blocks the proposal? | The feasibility, scope, price or timing detail still needed |
A wording change is not automatically extra scope. A clarification may explain what an existing requirement always meant. Conversely, a small-sounding phrase such as “one person” can alter handling, weight or assembly assumptions. Explain the behavior rather than classify the change by how many words it adds.
Keep acceptance specific. The customer can confirm a need that the supplier has not agreed to meet. An accepted investigation does not commit the supplier to the requested implementation.
Example: a handling requirement changes the design review
This fictional exhibition-display project illustrates the review. It is not a customer case, engineering assessment or Hemory output. The materials available on November 4 establish:
| Source | Information provided |
|---|---|
| October 6 accepted proposal | Six freestanding display units, ash finish and printed labels. Assembly assumes two installers. |
| October 20 venue discussion | The customer’s exhibition lead says the units will move between venues and asks for one-person assembly without tools. The supplier agrees to investigate feasibility. |
| October 27 clarification | The exhibition lead confirms the one-person, tool-free requirement. The number of units, ash finish and printed labels remain required. |
| November 2 supplier review | The design lead commits to a feasibility assessment by November 7. No revised construction, price or delivery date is accepted. |
The venue discussion explains the need: repeated moves by the customer’s team. It does not establish that a particular joint or construction method will work. The November 2 promise gives the next decision an input; it does not settle that decision.
A change-review note for the proposal owner could read:
Baseline: Six display units with ash finish and printed labels;
assembly assumed two installers in the October 6 accepted proposal.
Confirmed customer need: One-person assembly without tools, because
the units will move between venues. Confirmed October 27.
Unchanged requirements: Six units, ash finish, printed labels.
Supplier commitment: Feasibility assessment by November 7.
No revised construction, price or delivery date is established.
Proposal decision needed: Use the assessment to determine whether
and on what terms the new assembly requirement can be accepted.This preserves the new need without silently replacing the accepted proposal with an unsupported delivery promise. It also prevents unchanged finish and label requirements from disappearing while attention is on assembly.
Use Hemory to recover the qualification behind the request
The reason or condition may already be in a customer email or scope note. Use it if it answers the question. If the discussions were captured in Hemory, built-in Q&A can retrieve the relevant exchanges across conversations:
What changed about assembly for the exhibition display units? Find the customer’s reason, the requirements that stayed the same, and what our team agreed to investigate or deliver.
This recovers more than a note saying “tool-free requested.” You can return to the customer’s operating situation and your team’s actual response without asking everyone to reconstruct the calls.
If you are revising the proposal in a compatible AI agent connected to Hemory, give it the accepted proposal and ask:
Prepare a requirement-change review from the accessible Hemory
display-unit discussions and the proposal I provide. Separate the
accepted baseline, confirmed customer need, unchanged constraints,
and our commitments. Identify what needs a feasibility or scope
decision. Draft the review note without inventing a construction
solution, revised price or delivery date.The agent can retrieve and draft together. Supply the assessment separately when it becomes available if the connection cannot access it. Review the distinctions that affect the offer before changing the proposal.
Turn the review into a clear next decision
The proposal owner needs a decision to make, not just a longer meeting history. In the example, the next input is the November 7 assessment. Its result can inform which behavior can be offered and what effect it has on cost or timing. Those terms still need the relevant agreement.
If the assessment supports only part of the requirement, state that limit. If a later discussion accepts a revised proposal, record that acceptance with its scope and date. Keep the earlier requirement and the later supplier commitment connected without treating them as the same event.
For colleagues who cannot open your personal source records, include the baseline, change and open decision in the shared review note itself. A source reference supports the explanation; it cannot replace it.
Use Hemory during future customer discussions to preserve the constraints you may need when an offer changes. You can concentrate on understanding the customer’s work, then recover the detail when the proposal needs it.
FAQ
Is a confirmed customer requirement automatically in delivery scope?
No. Customer confirmation establishes the need. Supplier acceptance establishes what will be delivered and on which terms. Keep both visible in the review.
Should unchanged requirements appear in the change note?
Include the ones that could otherwise be lost or affected. You do not need to copy the entire specification, but a changed assembly requirement should not silently remove an established finish or quantity.
What if the original discussion was not recorded?
Use adequate notes, written agreement or a focused customer clarification. Record a later clarification as a new source. It can establish the current need without proving the exact words used in the earlier discussion.
