Automate project intake around one accepted request revision. Give every request a stable ID, collect the facts needed for a decision, and keep submission separate from approval. Once the business accepts the work, create the project through an idempotent action and read the destination record back. A requested date, signed agreement, or created task does not by itself prove that delivery is ready to start.
What should project intake decide?
Project intake should decide whether a proposed piece of work may enter delivery and which version of the request the team accepted. It should not silently promise a start date, reserve people, expand scope, or turn every incoming message into a project.
Use separate states because each answers a different question:
| State | What it means | Minimum evidence | What it does not mean |
|---|---|---|---|
| Submitted | Someone proposed a piece of work | Request ID, requester, desired outcome, context, and source links | Complete, approved, scheduled, or staffed |
| Decision-ready | The current revision contains the inputs and reviews required by its route | Revision, required fields, sources, dependencies, and unresolved exceptions | Accepted or promised to a client |
| Accepted | An authorized owner accepted the exact current revision into the delivery queue | Decision owner, accepted revision, outcome, conditions, and time | Start date committed, project created, or team assigned |
| Scheduled | A delivery owner made a capacity-aware timing decision | Project owner, planning basis, committed or provisional dates, and dependencies | Project setup verified or prerequisites complete |
| Project created | The delivery system returned a project record for the accepted revision | Destination ID, URL, creation receipt, and source request ID | Correct mapping or readiness to begin |
| Ready to start | The created project passed read-back and the applicable prerequisites have owners | Verified project fields, owner, first action, inputs, access, and blockers | Guaranteed outcome or unchanged scope |
A tiny team may have one person perform several of these actions. The record should still show which decision that person made and when. One approved status hides whether the team accepted the work, scheduled it, created it, or confirmed that it can start.
The sales-to-delivery handoff supplies commercial facts after a sale. Project intake is the wider decision boundary that can also receive internal initiatives, client requests outside a new sale, and work that still needs to be returned, deferred, or rejected.
What belongs in a project intake packet?
The intake packet should contain the minimum reliable information needed to decide and later reconstruct the handoff. Keep original messages and documents beside normalized fields so a reviewer can see where each fact came from.
| Packet field | Preferred source | Stop condition |
|---|---|---|
| Request identity | Stable request ID, submission time, requester, client or internal sponsor | Duplicate identity, no accountable requester, or conflicting records |
| Desired outcome | Requester's description plus a short structured outcome | Activity listed without an observable result, or several unrelated outcomes combined |
| Scope boundary | Current agreement, statement of work, change record, service catalog, or reviewed request | Missing source, conflicting versions, unclear exclusions, or work outside the accepted boundary |
| Timing | Requested date, reason, dependencies, and any actual commitment already made | Requested date presented as promised, impossible dependency, or no scheduling owner |
| Required inputs | Files, access, decisions, contacts, data, and prerequisites | Missing required input, unsafe access request, or no owner for collection |
| Commercial context | Linked proposal, order, contract, budget decision, or internal authorization where applicable | Commercial source missing, inconsistent, expired, or outside the reviewer's authority |
| Delivery context | Service type, likely owner, rough effort range if available, dependencies, and known constraints | No applicable route, unresolved capacity question, or unsupported estimate treated as fact |
| Decision record | Reviewer, authority, request revision, outcome, conditions, comments, and time | Wrong reviewer, stale revision, unclear conditions, or decision made on incomplete sources |
| Destination receipt | Project ID, URL, template, stored source ID, created revision, and read-back result | Duplicate project, missing ID, wrong template, incorrect mapping, or read-back mismatch |
The form should change with the route instead of asking every requester for a complete project plan. A routine repeat engagement, an internal improvement, and an unfamiliar client request need different evidence. Classification can reveal the applicable questions, but uncertainty should produce a visible review state rather than a confident guess.
Keep revision history when a decision input changes. A different outcome, client, scope, price, target date, dependency, data-access need, or delivery constraint may change the route or decision. The workflow should compare revisions, invalidate only the affected checks, and prevent the old acceptance from authorizing the changed request silently.
What should the automated project intake workflow look like?
Use six controlled stages: capture, validate, classify, decide, create, and verify. Each stage should produce evidence, a named owner, and a reason the request can stop.
From project request to verified delivery record
- Captureassign the stable request ID, preserve the original source, record the requester and outcome, and search for related requests.
- Validatecheck the fields and sources required for the current revision, expose conflicts, and return missing items to a named owner.
- Classifyselect the applicable route, reviewers, template, and prerequisites from known rules, while holding uncertain cases for review.
- Deciderecord accept, return, defer, reject, or escalate against the exact revision, including conditions and the decision owner.
- Createmake the project in the delivery system with an idempotency key derived from the request ID, accepted revision, and destination.
- Verifyread the project back, compare its stored values with the accepted snapshot, save the receipt, and expose any mismatch before `ready to start`.
Useful states include draft, submitted, duplicate review, needs information, scope review, commercial review, capacity review, decision pending, returned, deferred, rejected, accepted revision, creation pending, write uncertain, project mismatch, project verified, scheduling pending, ready to start, and closed. State names should describe what the business knows, not simply which automation step ran.
Use the request ID across the form, source documents, comments, decision, project, and activity log. If the create call times out after the destination accepted it, search by that source ID before retrying. An error response does not prove that no project was created.
After creation, read the project from the destination. Compare client or sponsor, project type, accepted outcome, scope reference, owner, dates, template, billing or budget reference when applicable, and source request ID. A green connector run proves only that an operation completed somewhere in the integration, not that the intended delivery record is correct.
How should requested dates and capacity be handled?
Keep the requester's preferred date separate from the delivery schedule. Intake can record urgency and constraints, but a named delivery owner should decide whether the team can commit a start or completion date with the information and capacity available.
Store distinct fields such as requested start, requested completion, reason for date, planning status, provisional window, committed start, and commitment owner. This prevents a form field from becoming an accidental promise when it is copied into a project template or client message.
Capacity checks do not need false precision. A small team may start with visible questions: Who owns the work? Which existing commitment would move? Which skill or access is required? What input blocks the first action? Record the answer and the person who made the tradeoff. Do not let an AI-generated effort estimate or an old project template commit the calendar.
If sales already communicated a date, preserve the exact source and route the conflict. Intake should not overwrite the promise, hide it, or declare it feasible. The responsible commercial and delivery owners need a visible decision and, when necessary, a controlled client follow-up.
What should rules, AI, and people handle?
Use deterministic rules for facts the business can state exactly, AI for bounded preparation, and people for commitments and ambiguous tradeoffs. The control should match the consequence of being wrong.
| Work | Good starting mechanism | Required control |
|---|---|---|
| Assign a request ID, check required fields, calculate age, and detect an exact duplicate | Rules | Stable keys, explicit required fields, and visible error states |
| Route a known service type or request category | Rules | Versioned routing table, fallback owner, and tests for unmapped values |
| Summarize a long request or extract candidate facts from files | AI-assisted preparation | Source links, visible uncertainty, field-level review, and no silent replacement of originals |
| Suggest a known category from unstructured text | AI-assisted classification | Restricted category list, confidence or uncertainty signal, reviewer correction, and evaluation on real examples |
| Decide priority, capacity, unusual scope, or whether to accept work | Person with defined ownership | Current request revision, comparable context, recorded rationale, and conflict route |
| Create the accepted project | Deterministic integration | Accepted revision check, least necessary access, idempotency key, and destination read-back |
| Promise dates, approve scope changes, or send exception messages | Person, with drafting assistance if useful | Named authority, exact approved message, current facts, and send evidence |
An AI summary can shorten a review, but it should not become the evidence. Keep the original request and show which source supports scope, timing, price, dependencies, and promised outcomes. If the model omits a condition, the reviewer needs a way to see and correct it before the decision.
The guide to connecting small-business software explains stable matching keys, ownership, and controlled synchronization. Apply the same principles here: one authoritative request, one accepted revision, and a verified receipt from the project system.
How does project intake connect to neighboring workflows?
Project intake should exchange explicit records with sales handoff, client onboarding, change control, and delivery without absorbing their decisions. The boundary is what keeps one approval from authorizing unrelated actions.
- Sales-to-delivery handoff provides the accepted commercial source, client facts, scope reference, and promises that delivery needs to review.
- Client onboarding collects client contacts, access, documents, billing setup, and kickoff prerequisites after the relationship and applicable work are accepted.
- Change requests decide whether a proposed change modifies an active project's scope, price, timing, or delivery plan. An accepted change may create a new intake revision or a linked work item.
- Project delivery owns tasks, dependencies, progress, risks, and outcomes after the intake record becomes a verified project.
- Offboarding closes delivery, recurring actions, access, assets, and data at the end of the engagement.
Do not copy all fields into every system. Pass the stable request ID, accepted revision, source links, decision, conditions, destination ID, and the fields the next workflow owns. Keep a link back to the source instead of creating several editable copies of the same scope or commitment.
The client onboarding guide covers prerequisites after acceptance. The change-request guide covers revisions to active work. Project intake remains the front door that decides what may join the delivery queue.
How should you test project intake automation?
Test the decision boundaries and failure recovery, not only the happy path. Use closed or fictional requests in a test destination, then compare every result with its source and accepted revision.
- Replay a small set of accepted, returned, deferred, rejected, duplicate, incomplete, and unusual requests. Confirm that each follows the intended route and preserves its sources.
- Change one material field after review. Confirm that the workflow creates a new revision, invalidates the affected decision, and does not alter the accepted history.
- Submit the same request through two channels. Confirm that the duplicate enters review instead of creating two delivery projects.
- Use a requested date that conflicts with capacity or a prior promise. Confirm that the date remains a visible issue and does not become a silent commitment.
- Remove a required input, source document, reviewer, template mapping, or destination permission. Confirm that the request stops with a named next owner.
- Time out the create step after the destination may have accepted it. Confirm that recovery searches by the request ID and accepted revision before any retry.
- Change a destination mapping so the wrong client, owner, template, date, or scope reference is stored. Confirm that read-back detects the mismatch and leaves the project unverified.
- Change a form field, route, role, integration, or project template. Rerun the relevant failure cases as regression tests.
Track measures that reveal the workflow without promising a result: requests by state and age, returns by missing item, time waiting for a decision, post-acceptance changes, duplicates, write failures, read-back mismatches, projects without a source request, and accepted work without an owner. Establish a baseline before claiming faster intake, better capacity use, or fewer mistakes.
When to avoid it
Keep project creation manual when the business cannot explain who may accept work, what information that decision needs, how requested dates become commitments, which system owns delivery, or who repairs a failed handoff. Start with one request register, explicit states, named owners, and a visible decision history. Automate only after two people can interpret the same request consistently.
What to remember
- A submitted request is proposed demand, not committed delivery work.
- Accept one exact request revision and preserve its sources and conditions.
- Keep acceptance, scheduling, project creation, and readiness as separate states.
- Record requested dates without turning them into automatic commitments.
- Use stable IDs and idempotent creation so retries do not duplicate projects.
- Read the destination project back before marking the handoff verified.
- Give AI bounded preparation work, not authority over scope, priority, capacity, or promises.
- Test duplicates, changed revisions, unavailable owners, uncertain writes, and mapping errors before launch.
Use the workflow maintenance guide to assign queue owners, review alerts, update routes, and rerun recovery tests after tools or policies change.
If you want to build this workflow, bring one recent project request, its messages and source files, the resulting project record, and one delayed or changed case to a free 30-minute call. I can help you define the packet, states, decision boundaries, destination checks, and smallest reliable pilot before automation starts creating delivery work.
Frequently asked questions
No. Project intake decides whether one proposed piece of work may enter delivery and on which accepted facts. Client onboarding collects the contacts, access, documents, billing setup, and kickoff prerequisites needed after the relationship and applicable work have been accepted. The workflows should link to each other without sharing one ambiguous status.
Not necessarily. A signed agreement may provide the commercial source for intake, but delivery may still need a named owner, an accepted scope reference, capacity, inputs, access, and a verified project record. The workflow should preserve the signed source and show which operational prerequisites remain open.
It can populate a clearly labeled requested-date field. It should not populate a committed start date unless a defined scheduling decision has occurred. Store the request, the planning status, the person who committed the schedule, and the resulting date as separate facts.
One person can perform several roles in a small business, but the states still help. Record when that person accepted the request, committed the schedule, verified the project setup, and marked the first action ready. This makes changes and missed prerequisites visible without inventing a larger approval structure.
Written by Antoine mazu. Antoine helps small service businesses understand and improve their workflows with solutions tailored to their needs, with or without AI. He combines product thinking with hands-on technical execution from Bayonne, France.
Sources accessed October 17, 2026: Premier, Project intake: turn requests into well-defined work, ScaleLabs, Project Intake Process Best Practices, Asana Help Center, Project intake, AppTrajectory, Make and ClickUp: Automate Project Intake from Google Sheets, and ClickUp, How to Build a Project Intake Dashboard in Google Sheets.
