The customer lifecycle
Ten stages, in order. The first one is paid and produces a written deliverable, so you find out whether BetterWrk is right for you before you commit to replacing anything.
Paid · weeks 1–2
ProcessScout examines how the work actually moves: the systems involved, the handoffs, the spreadsheets in between and the places where people are doing by hand what software should be doing. You receive a written picture of what we saw, what it is costing and what should change.
You get: a documented workflow, sized friction, a prioritised list of improvements and a recommended operating environment. It is useful whether or not you buy the suite.
Weeks 3–4
The critical requirements are written down and approved with you. This is the document the fit promise is measured against, and it is where an honest conversation about exceptions happens — before anyone has spent money on the wrong thing.
You get: every approved critical requirement marked native, configured, integrated, built or accepted exception.
Weeks 3–4
How your entities, roles, approval authority, data scopes and workflows map onto the suite. Where your process is genuinely better than the default, the software changes. Where the default is better, we will say so.
Weeks 5–8
Configuration, data migration, integration with the systems you are keeping, and the initial customer-specific changes identified in the Blueprint. BetterWrk does this work. You are not handed an implementation plan and left to resource it.
Weeks 9–10
Every approved critical requirement is acceptance-tested against the Blueprint, with you, before go-live. Anything that fails is fixed or explicitly re-classified as an accepted exception. Nothing quietly slips.
The commitment: 100% of approved critical requirements are accounted for and acceptance-tested before go-live.
Go-live
Cut over by area, not by faith. Feature gates mean a step that goes badly is switched off rather than escalated. Support is one place, whichever application the problem appeared in.
Continuous
Observation begins on day one, so improvement is measured against a real baseline rather than a memory of how bad things used to be. Users are asked about specific work at the moment it happens.
Continuous
Evidence becomes a proposal, sized and costed against your Fit Capacity. Your named owners approve or decline. Payroll, finance, permissions and contract logic always require the customer approver.
Continuous
Tested, gated, released to your organisation first, monitored afterwards and reversible. A release you dislike is a switch, not a project.
Quarterly
What was released, what it was supposed to change, and whether it did. Improvements that did not work are reported as such. The Fit Blueprint is updated as the business changes, because the requirement list from launch year is not the requirement list from year three.
Timing
Real timelines depend on your scope, your data and how quickly your own approvers can meet. This is the shape, not a contractual commitment.
Illustrative timeline
| Period | Typical activity |
|---|---|
| Weeks 1–2 | Evidence gathering and Trail Map |
| Weeks 3–4 | Fit Blueprint and launch scope |
| Weeks 5–8 | Configuration, migration and integration |
| Weeks 9–10 | Acceptance and controlled go-live |
| Weeks 11–12 | First ProcessScout outcome review |
Fit methodology
The fit promise is only meaningful if the words in it are defined. Here is what each one means.
Requirements come out of the Trail Map evidence and your own operating knowledge. A requirement is critical if the business cannot run correctly without it — a legal obligation, a control, a customer commitment or a step with no viable manual fallback. Preferences are recorded separately and are not covered by the promise.
Each approved critical requirement has a test written against it before build. The test is run with you before go-live. A requirement is not accounted for because someone believes it works.
Requirements discovered after the Blueprint is approved are handled as ongoing improvements, not as launch scope. Anything depending on a third party we do not control is scoped as integrated, with that dependency stated.
That every approved critical requirement is accounted for in one of the five categories and acceptance-tested before go-live. We do not warrant that your software will be perfect forever, that every future request will be free, or that every suggestion will be released.
Common questions
No, and we would usually advise against it. Most launches start with the workflow the Trail Map identified as most expensive, and integrate with the systems you are keeping. Adding modules later is a scope conversation, not a re-implementation.
BetterWrk. One provider, one support route, one accountable party for the environment — including the integrations we built and the open-source components we distribute. There is no triage argument between vendors, because there is only one vendor.
Less than a traditional implementation, but not zero. We need access to your systems and evidence, time from the people who know the exceptions, and named approvers who can make decisions. The single biggest cause of delay is an approver who cannot get to a meeting.
No. Feedback is unlimited; releases are not automatic. ProcessScout sizes the problem, BetterWrk proposes the honest intervention — which is often training or configuration rather than new software — and your named owner decides. An included allowance covers approved customer-specific improvements.
You are taking a dependency, and it is fair to price that risk. Your data and configuration are exportable throughout. Buy + Assure adds an operating licence and a qualifying fallback operating right, and escrow is available. We would rather you asked this now than in year four.
A Trail Map documents the workflow, identifies the highest-value improvements and shows what the right operating environment should look like.
Start with a paid Trail Map
Start