Client information becomes hard to manage when answers arrive in email, files sit in personal inboxes, and nobody can tell what is still missing.
The fix is to treat each information collection job as a defined workflow: build the Request, choose its client audience, publish it, monitor visible progress, and review the response before completing the handoff.
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. Do not assume that selecting several recipients creates a separate private response set for each person.
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.
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.
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 structure gives the client one place to respond and gives your team one record to evaluate.
Explore Sydnee Requests and the Request template library. If your intake requires several audiences or conditional paths, book a demo to test the workflow against your process.
