# The client already said no to that plan.

You open the proposal and recognize the problem immediately. It recommends replacing everything at once, even though the client already explained why they cannot do that.

Your team should be working out how to make the change succeed for the client. Instead, the next draft repeats a conversation you thought was settled.

## The meeting went well. The next draft forgot it.

You lead a small client team. In the last meeting, the client explained that operations cannot stop while the new system goes in. You agreed to start with one team and expand after it works.

A colleague picks up the proposal in a different AI tool. They have the old scope and the latest pricing, but not the reason for the phased approach. The draft comes back with a single cutover.

You catch it, find the notes and explain the decision again. The client never sees this draft, but your team still paid for the same conversation twice.

Where the explanation gets lost:

1. Client explains the constraint
2. Reason stays in meeting notes
3. New draft proposes a single cutover
4. You explain and rewrite

## We’d start with the decision that keeps getting lost.

We’d trace the brief from the meeting to the writer. Which decisions must survive that handoff? Who has agreed to them, and who can change them?

For this proposal, the useful thing to save is specific: the client needs to keep operating, so the rollout starts with one team. We would not begin by importing every file the company has ever produced.

## The next writer needs the reason, not just “phase the rollout.”

Ask an assistant connected to Korium to save the agreed approach and the source. In this illustration, the note could say:

> The client must keep operating during the change. Start with one team, review the result and agree the next phase before expanding. A single cutover was rejected because it would interrupt operations.

**Source:** The client meeting notes and the follow-up confirming the agreed approach.

## The proposal starts with the client’s constraint already accounted for.

Now your colleague asks their connected assistant to draft the delivery plan. Its instructions tell it to search Korium before writing, so it can find the agreed approach and check where it came from.

The assistant has a reason to propose a phased plan, rather than a vague instruction to make the proposal sound right.

A plan based on the saved explanation:

1. Draft a first phase for one team.
2. Include a review before wider rollout.
3. Flag commitments that still need the client’s agreement.

Your team still checks the scope, price and promises before anything goes to the client. Korium supplies the earlier decision; it does not approve the contract.

## Which parts of Korium help here?

Memory keeps the client’s decision. A proposal workflow makes checking it part of preparing the next draft.

### Memory: Keep the reason for the phased rollout.

Korium:mem keeps the client’s constraint, the rejected single cutover and the meeting where the team agreed the approach. A writer using another connected assistant can retrieve that explanation before drafting.

### Workflows: Check the agreement before writing, then get the draft reviewed.

We’d set up a proposal workflow that has the assistant read the client decisions, draft the phased plan and bring unapproved commitments to your team. After the client responds, it includes saving any agreed change back to memory.

What we’d set up with you: We’d connect the assistant and adapt the proposal workflow to your review process. You can start by saving and retrieving the client decision; this example does not need code lookup or a separate proposal-writing skill.

## The next meeting can move the proposal forward.

Suppose the client approves the pilot but changes which team goes first. Save that decision with its source and connect it to the earlier plan.

The next writer can see what applies now and why it changed. They do not have to choose between two contradictory documents or rely on the person who happened to attend both meetings.

With the agreed constraints in the draft, you and your colleague can work on the questions that still need judgment: what the first phase should achieve, how to keep the client operating and what would justify expanding. A newer colleague can contribute without you briefing them from scratch.

How we would check whether it helped:

- Check whether new drafts respect already-agreed constraints.
- Count the rewrites caused by missing client context.
- Ask whether colleagues can prepare the proposal with less briefing and bring useful options to the review.

## Bring the proposal your team keeps rewriting.

We’d follow one client decision from the meeting to the next draft. Then we’d put Korium into that handoff and check whether your team can spend less time repairing the proposal and more time developing it with the client.