Plan customer setup tasks after acceptance

Start with a verifiable acceptance event

A customer accepts the agreed work. The team still needs to confirm the scope version, collect a few setup choices, assign an internal owner and test that the promised service can begin. If a workflow treats “accepted” as “ready,” a welcome message may announce a service that nobody has configured.

Define one accepted-engagement event and a stable reference for the onboarding instance. Specify who records acceptance, which approved scope it covers, and how a correction or repeated event is recognized. Acceptance opens the setup journey; the final ready-for-service state needs its own checks. The lead-follow-up guide handles inquiry and conversion messages before this boundary. The approval-workflow guide handles who may authorize the underlying agreement.

The downloadable matrix is a planning example, not an integration or a result from a Kinetivy client. Replace its fictional tasks and time rules with an approved process for the actual service. A task can be manual even when the surrounding handoff is automated.

Map the work in the order it can happen

Work backward from “ready for service.” What must be true for that claim to be honest? A workspace might need to exist, the right staff might need access, a kickoff might need to be agreed, and a sample request might need to pass. Write each as an observable outcome. Then name its prerequisite: provisioning should use the accepted scope; access should follow an authorized role list; a readiness notice should follow a checked setup, not a successful API response alone.

Some tasks can run in parallel after acceptance. Others must wait for customer input or a staff decision. The BPMN standard provides tasks, gateways and timer events for representing such paths, but it does not choose the right business sequence. A simple dependency column can be enough for a small team. Keep a visible state for waiting on the customer, waiting on staff, blocked by a conflict, and completed with evidence, so “in progress” does not hide the next action.

Name one accountable owner for each outcome and a deputy for absence. A group queue may help people claim work, but someone must still see unclaimed or overdue items. Camunda documents assignees, candidate groups, due dates, follow-up dates and completion events as one product example. Check what the chosen tool can actually enforce, especially task permissions; a label in a task list is not authorization.

• Acceptance gate: engagement reference, approved scope version and person allowed to start setup.
• Setup task: expected result, prerequisite record or task, accountable owner and deputy.
• Wait state: missing customer input, internal review or external system action, with a next check and owner.
• Completion gate: evidence that the intended business state exists, plus the person who verifies it.

Use the ten-column onboarding matrix

Download the CSV above. It contains a blank row and a fictional equipment-service journey with normal setup tasks and exception rows. Make one row for each task whose outcome or owner can differ. Keep the live working copy in an access-controlled location; a public template should contain no customer names, contacts, contract text, credentials or private record identifiers.

Use a stable reference to connect tasks without copying the full accepted agreement into every tool. Write the exact prerequisite evidence, not only “after sales.” Define the person who checks the result and what they inspect. Mark unresolved provider behavior as an open test. A row is ready to automate only when the trigger, allowed action and failure destination are supported by the actual systems.

• Onboarding step and intended outcome | Start event and stable reference | Prerequisite and hold condition | Accountable owner and deputy | Required input and minimum data | Allowed action and destination | Due or follow-up rule | Exception route and stop rule | Completion evidence and verifier | Privacy, retention and open test.
• The start event identifies the accepted scope version; the prerequisite says what must be true before the task can act.
• The due or follow-up rule records a business choice, not a universal reminder cadence. State who may change it when the customer requests a pause.
• The completion column distinguishes a queued action, a provider acknowledgment and the verified business result.

Tie reminders to an open task and a useful next action

A reminder should tell the right person which unresolved task needs attention and where to act. Set the first follow-up, maximum repeats and escalation owner according to the actual promise and working hours. A customer-facing reminder for missing setup input has a different recipient and tone from an internal alert that a provisioned workspace failed its check.

Before each scheduled send, check the current task state, owner, customer preference and any pause or cancellation. Stop the reminder when the task is completed, replaced or no longer eligible. Camunda documents a non-interrupting timer that can branch to a notification while a task remains open, and an interrupting timer that can move a timed-out activity to another route. That is a modeling pattern, not a prescribed schedule. The notification-design guide covers message channel and delivery-state choices in depth.

If a customer has not supplied an optional preference, do not repeatedly ask for information that is not required to begin. If a required input is missing, keep the dependent work on hold with a named owner and a manual contact route. Never turn a missed reminder into an unverified “complete” state.

Close only when the service can actually begin

Choose evidence for each outcome before building the automation. A task-create acknowledgment proves a task was created; it does not prove that the assigned person saw it. An API success response for workspace creation does not prove that the customer has the intended access. Microsoft documents HTTP 202 as accepted for processing, with completion still pending; use that distinction as a reminder to check the real target state, even when the chosen products use other protocols.

For a fictional equipment-service setup, the readiness check could inspect the approved service scope, a confirmed internal owner, a workspace with the intended permissions and one synthetic request that follows the expected route. Record the check result, date and verifier against the engagement reference. The exact checks vary by service. Do not mark a customer as ready because every automation step shows green if a prerequisite is still waiting or disputed.

Keep evidence useful and proportionate. OWASP recommends recording when, who, what and result for relevant events, while excluding secrets and sensitive personal data from general logs and limiting access to them. Store the completion reference or status in the operational record and keep detailed customer material in its authorized system. Where UK data-protection rules apply, ICO guidance calls for personal data to be limited to what is necessary; the applicable legal duties depend on the organization and jurisdiction.

Hypothetical journey: an equipment-service account

Imagine a fictional company that services equipment for other businesses. An authorized employee records an accepted service agreement with a scope reference. The coordinator checks the service locations and assigns a setup owner. A technician workspace is then prepared using the approved role list. A verifier runs a synthetic service request and checks the result before the coordinator marks the account ready. These are invented planning steps, not Kinetivy client work or a measured outcome.

The CSV shows those tasks and separate rows for missing location details, a repeated acceptance event, changed scope, an absent owner, a failed workspace check and a cancelled engagement. Each row either holds the dependent action or sends it to a named person. A repeated acceptance event should find the existing onboarding reference rather than open a second setup. A material scope change should return affected tasks to review before a readiness notice goes out.

The example uses event gates such as “before workspace setup” and “before readiness notice” rather than claiming a universal number of days. The team should set any actual deadlines and reminder cadence with its service owner. Failed transactions, uncertain retries and cross-system reconciliation belong to the automation-failure-recovery guide; this matrix records the customer-facing setup consequence and the next accountable action.

Rehearse the journey before using live records

Walk an accepted sample engagement through the matrix with synthetic data. At each task, check the prerequisite, actual destination record, owner view and completion evidence. Then repeat with a missing required input, duplicate acceptance, changed scope, unavailable owner, failed provisioning check and cancellation. Confirm that blocked tasks stay visible and no readiness message is sent prematurely.

Review the map when the accepted agreement, service scope, team roles, connected tools or required customer data changes. The business owner decides what “ready” means; a technical owner confirms the configured steps, reminders and stop controls still match it. If the tool cannot enforce a required hold or expose evidence, keep that step manual until the gap is resolved.