To collect client information in one place, give every required answer, file, deadline, and response status one system of record. Email or chat can still handle clarification, but the final response belongs in the Request.
Treat each collection job as a defined workflow: build the Request, choose its client audience, publish it, monitor visible progress, and review the response before handing work to its next owner.
Capture the complete collection job
"One place" does not mean every conversation has to happen in the form. It means your team can open one record and see what the client needs to provide, what has arrived, and what happens next.
| Collection item | Where to capture it | What the team can verify |
|---|---|---|
| A required answer | A required Request field | Whether the visible required field has a response |
| A client file | A file-upload field | The submitted file in the response and the account Files structure |
| A deadline | The Request due date | Whether the published Request is current or overdue |
| Follow-up work | A named handoff step after review | Who creates or assigns the work that follows |
Before you publish, confirm the Request has one client account, the right portal audience, only the fields needed for the next decision, a real due date when timing matters, and an internal owner for response review.
Define what a Request is collecting
In Sydnee, a Request is a branded, client-facing form connected to one client account. Your team creates and publishes it so portal members can provide structured answers, files, or signature responses.
Use Requests for jobs such as:
- New-client onboarding
- Creative briefs
- Recurring document collection
- Access and configuration details
- Structured feedback or confirmations
A Request is not a public anonymous form, Task, contract platform, or general-purpose automation engine. If a client needs to initiate a service ticket or express interest in another service, that belongs to the supported Service Showcase workflow instead.
Build the smallest complete form
Start with the decision or work that follows the response. Ask only for information that changes that next step.
Sydnee Requests support field types for text, contact details, dates, choices, uploads, signatures, and other structured inputs. Section headings organize the form, and conditional rules can show or hide fields or sections based on earlier answers.
Use a reusable Request template when the structure repeats. Review the template for each client instead of assuming every stored question still applies.
For a deeper form-design process, use the guide to build client intake forms that reduce follow-up.
Choose the right client audience
Each Request belongs to one client account. Your team can assign it to:
- One selected portal member
- Several selected portal members
- All active portal members on the account
A private Request is available only when one portal member is selected. “Private” describes who can see it; it does not mean the full Request is end-to-end encrypted.
Choose the audience before publication. Selecting several recipients does not create a separate private response set for each person. Review Request recipients and privacy before publishing.
Publish with an intentional deadline
Keep a Request in draft until the form, audience, and instructions are ready. Then publish it immediately or schedule publication for a future date and time.
When the work has a real deadline, add a due date. Due dates support the overdue state and the current reminder options. Scheduled reminders use supported offsets around the due date rather than an arbitrary automation schedule.
You can also send a branded publication email with a custom message. Treat email as the notification that work is available, while the Request in the portal remains the place for the response.
Monitor progress without inventing a status
The team Request board separates Draft, Scheduled, Published, Overdue, and Completed work. While a client responds, the team can review visible-field progress and required-answer completion.
Use the labels for what they mean:
- Published: available to the intended portal audience
- Overdue: published and past its due date
- Completed: the Request reached its completed state
An overdue Request does not escalate itself. A completed Request does not mean legal acceptance, project approval, or automatic Task creation.
Review the response and hand off the work
When the client finishes, review the current form state or the chronological response timeline. Download visible responses as a PDF or package submitted upload fields as a ZIP when that format helps the next step. The response review and export guide covers the current controls.
Files uploaded through Request fields are also stored in the account's Files system under a Request-oriented structure. Other answers remain part of the Request response.
The handoff after review should be explicit:
- Confirm the required answers and files are present
- Resolve any ambiguity with the client
- Create or assign the active work that follows
- Keep uploaded files in the appropriate account folder structure
- Complete or archive the Request according to the process
Sydnee does not provide a general rule that turns every completed Request into a Task or Deliverable. Your team or a supported integration must perform the next action.
Walk through a recurring document Request
Suppose an agency needs performance inputs from a client before preparing a quarterly review.
- Start from the approved quarterly-input Request template.
- Assign the Request to the client contacts responsible for the data.
- Add a due date that leaves time for review.
- Configure the supported reminder schedule.
- Publish the Request with a short explanation of what the team needs.
- Monitor required-answer progress instead of searching email for attachments.
- Review the submitted answers and files.
- Create the Tasks required to prepare the review.
The Request organizes collection. The Task board organizes the work created from that information.
If the same collection job repeats across accounts, use a reusable client workflow template as the reviewed starting point. The template standardizes the questions; the Request still needs the correct client, audience, deadline, and handoff each time.
Avoid request-management mistakes
Collecting information through several channels
If email, chat, and a form all count as the official response, your team must reconcile them manually. Redirect required answers and uploads to the Request.
Sending one Request to the wrong audience
Account-wide, selected-user, and private Requests serve different needs. Confirm who should see and respond before publication.
Treating a due date as an escalation plan
The due date powers overdue status and reminders. Decide who follows up when the Request remains incomplete.
Stopping at completion
The response still needs review and a handoff into active work. Name that owner before publishing.
Keep collection structured from start to handoff
An organized client Request has a defined purpose, appropriate audience, intentional due date, visible progress, and a named review step. That gives the client one place to respond and your team one record to evaluate.
If you are comparing ways to centralize client information collection, explore Sydnee Requests. When you are ready to build the workflow, use the Request publication guide to verify the audience, due date, reminders, and email choices before sending.
