Test Incentive Formulas

Before assigning an incentive scheme to a live location, it is important to verify that the formula calculates as intended across a realistic range of technician performance values. A formula that looks correct in isolation can behave unexpectedly at the boundaries — paying out nothing for a strong performer, or producing an inflated result for an edge case that only appears when certain variables are zero or very high.

BayWise includes a Formula Tester built into the scheme editor. It lets you enter values for each variable and see the calculated result in real time, without needing to assign the scheme to a location or wait for a reporting period to close.

Testing a formula is not optional housekeeping — it is the final verification step before a scheme goes live. A formula that pays out an unexpected amount on payroll day is difficult to reverse and harder to explain.

Who can use the Formula Tester: Anyone who can create or edit an incentive scheme (Location Manager, Org Admin, Account Owner).

Access the Formula Tester

The Formula Tester is available from within any incentive scheme — whether you are creating a new scheme or editing an existing one.

Run a test scenario

Recommended test scenarios

Testing against a single “typical” technician is not enough. Run the tester against at least the following three scenarios before assigning any scheme to a live location.

Scenario 1: High performer

A technician working at the top of their capability — high job count, strong efficiency, strong utilization.

Expected result: The formula should produce the maximum or near-maximum incentive output. If the result for this scenario is low, the formula is likely not calibrated for your actual technician performance range.

Scenario 2: Average performer

A technician who meets expectations without exceeding them — representative of the majority of your team on a typical day.

Expected result: A moderate incentive output — meaningfully less than the high-performer result but not zero. If this scenario produces no output at all, check whether your formula’s thresholds are too strict for real-world performance levels.

Scenario 3: Low performer or difficult day

A technician who had a poor period — few jobs, below-target efficiency, and high idle time. Also useful for capturing a day where the technician was pulled off jobs early or dealt with a difficult fault diagnosis.

Expected result: Minimum output or zero. Check that the formula does not produce a negative number for this scenario — a negative incentive is rarely the intended design, and most payroll systems will flag it as an error. If your formula can go negative, add a max(0, formula) wrapper.

Edge case testing

Beyond the three standard scenarios, test the following specific edge cases before assigning any scheme.

Zero jobs completed

Set Jobs Completed to 0 and leave all other variables at their typical mid-range values. If your formula divides by Jobs Completed anywhere, this will produce a division-by-zero result. BayWise treats this as zero output rather than an error, but it is better to guard against it explicitly:

jobs_completed > 0 ? (your formula here) : 0

This makes the zero-job case unambiguous — the technician receives no incentive, not an undefined result.

Perfect efficiency

Set Efficiency % to 100 exactly. Some formulas apply an adjustment based on the difference from 100. At exactly 100%, this adjustment should be zero — neither a bonus nor a penalty. Confirm the formula behaves neutrally at this value.

Very high efficiency

Set Efficiency % to 130 or higher — representing a scenario where a technician completes jobs at 30% faster than estimated. Depending on how your formula is written, very high efficiency values can produce unexpectedly large outputs. If this is not your intent, consider capping the efficiency input in your formula.

Maximum utilisation

Set Utilisation % to 100. Confirm the formula does not produce an inflated result for perfect utilisation if that is not intended.

First period, partial data

A technician who joins partway through a reporting period will have lower Attendance Minutes and Jobs Completed than a full-period technician, even if their per-day performance is excellent. Test the formula with half-period values (e.g., 4 days of data instead of 20) to confirm the output is proportionate and not penalising someone for a partial period they could not control.

Interpreting formula errors

If the tester returns an error rather than a numeric result, check the following:

After testing: next steps

Once the formula behaves as expected across all scenarios, the scheme is ready to assign.

• If the scheme is already saved, go to Settings → Incentives, select the scheme, and click Assign to Locations. See Assign Incentive Schemes.
• If you are still in the creation flow, click Save and then proceed to assignment.

You do not need to keep the tester open or save a test session. The tester is a verification tool only — test results are not stored or attached to the scheme record.

Common questions

Does the Formula Tester use real technician data? No. The tester uses only the values you enter manually. It does not pull live data from any technician’s actual performance record. This keeps testing safe — you can experiment with any values without affecting live reports or calculations.

Can I save a test scenario to run again later? Not currently. The tester does not have a saved-scenario feature. If you regularly verify a scheme against a fixed set of benchmark values, keep a note of your test scenarios in your scheme’s name or description field for reference.

The formula works correctly in the tester but produces unexpected results in the actual report. Why? The most common cause is a difference between the values you tested with and the actual values recorded for the technician in that period. Pull up the technician’s report for the period, note their exact values for each variable, and run the formula manually in the tester with those precise numbers. If the tester then matches the report output, the formula is working correctly — the unexpected result was due to actual performance data being different from your test assumptions.

Can I test a formula before saving the scheme? Yes. The Formula Tester is available within the creation flow before you save. You can test and refine the formula during creation without committing it to the scheme list.

Our formula uses a conditional threshold (e.g., jobs_completed >= 6). How do I verify the threshold boundary? Test at exactly the threshold value, one below it, and one above it. For the example above, test with Jobs Completed set to 5, 6, and 7. Confirm that the formula applies the correct branch at each boundary. Off-by-one errors in thresholds are common and easy to miss if you only test values well above or well below the threshold.

Related pages

• Create an Incentive Scheme
• Assign Incentive Schemes
• Read Technician Reports
• Configure AI Providers