> ## Documentation Index
> Fetch the complete documentation index at: https://help.getatelier.design/llms.txt
> Use this file to discover all available pages before exploring further.
# Proposals
> What you send before the work is agreed — scope, phases, fee and payment schedule in one document that becomes the project when the client accepts.
A proposal is the offer. It says what you will do, in what order, for how
much, and when you expect to be paid.
It is also the only document in Atelier that **builds the project**.
Accepting a proposal turns its phases into the project's phases — so the
shape you give the work here is the shape the job takes.
## The list
**Finance → Proposals.** Each row: number (`PROP-2026-001`), title,
client, status, created date, expiry and total.
Two ways to start:
* **New proposal** — build it in Atelier: scope, fee and payment schedule,
described below.
* **Upload signed document** — for a proposal agreed elsewhere. Atelier
reads it and fills the fields in for you.
## Uploading a signed contract
If the agreement already exists — signed on paper, drafted in Word, sent
as a PDF before you started using Atelier — you do not have to retype it.
**Upload signed document** takes a PDF, Word file or image and extracts
the **phases, fees and payment schedule** for your review.
*Smith Residence — Signed Contract*.
On **Auto-detect from document**, Atelier reads the name, address and
contacts out of the file and links a matching client — or creates one.
A close-but-not-exact match is put to you for confirmation rather than
guessed at.
Optional.
PDF, DOC, DOCX or an image.
It is a draft for review, not a finished document. Check the phases,
the fee and every payment milestone against the original before you
rely on any of it.
Uploading the file does not accept the proposal by itself — accepting is
a separate, deliberate step once you've checked what was extracted. And
Atelier does not verify that the file actually contains a signature; it
takes your word that this is a signed agreement. Treat it as your own
record, not as proof.
This is the route into Atelier for a studio with a drawer full of live
contracts. Because **phases become the project's own phases on acceptance**,
uploading an old agreement is not just filing a PDF — it reconstructs the
project's timeline from it.
Analysis costs one AI credit per document. See [AI credits](/ai/credits).
## Building one
The form has five blocks, and they are in this order for a reason: what
the job is, what you will do, what you charge, when you get paid, and how
you explain it.
### Project info
| Field | Notes |
| --------------- | ------------------------------------------------------------------------------------------------------------- |
| **Title** | Required. *Interior Design Proposal — Smith Residence*. |
| **Client** | Required. Pulls from your client records. |
| **Expiry date** | When the offer lapses. Worth setting — an open-ended price is a price you will be held to in eighteen months. |
| **Project** | Link to an existing project, or leave it unlinked. |
### Phases — the scope
Phases are the stages of work: Concept Design, Design Development,
Procurement, Installation. Each has a name, an optional description and an
estimated duration in weeks.
**Phases become the project's phases on acceptance — there is no pricing
here.** This is the hinge between Finance and the project: when the client
accepts, the phases you listed appear on the project's Timeline, with dates
derived from the durations you gave. They do not become tasks — the task
board is yours to fill. Describe the job as you intend to run it, not as a
sales document.
Duration is estimated, not dated. You are telling the client *six weeks of
design development*, not committing to a calendar before the job has
started.
### Fee — what you charge
Four fee types:
| Type | Use it when |
| ------------- | ---------------------------------------------------------------------------- |
| **Fixed** | One agreed price for the whole scope. Simplest to sell, riskiest to deliver. |
| **Hourly** | Billed against tracked time. Suits open-ended or advisory work. |
| **Cost-plus** | Your margin on what the job costs — common in procurement-heavy schemes. |
| **Mixed** | A combination: fixed design fee plus a procurement margin, for example. |
The fee is **independent from the payment schedule** — the form says so
itself. How much you charge and when it arrives are two separate
decisions, and keeping them separate is what lets you offer the same price
on friendlier terms.
### Payment schedule — when you are paid
A list of milestones, each with a name, an amount and a **trigger**:
| Trigger | Fires when |
| ----------------------- | ------------------------------------------------------ |
| **On acceptance** | The client accepts the proposal. This is your deposit. |
| **On date** | A fixed calendar date. |
| **On phase completion** | A phase from the scope above finishes. |
That third trigger is the one worth understanding. It ties money to
progress rather than to the calendar, so the client pays for design
development when design development is done — not on the 15th regardless.
A schedule that works for most residential jobs:
1. **Deposit — on acceptance.** Enough to commit the client and cover the
first stage.
2. **Stage payments — on phase completion.** One per phase, so cash
follows the work.
3. **Balance — on phase completion.** Against the final phase, usually
installation.
### Narrative — how you explain it
Three free-text blocks, and the part clients actually read first:
* **Introduction** — you and the project, briefly.
* **Scope of work** — what is included *and what is excluded*. The second
half is what prevents an argument in month four.
* **Terms & conditions** — payment terms, revision policy, cancellation
clause.
## Sending it
**Mark as sent** changes the proposal's status — it does not email
anything. Copy the client link (**Shared**, in the proposal toolbar) and
send it yourself.
## Two ways a proposal gets accepted
* **The client accepts it themselves**, on the public link. They type
their name and click **Accept** — Atelier records that name alongside
their IP address and the timestamp, as a separate record. This is the
version with a real audit trail: who agreed, and when.
* **You mark it accepted**, from inside Atelier — for a deal closed by
phone, in person, or on paper. Nothing verifies this beyond your own
say-so; there is no equivalent record of who agreed to what.
Either path lands on the same `ACCEPTED` status and has the same effect:
* **A DRAFT invoice is created for every milestone** in the payment
schedule — not just the deposit.
* If the proposal wasn't linked to a project, accepting it can create
one, using the proposal's phases as the project's phases.
**Editing an accepted proposal changes what the client sees, immediately.**
Open one and Atelier says so: *"This proposal has already been accepted.
Changes will update the live link immediately. To keep the original,
create a new version instead."* The client is holding a live link, not a
copy. If you need the original preserved — and you almost always do,
because it is the record of what was agreed — create a new version rather
than editing in place.
Once a proposal leaves `DRAFT` the assistant cannot change it, at any
later status including `ACCEPTED`. Changes are made in Finance — a new
version, or a change order.
Scope that grows after acceptance does not belong in a revised proposal.
It belongs in a change order, which keeps the record of what was agreed
when.