The rule for deciding from a trial: written acceptance conditions before the trial starts — which tasks must pass. Starting a trial with “let’s see what happens” makes the decision feeling-based; written conditions make it evidence-based.

The trial-acceptance conditions sheet

# Condition Verification method Pass criterion
1 Student import our list from Excel 90%+ entered correctly
2 Daily entry attendance+fees run 3 days staff ran it alone
3 Reports print the monthly summary answerable in Q&A
4 Failure support number correction, wrong-entry fix history kept
5 Time average time per workflow step half of the register era or less

Sample terms: “If conditions 1–3 pass in 14 days, approve; if 1–2 fail, reject; whether we keep the trial data is our decision.”

Trial acceptance terms: workflow steps and limitations

  1. Use real data in the trial (2–3 classes) — demo data is only beauty.
  2. Keep date-evidence beside each condition — no room for later disputes.
  3. At trial end, ask your users: comfortable? where did you get stuck? — the real input to the decision.
  4. Limitation: 14 days cannot verify every feature — verify the core cycles (attendance, fees, reports).

Trial terms: questions to ask before your demo

  • Is the trial verifiable — will support accept a condition list?
  • Will trial data come through completely?
  • Can other users get access during the trial?

The trial-based decision yardstick is in the trial-acceptance rules article and the trial guide; price on the pricing page.

Trial terms FAQ

What trial length is good?

14 days — enough to run the core cycles (attendance+fees+reports); shorter is incomplete, longer stalls.

If the trial fails, drop the vendor?

Not immediately — see why a condition failed: lack of support? training? Some are fixable. Failure in real core work is what eliminates.

Should trial data be deleted afterwards?

Keep it if activation happens — otherwise have it deleted, in writing; avoid entering private data in trials.