Skip to main content

Early adopters programme

Early adopters are critical to the rollout of a new version of our software.

Customer segmentation for releases​

Jadu segments their customers into groups when rolling out a new software version. This allows us to match an organisation’s tolerance of risk and desire for updated software versions, with their position in our rollout queue.

We currently segment customers into 3 groups:

  1. Early adopters (approx 5% of customers)
  2. Fast followers (approx 20% of customers)
  3. General population (approx 75% of customers)

What is an early adopter?​

Early adopters are the first customers to be patched with a new version of our product. They could alternatively be referred to as “lighthouse customers” as they serve as a beacon of light for both Jadu and the rest of our customer base.

In what is a mutually beneficial relationship with Jadu, early adopters provide feedback on a release, positive and negative, that we can then use to direct how our product changes in the future.

Benefits of being an early adopter​

  1. Priority access to new features and improvements in the software.
  2. Closer relationship with Jadu, with the potential to have greater influence over future releases.
  3. Opportunities to participate in case studies, press releases and other promotional materials.

Considerations of being an early adopter​

  1. Greater risk of encountering a defect that has escaped our development process.
  2. Being at the cutting edge, documentation and other resources may still be in development at the point that releases are rolled out.

Support of early adopters​

Jadu recognises that being an early adopter of our upcoming releases may mean that a customer will experience more issues than a customer in the final phase of our rollout.

To mitigate this, we aim to offer an expedited turnaround of fixes using hotfixes for agreed critical issues introduced by the latest release of the software where there is no workaround available. These issues would be defined as P1 and P2 issues in our SLA.

Our hotfixes are proposed and tested by our development teams, consistently with our normal development process. However, when applying a hotfix, we bypass a full release process to get the fix in place as quickly as possible in our customer’s environment.