For each portal component, choose the shortest route that lets the client complete the actual process. Use a checklist for structured choices, an external portal when a partner maintains the authoritative record, direct contact when discussion is necessary, and upload–review–approval for document-based collaboration.
The mistake is forcing every topic into the same form. A kitchen choice, an appointment with a healthcare provider and a review of an annotated drawing need different interactions. A portal remains one entry point, but does not need to be the source system for every step. That distinction belongs in the architecture of a customer portal.
Four routes, each with its own purpose
Yindle Portal has four interaction modes for each category:
- Checklist or questionnaire: for repeatable answers, options, quantities and a deliberate submission.
- External portal: for a partner environment in which the action is actually recorded.
- Direct contact: for situations where advice, an appointment or a personal conversation forms part of the task.
- Upload, review and approval: for a base document that the client edits, after which a proposal is returned and reviewed.
These modes are implemented interface patterns. Whether they are sufficient for your process needs to be tested with real scenarios.
Use a route decision tree
Ask four questions in sequence for each component. Can the answer be recorded objectively in a structured form? Choose the checklist. Is an external system demonstrably the authoritative register? Hand over to that portal. Does the step require expertise or negotiation? Make contact the main action. Does a file need to move back and forth with an explicit decision? Use the review route.
If several answers are “yes”, split the task. A client could first indicate preferences in a short questionnaire, then arrange an appointment with an adviser. Two clear steps work better than one form trying to handle every exception.
Worked example: a fictional renovation project
In this fictional example, housing association Morgenhof manages a renovation. It uses a checklist for colour choices. The actual order for custom sunshades goes through the supplier’s portal. An accessibility modification requires a home visit and therefore gets a contact route. For socket locations, the resident downloads a floor plan, uploads annotations and later reviews the detailed proposal.
The resident dashboard shows four topics, each ending differently. The external route clearly states that the choice is stored with the supplier. The contact route shows who will call and within what timeframe. The review route always shows which document needs attention. One overview thus stays clear about four different endpoints.
Assess the handover, not just the button
A route is complete only when the return path is clear too. Use this check table:
| Route | Evidence of completion | Important failure path |
|---|---|---|
| Checklist | Submission confirmation and summary | Incomplete or submitted twice |
| External portal | Status from the partner or a clear manual check | Client returns without a result |
| Contact | Appointment or callback action | Nobody owns it |
| Review | Decision on an identifiable version | An old proposal is approved |
The current Portal route to an external partner does not automatically record every external completion. If you want a status written back, an integration or additional working agreement is needed. Make that clear in the design.
Keep the client-facing language consistent
Even when the underlying pattern changes, the heading, status and navigation should remain recognisable . For example, consistently use “What do you need to do?”, “Whose turn is it?” and “When is this completed?” The client then experiences one process rather than four separate applications.
Include at least one failure scenario for each route in a pilot. Make an external system temporarily unavailable, use the wrong file type for an upload, make a contact person unavailable and leave a questionnaire half finished. Assess whether the client sees a safe next step and whether the team knows where the unfinished task will reappear.
Finally, define where the definitive status lives. For a checklist, that can be the portal; for an external partner, it often is not. Without that source agreement, one screen shows “completed” while another still says “open”. That is precisely the confusion a central entry point should prevent.
Explore the different case-file options in Yindle Portal. To choose the right interaction route for each component, work through one complete client scenario with Yindle.