A 30-day target is useful only when it ends with a process people can actually use. Pick one contained workflow, keep the existing system of record, and make the owner, evidence and next decision visible. The schedule below is an illustrative plan, not a delivery guarantee.
Before day one: choose a workable first process
Choose work that repeats often enough to measure and has a clear trigger and owner. A procurement exception, inspection follow-up or customer commitment can work. Avoid a first process that needs unresolved policy decisions, a new master-data programme or several unproven integrations. Name one business sponsor and one operational owner.
Days 1–5: map the real journey
Follow a recent example from request to closure with the people who do the work. Capture the trigger, each handoff, the decision authority, the system that owns the business record, required evidence and the most common adverse path. Record the baseline: volume, time to first owner, total cycle time and work reopened or returned.
Gate: the sponsor agrees the problem, scope and closure definition. If the team cannot agree who decides an exception, resolve that before configuration.
Days 6–12: design the minimum useful workflow
- Use a short set of meaningful stages and one accountable next-action owner at a time.
- Link to the ERP or CRM record instead of copying it into another master.
- Specify the minimum fields, evidence and approval authority needed at each decision.
- Define a returned, rejected, overdue and reopened route as well as the normal route.
- Limit notifications to events that change someone's next action.
Gate: a user can explain who owns each step, what evidence is needed, and what happens when it cannot proceed.
Days 13–20: configure and test end to end
Configure in a controlled environment. Run representative scenarios: a normal case, missing evidence, reassignment, an overdue item, a rejected decision and a reopened case. Test permissions for different roles and check the record link and any write-back in the target systems. If a field worker uses a mobile portal, test that rendered journey separately. Configuration readback alone is not proof that users can complete it.
Gate: the operational owner signs off the scenarios and knows how to reverse or pause the launch if a control fails.
Days 21–30: launch with a small cohort
Train the first users on the real task, not a feature tour. Give them a short route for help and name the person reviewing exceptions each day. Keep a daily list of missing fields, confusing handoffs, unowned items and duplicate notifications. Change one issue at a time and retest the same scenario.
Gate: the team demonstrates the complete path with real authorised users, including the adverse path and closure evidence. Expand only after the sponsor accepts the measured results.
What to measure after launch
- Share of new work with an owner and next action within the agreed time.
- Median and oldest age by stage, not only total completed volume.
- Items returned for missing information and reopened after closure.
- Decisions made with the required evidence and authority.
- User adoption and any work still happening outside the workflow.
Compare these with the baseline and review them with the team. A dashboard is useful only if it changes a decision or prompts an intervention.
When the 30-day target is unrealistic
Pause the timeline if data access, approval policy, security permissions or a required integration is unresolved. Do not work around those gaps with ungoverned spreadsheets or a hidden manual step. It is better to launch one narrower, complete process than claim a broad rollout that users cannot finish.
Frequently asked questions
Must we replace our ERP or CRM?
No. Keep those systems authoritative for their records and transactions. Use the workflow to coordinate people, decisions and evidence around them where needed.
What proves that the first process is live?
A real user can complete the normal and exception routes in the intended environment; permissions, evidence, linked records and reporting are verified. A configured model or attractive page is not enough.
Next step
Bring one repeatable process, its owner and a recent real example to a working demo. For the operating model behind this approach, read what a process operating system is and how to manage a cross-team case.
Intelliflow Editorial Team. This is an illustrative implementation framework; timing and available capabilities depend on the process, configuration, integrations and customer readiness.