What a successful pilot looks like is answered by both sides, in writing, before the pilot starts. Otherwise everyone applies a different measure at the end and the decision is postponed. This page states the scope, duration and limits of a QWorks pilot — and what we do and do not commit to — before the first meeting.
The frame below describes the kind of operation where QWorks pays off fastest. What decides this is not the name of the industry but the coordination and evidence load the operation carries. The second column matters as much as the first: seeing together when a pilot becomes meaningful makes the decision quicker.
This is a shared frame, not a screening filter. Even if you sit closer to the right-hand column, the conversation is worth having; more often than not the right answer is not “no” but “this step first”.
The real obstacle facing a newer enterprise vendor is not the incumbent solution; it is the risk carried by the person who signs. That risk cannot be hidden, but it can be made manageable: narrow the scope, write the criteria first, and put the exit on the calendar.
The eight headings below are the same in every pilot. Their content varies by organisation; their presence does not. Commercial terms are written separately, once this scope is clear.
Scope is bounded in writing from the start. A “let us set everything up first” approach turns a pilot into a project and delays the decision.
Varies with deployment complexity. Long enough to see the behaviour of a quality operation change, short enough not to exhaust organisational attention.
A pilot without a sponsor produces no commercial decision even when it succeeds technically. Both names are agreed at the start.
Ownership, deadlines, evidence, escalation and management visibility. “How many users logged in” is not a success measure.
Customer names, part numbers and personnel names are not collected unless needed. Where real data is required, its limits are put in writing.
A “we cannot start until every system is integrated” approach delays pilots by months. Integration scope follows the pilot’s question.
Control of data and infrastructure stays with you. The deployment model is scoped to your IT standards.
A pilot does not end with “let us see how it goes”. It closes with a decision meeting whose date is set at the start.
No price appears on this page. The commercial frame is shared in writing once scope and success criteria are clear — with nothing surfacing later: licence, implementation, integration and support stated separately.
“How many people logged in” does not show whether a pilot succeeded. A pilot measures whether the parts of the quality operation that depend on personal follow-up today have become rule-bound. The three axes below are common to most pilots; the exact measures are written in your own process language while scope is agreed.
On open cases, is who does what by when defined in the system — or is it still personal follow-up?
Example measure: every critical action in pilot scope has an assigned owner and a defined deadline.
Can critical steps be closed without evidence and approval?
Example measure: steps with an evidence requirement cannot be closed on a claim, and effectiveness verification runs as a separate step.
Does a delay only generate a reminder, or does it genuinely engage the right management level?
Example measure: cases at risk enter management visibility before the deadline passes, and escalation runs without personal initiative.
The baseline is taken at the start. Before the pilot begins, the current way of working — which step waits where, who chases it, how evidence is collected — is briefly recorded. The outcome is compared against that baseline, not against general industry averages.
The purpose of each contact is not to close a sale but to clarify the next step that matches your risk appetite. You do not have to pass through every rung below; but for a pilot to be meaningful, we need to have seen the current operation together.
Twelve control points, four dimensions. You see for yourself where the current operation still depends on personal follow-up.
We walk step by step through a typical recent complaint together. We do not open a product screen in this conversation.
You pick one closed, anonymised case; we map the current flow and show the controlled operating model for the same scenario.
Not a general product tour — how your own case runs on QWorks, including delay, escalation and evidence control.
Defined scope, defined duration, defined success criteria and a decision meeting scheduled in advance.
When references are few, trust is built by drawing the boundaries clearly rather than by enlarging the claim. The right-hand column below is the part most vendors avoid writing down; for us it is the first sentence of a sales conversation.
The agenda is written before the pilot begins: the baseline, the agreed success criteria, the observed outcome and one of three decisions. We commit to the calendar, not to the result.
Criteria met; extending scope to a second process, a second site or a wider user group is discussed.
Some criteria met; which assumption proved wrong is written down and the scope is redefined.
Criteria not met; the reason is recorded and the pre-agreed handling of environment and data is applied.
We do not leave the first questions of procurement, IT and executives to the meeting.
The commercial frame of a pilot is set together with its scope; we do not work from a standard price list. What is fixed is this: we do not run an open-ended engagement without success criteria, a sponsor and an exit date. Once scope is clear, commercial terms are put in writing too.
No. The purpose of a pilot is to produce a decision, not to close a sale. If the success criteria are not met, that is a valid outcome and we record the reason together. The date of the decision meeting is fixed in advance; its result is not.
QWorks is placed on-premise or in an environment you control; control of the data and the infrastructure stays with you. Only the minimum data required for the pilot to run is used. Customer names, part numbers and personnel names are not collected unless needed; where they are, the data processing limits are put in writing.
The target is the minimum viable setup: environment, identity and access approach, and — only where the pilot’s value hypothesis requires it — a limited integration. Architecture, deployment, backup and support models are clarified with IT before the pilot starts; we do not leave these until after a proposal.
No. QWorks does not replace source systems; it preserves their master data ownership and runs the quality operation that falls between them. The pilot’s question is not “which system stays” but “where does this operation fall back on personal follow-up today”.
No. Visibility is a separate matter and only arises with your written approval. No logo, figure, quote or process detail is published without it.
Building the first screen is perfectly possible. The real question is whether stage/gate control, mandatory evidence, customer-specific SLAs, escalation, effectiveness verification and quality policies that change over the years can be sustained on the same backbone. QWorks provides that as a productised quality operating model, not as a single application.
A limited user group is enough — usually the team actually working on a single process. The aim is not to change the organisation top to bottom but to see the behaviour of one critical flow change measurably.
Priority process, site boundary, sponsor and success criteria settled in a single conversation. We do not have to show product in that meeting; we start by looking at your operation.
