A customer onboarding portal is a shared workspace where your customer can see the implementation plan, complete their tasks, submit intake information and leave comments without living in your internal tools. Done well, it replaces the email threads, spreadsheet trackers and "where's that form?" pings that slow every rollout. Done poorly, it either overshares internal work or under-shares the few items the customer actually needs.
This guide defines what a customer onboarding portal is, what to put in front of the customer versus what to keep internal, and the access mistakes teams make when they first share a project. For the broader collaboration model behind a portal, see vendor-customer collaboration during implementation.
What Is a Customer Onboarding Portal?
A customer onboarding portal is the customer-facing slice of your implementation project. It is not a second project management tool and it is not a full copy of your internal workspace. It is a controlled view of the work both sides must finish to reach go-live.
In practice, a good portal answers four questions for the customer:
- What are we supposed to do next?
- What has already been completed?
- Where do we submit information or approvals?
- Who do we talk to when something is stuck?
Your internal team still needs the full plan: private notes, internal dependencies, risk flags, billing context and unfinished drafts. The portal only exposes the shared layer. That separation is the whole point. Customers should never have to join your internal workspace just to mark a kickoff form done.
Portal vs Project Management Tool vs Shared Folder
Teams often try to cover the portal job with whatever they already have. The mismatches show up quickly.
| Approach | What it is good at | Where it breaks for onboarding |
|---|---|---|
| Shared folder or drive | Storing files and decks | No task ownership, no status, no intake forms |
| Generic project tool invite | Full task tracking | Exposes internal work, comments and unfinished drafts |
| Email and spreadsheets | Fast to start | No single source of truth; ownership and dates drift |
| Customer onboarding portal | Shared tasks, forms, comments and approvals with controlled visibility | Needs deliberate choices about what is customer-visible |
The portal is closer to a project tool than a folder, but with a hard visibility boundary. Project access and per-task visibility are separate controls. Giving someone access to the project does not automatically show them every task.
What to Show Customers: The Shared Checklist
Start from the customer's job, not from your full task list. Most onboarding portals should include some mix of the following.
- Shared milestones. Kickoff complete, data connected, training delivered, go-live criteria met. Customers need the checkpoints that define progress, not every internal subtask under them.
- Customer-owned tasks. Provide SSO contacts, map fields, schedule training, approve the cutover window. Anything that waits on the customer belongs in the portal with a clear owner and due date.
- Intake and information forms. Technical contacts, environment details, success criteria, security questionnaire answers. Attach forms to ordinary tasks so the request lives next to the work it unlocks.
- Customer-visible comments and files. Clarifications, decisions and attachments the customer is meant to see. Keep internal debate off that thread.
- Approvals and completion signals. Let customers mark their side of an open task done, and let them retract that signal while the task is still open. Your team still controls the internal task status separately.
- A short "how to use this portal" note. How they sign in, who to contact, and what "done" means on their tasks.
If a shared item does not help the customer act, complete or approve something, it probably should stay internal.
What to Keep Internal
Oversharing is as damaging as undersharing. Keep these off the customer view by default:
- Internal-only tasks. Prep work, QA, vendor coordination, legal redlines you are still drafting.
- Internal comments and risk notes. Speculations about the deal, salary or discount discussions, and half-finished diagnoses.
- Unpublished forms and draft questions. Customers should only see published forms. Editing a published form creates a new draft; customers continue to see the published version until you publish the changes.
- Billing, margin and commission context. Useful for your team, distracting or sensitive for the customer.
- Incomplete information requests that are not yet ready. An incomplete attached information request blocks customer completion signals, so do not share the task until the form is ready.
A useful rule: if you would not put it in a customer email today, do not make it customer-visible in the portal.
Intake Forms, Comments and Approvals
Most of the waiting in onboarding is waiting on information. That is why forms belong on tasks, not in a separate survey tool with no link back to the plan.
A practical form setup for onboarding looks like this:
- One form per task. Keep each request focused: technical contacts on one task, integration requirements on another.
- Question types that match the answer. Short text, long text, email, number, date, multiple choice and checkboxes cover most intake needs. Mark required questions and add help text where answers are easy to misread.
- Conditional questions. Ask about the existing system only when the customer selects a migration option. Each question can depend on one earlier answer.
- A clear response policy. Choose one response across all recipients when you need a single canonical submission, or allow updated responses when details will change during the project.
- Reusable templates. Onboarding intake, implementation requirements and similar starters keep the questions consistent across customers. Each task still gets an independent copy you can tailor.
Comments sit next to the work. Customers can read customer-visible comments, add comments on open tasks and submit published forms. Closed tasks become read-only, which protects the record after a phase ends.
In Quivly, these pieces live together: the Customer Portal controls project access and per-task visibility, task forms collect the answers on the relevant task, and form templates keep intake consistent across projects. Publishing a form does not invite anyone or make a task visible. Customers also need access to the shared project and task.
Access Mistakes Teams Make
Most portal failures are access mistakes, not feature gaps. Watch for these:
- Inviting before choosing visibility. Add people only after you have enabled the tasks they should see and reviewed descriptions, comments and files. Project access alone does not make every task visible.
- Sharing the whole project when only three tasks matter. Hide the rest. Hiding a task removes it from the portal, including access through a direct link.
- Skipping the customer preview. Use a "view as this user" preview to confirm what they will see. Comments and status changes are disabled in that preview, so it is safe to inspect.
- Confusing form preview with portal preview. Previewing a published form as the customer opens the live form. Submitting it creates a real response and can use a one-response allowance. Do not submit sample answers on a customer's only-response form.
- Wrong email address. The customer must sign in with the invited address. If the invitation or code never arrives, confirm the address, check spam and resend. People appear as Invited until they sign in, then Active.
- Leaving access open after the person leaves. Revoke access when a contact rolls off the project. That removes the project from their portal. Other projects shared with them stay available. Removing their last project grant also ends their portal sessions.
- Empty project syndrome. The customer opens the portal and sees nothing. Almost always, they have project access but no customer-visible tasks. Fix visibility, then preview again.
How to Roll Out a Portal Without Breaking Trust
Treat the first shared view as a customer deliverable.
- Build the internal project fully, including private tasks.
- Decide the shared milestone list and the customer-owned tasks under each one.
- Attach and publish intake forms on the tasks that need them.
- Enable task and milestone visibility for the shared set only.
- Preview as the customer contact.
- Invite the right emails and confirm they reach Active status.
- At kickoff, walk the customer through the portal for five minutes so they know where to work.
Update visibility as the project moves. Early on, intake and kickoff dominate. Later, cutover approvals and training completion matter more. Revoke access for people who leave the account team instead of letting old contacts keep a quiet window into the plan.
If you want one place for the shared plan, customer tasks, intake forms and controlled access, Quivly's Customer Portal is built for that split between internal work and customer-visible work. Pair it with your onboarding milestones so every account sees the same checkpoints without seeing your internal scaffolding. For how those milestones fit a 30-60-90 plan, use the customer onboarding plan template.
