From process explanations to actions that can actually be followed up

Only turn a process step into an action when someone can actually complete something and the outcome can be checked. ‘Documents’ is a subject; ‘upload the signed intake form’ is an action. Name the owner, desired outcome and any date, and track the status for each file.

Process descriptions explain how a journey works. Actions direct today’s work. When the two are mixed, clients may think an explanation is mandatory or miss a task among informational text. Good customer portal design uses them alongside each other with different visual emphasis.

Write an action as a verifiable sentence

Use the formula: verb + object + criterion. ‘Review’ is too vague. ‘Check proposal v2 and choose approve or amend’ explains the endpoint. Add a date only if it comes from the actual process and someone is responsible for maintaining it.

Yindle Portal separates ordered process steps from action items. For each file, an action can be open, completed or confirmed, with a note and the person confirming it. ‘Step 3’ therefore does not have to be complete for every file at the same time.

Choose who may change the status

Not every task can be ticked off by the client. Distinguish in advance between:

  • Client action: the user provides something or deliberately confirms it.
  • Organisation action: an employee reviews, schedules or publishes.
  • Shared action: one party carries it out and the other confirms the outcome.
  • System signal: a reliable event sets the status automatically.

Avoid automatic completion based solely on a page visit. Seen does not mean understood, and opened does not mean carried out.

Worked example: fictional complaint handling

In a fictional scenario, service company RustigHerstel handles a complaint about paintwork. The process explanation contains four steps: report, assess, plan repairs and complete. Customer Nora’s file contains one specific action: ‘Upload two photos of the damage.’ After upload, this changes to ‘Received; service team review’.

The team then proposes an appointment. Nora accepts the date. After the work, the employee marks the repair as done; Nora is asked whether the complaint can be closed. The process steps stay the same, but actions differ by file and moment. That distinction keeps the explanation stable while making the work personal.

Use an action contract

Complete one card for each action type:

Field Check question
Start Which event opens the action?
Owner Who can carry out the action?
Evidence Which submission, choice or system status demonstrates completion?
Confirmation Does a second party need to check the outcome?
Exception What does the user see if the action cannot be carried out?
Next step Which new action or information follows?

This card prevents ‘we will just mark it complete’ from becoming an unspoken working agreement. It also makes clear which actions belong in a form and which are better handled through contact.

Manage both the backlog and its causes

A list of open actions is useful, but it does not explain why they remain outstanding. Regularly review their age, type and blocker. Ten old uploads may indicate unclear instructions; ten reviews assigned to one employee may be a capacity problem. Adjust the process or wording before sending more reminders.

Include an exception scenario where the requested action is impossible. Nora may be unable to take a useful photo because the damage is behind a fixed cupboard, for example. A safe action then offers ‘I cannot provide this’ with an explanation, after which the team can arrange an inspection. Without that route, the task stays open indefinitely or someone uploads an arbitrary file just to continue.

Also check what happens when the request changes. If the team needs different evidence after opening an action, the original wording must not be silently overwritten as though it had always said that. Close the old action with a short reason and open a new one. Both parties can then understand why extra work was needed.

In the management view, distinguish between waiting for the client, waiting for the organisation and being blocked by a third party. ‘Open’ alone is too broad for reporting. The basic system can record actions for each file; these additional reasons for waiting are a process choice, potentially requiring configuration, that needs to be developed separately.

See how Yindle Portal brings process components and personal actions together. To develop your first action contract, discuss a specific journey with Yindle.

Previous insight
Next insight

Start with your question

Where does your team get stuck?

Your first enquiry does not need to be a technical brief. Tell us which systems you use and where work gets stuck. Together we discuss what is possible and which step you can take next.

Discuss my project