> For the complete documentation index, see [llms.txt](https://docs.allshore.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allshore.ai/clients-and-pipeline/proposals-and-collateral.md). # Proposals & collateral A **proposal** is how an estimate reaches a prospect: your pricing summary, optional cover prose, and your firm's collateral — in one email, recorded. ## The collateral library **Collateral** is your reusable attachment shelf: capability decks, case studies, standard terms — whatever you routinely send with pricing. Upload once, attach to many proposals. Any partner staff member can upload and list; **archiving and unarchiving are partner admin actions**. Collateral is immutable once uploaded, which is what makes a proposal's record trustworthy: the attachment ids on an old send still resolve to exactly the bytes that went out. ## Sending a proposal From the estimate, choose recipients, optionally a **cover template** (prose that sits above the pricing table), and any collateral to attach. **Recipients are required, and not defaulted.** The composer prefills them from the client's signer and contacts, but a proposal quietly going to whoever happens to be on file isn't a default worth having — the recipient list is the point of the screen. Several mistakes are caught immediately, while you're standing there: no recipients, an archived collateral document or cover template, an id that isn't yours, and a **collateral set** already too large for email (the error names the limit and what your attachments weigh). That size check is a preflight on your attachments, with an allowance reserved for the pricing summary that hasn't been rendered yet. If the finished summary turns out larger than the allowance, the send can still fail on size *after* you've left the screen — so on a proposal with heavy attachments, confirm it went rather than assuming. Through the conversational connector (Claude, Ally), sending a proposal is **confirmation-gated** — it mails your firm's pricing to a third party, so the assistant must ask first. ## After you send Sending returns as soon as it's accepted and refusable; the summary PDF renders a moment later, and **the history row is created only once that render succeeds**. So a row that hasn't appeared yet means one of two things: the render is still in flight, or it failed before any row could be written. If a proposal never gains a history row, don't assume it's still coming — the send didn't reach the ledger. Send it again (trimming attachments if size is plausible), and if it keeps happening, ask your platform operator to look for a render failure on this estimate in the audit trail. Be aware it's recorded against the estimate and the time, not against a per-attempt identifier, so overlapping retries on the same estimate can be hard to tell apart — resend once and wait rather than firing several. Each row that does appear records the recipients, when the send was requested, its outcome, and a link to the pricing summary **rendered for that attempt** — which is only a summary the client received if the row's outcome is *sent*. Outcomes: **queued** (in progress, or finished without its outcome recorded — ambiguous, so check before resending), **sent** (accepted by the email provider, not proof of receipt), **failed**, and **skipped** (email isn't configured). A failed or skipped row still carries its rendered summary; nothing was emailed. The attachment set isn't on the send row itself — it's in the audit trail for that send, joined by the same request id. Two proposals to the same people with different attachments stay distinguishable. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.allshore.ai/clients-and-pipeline/proposals-and-collateral.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.