Colay / Guides
Turn multiple AI perspectives into a client proposal
Consultants and agencies need a proposal that helps the client agree to a next step. In Colay, you can collect individual agent responses, discuss disagreements in Consensus and request an HTML presentation of the conclusion. This guide connects that workflow to the client brief, scope boundaries and commitments you can substantiate.
Decide what the proposal needs to achieve
A presentation for an initial meeting serves a different purpose from a proposal ready for approval. The first helps clarify the problem and agree to discovery. The second specifies scope, responsibilities, price and acceptance conditions. State the deal stage in the brief so the draft does not commit beyond what has been agreed.
Describe the recipient, the decision they own and what they already know. A business owner may be choosing a next step while an operations lead checks whether staff can support implementation. That distinction determines which objections deserve attention and what belongs on the slides.
Worked scenario: an agency reviews lost inbound requests
Imagine a client asking an agency to implement a new CRM because some inquiries are being lost. The source material includes a process map and examples of missed requests. It does not establish whether the loss occurs during staff handoffs, data entry or follow-up. This is a hypothetical workflow, not a Colay customer story.
An initial proposal might jump straight to implementation. Review could reveal that replacing the system is not yet justified: unclear ownership may be the real cause. A useful discussion outcome would propose inspecting the process, testing the cause and then agreeing the implementation scope. Evidence supporting a system replacement would lead to a different recommendation.
Carry that reasoning into the presentation: what is known, which uncertainty the first stage resolves and what supports the next decision. A polished description of the new system does not establish that connection.
Review the brief from several perspectives
These are suggested tasks for your prompts, not a built-in panel of certified experts. Use Ask separately for individual initial responses. Provide the same brief and identify where client evidence ends and your assumptions begin.
For a shared conclusion, use Consensus with the brief, relevant excerpts and review notes. Supply these explicitly: separate chats do not automatically become sources for a new request. Ask the discussion to preserve disagreements that the available evidence cannot settle.
- Solution designer: which sequence of work addresses the client’s problem.
- Critic: which claims lack support and which dependencies are missing.
- Recipient’s perspective: what needs clarification before approval.
- Editor: how to turn the reviewed findings into a concise document.
Turn promises into conditions the team can verify
Do not turn unknowns into confident numbers merely to fill a slide. The responsible team must confirm estimates, dates and commitments. Leave a question in the working draft when a value is unresolved; in the client version, state the condition clearly or remove the unsupported promise.
| Draft statement | What to specify |
|---|---|
| We will increase sales | The process change in scope and how its outcome will be assessed. |
| All integrations included | Named systems, required access and agreed limitations. |
| Delivery by the agreed date | The date, dependencies and conditions that start the schedule. |
| Support included | The support period, covered work and ownership boundaries. |
A prompt for the conclusion and presentation
“Using this brief [evidence] and review notes [excerpts], prepare a proposal for [recipient] at [initial meeting or scope approval] stage. Separate facts from assumptions. Check that each proposed activity addresses the client’s problem. Do not invent team experience, testimonials, prices, dates or performance improvements. Identify disputed conditions a person must confirm. Then prepare an HTML presentation covering: client problem; established observations; options and recommended approach; scope and exclusions; dependencies and acceptance conditions; next step.”
Review the substantive conclusion first. Resolve scope or condition changes before final presentation work. Colay’s default Consensus request includes an HTML presentation based on the conclusion, but review the generated result: a model may omit a requirement or present it poorly.
Prepare a version you can use in a meeting
Read every slide from the recipient’s perspective. Does the proposal make sense without a spoken explanation? Is the scope clear? Has compression removed an important condition? Check names, numbers, links and table readability. Remove internal notes that are not intended for the client.
Export the reviewed presentation when needed. Colay’s current PPTX export preserves slides as images; individual labels are not editable PowerPoint text objects. If you need changes to slide text, make them before exporting or plan additional editing.
Evaluate the workflow through the time you spend revising and the clarity of the conditions you can agree. This scenario does not establish a preparation-time benchmark or sales improvement. Account for credits and repeated generations. Start with one anonymized brief and one proposal section on which the team disagrees.
Bring your next question to Colay
Choose a model, use Auto, or bring several perspectives together with Consensus.