Skip to main content
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.
1

Give it a title

Smith Residence — Signed Contract.
2

Leave the client on Auto-detect, or pick one

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.
3

Attach the project, if it exists

Optional.
4

Choose the file and Upload & Analyze

PDF, DOC, DOCX or an image.
5

Review everything it extracted

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.

​
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

​
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:
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: 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.