Summary

The Contract Definitions page is used to create and edit contracts.

You can work with multiple contracts, each with its own users and its own configuration.


Contract Structure

Name

Each contract has a Name. You can enter any name you see fit. This Name will be used to reference the contract on other screens.

Dates & Period Type

Each contract has a Start Date, an End Date, a Time Zone, and a Period Type.

The Start Date, End Date, and Time Zone selections define the beginning and end of your contract term.

The duration between your Start Date and End Date will be divided into periods, according to your Period Type selection.

The "Periods" of your contract can be calculated in several ways.

  • "Fixed" means the time between the start & end dates of your contract will be processed as a single period.
  • "Monthly (Calendar Month)" means each calendar month between your start & end dates will be processed as a separate period and new periods start on the first of each month.
  • "Monthly (Exact Day)" means each month between your start & end dates will be processed as a separate period and new periods start the same day of each month according to your contract start date.
  • "Annual (Calendar Year)" means each calendar year between your start & end dates will be processed as a separate period and new periods start on the first of January each year.
  • "Annual (Exact Day)" means each year between your start & end dates will be processed as a separate period and new periods start the same day of each year according to your contract start date.


To illustrate all the differences, let's say we have a contract with irregular dates. Let's say you define a contract that starts on Jan 15th, 2023 and ends on Jan 14th, 2025. A two-year contract that starts and ends in the middle of a month.

If the Period Type is:

  • "Fixed", then the contract will have a single period from Jan 15th, 2023 to Jan 14th, 2025.
  • "Monthly (Calendar Month)", then the contract will have 25 periods. The first period will be Jan 15th, 2023 - Jan 31st, 2023. The second period will be Feb 1st, 2023 - Feb 28th, 2023. The following 22 will match all calendar months until Dec 2024. And the last period will be Jan 1st, 2025 - Jan 14th, 2025.
  • "Monthly (Exact Day)", then the contract will have 24 periods. The first period will be Jan 15th, 2023 - Feb 14th, 2023. The second period will be Feb 15th, 2023 - March 14th, 2023. The following 21 will be 30 or 31 day periods, all starting on the 15th of each month. And the last period will be Dec 15th, 2024 - Jan 14th, 2025.
  • "Annual (Calendar Year)", then the contract will have 3 periods. The first period will be Jan 15th, 2023 - Dec 31st, 2023. The second period will be Jan 1st, 2024 - Dec 31st, 2024. And the last period will be Jan 1st, 2025 - Jan 14th, 2025.
  • "Annual (Exact Day)", then the contract will have 2 periods. The first period will be Jan 15th, 2023 - Jan 14th, 2024. The second period will be Jan 15th, 2024 - Jan 14th, 2025.


Contract reports are calculated solely using Jira issues and SLAs on those issues. Since Jira already stores them, you can create contracts and get reports for your past issues as well.


Clauses

Each contract has one or more "Clauses".  A clause defines a limit or a goal for a group of issues. 

Name

Each Clause has a name. The clause will be listed with this name in Contract Reports.

JQL

Each Clause has a JQL. This JQL determines the scope of issues that will be included in this clause.

This JQL can be thought of repeating for each contract period. The issues created in each period of that contract will be matched with this JQL to determine whether that issue is in the scope of the clause or not.

The user is expected to enter a valid JQL here. Any JQL valid for Jira can be used. The Clause dialog even allows invalid JQL queries to be saved, so any lacking user permissions do not block the creation of the contract.

Clause Type

There are 3 types of clauses:

  • "Number of Issues": This clause type sets a limit for the number of issues that can be created in each period.
    • If there are fewer issues created in a period matching the JQL of this clause, then this clause will succeed for that period. If there are more issues created in a period matching the JQL of this clause, then this clause will fail for that period. 
  • "Total Service Hours": This clause type sets a limit for the total number of service hours that can be used in a period.
    • The service hours are taken directly from the work logged onto Jira issues created in each period.
    • If there are fewer hours logged onto issues created in a period matching the JQL of this clause, then this clause will succeed for that period. If there are more work hours logged onto issues created in a period matching the JQL of this clause, then this clause will fail for that period. 
  • "SLA Success Rate": This clause type sets a goal success rate for the selected SLA timers.
    • TicketBook does NOT run its own SLA timers. The SLA timers selected here are Jira Service Management's SLAs.
    • The SLA Success Rate is "the "number of issues with successful SLA timers" divided by "the total number of issues" created in a period matching the JQL of this clause.
    • If more than one SLA timer is selected for this clause, then all selected SLA timers must be successful for an issue to succeed. If at least one SLA timer is breached for that issue, then that issue is a failure.
    • By default, the expected Success Rate is 100% but you can reduce this target.
    • If the SLA Success Rate in a period is equal to or higher than the target, then this clause will succeed for that period. If the SLA Success Rate in a period is lower than the target, then this clause will fail for that period. 

You can define multiple clauses of the same type with different JQLs.


For example, if your agreement stipulates that...

  • The customer can create 10 issues in project ABC every period, then you should create a "Number of Tickets" clause and configure it with a JQL like "project = ABC" and set the limit to "10"
  • The customer can create 10 low-priority issues and 3 high-priority issues in project ABC every period, then you should create two "Number of Tickets" clauses.
    • You should configure one of them with a JQL like "project = ABC and priority >= High" and set the limit to "3".
    • You should configure the other one with a JQL like "project = ABC and priority < High" and set the limit to "10".
  • The customer can use up to 50 hours of service, then you should create a "Total Service Hours" clause and configure it with a JQL like "project = ABC" and set the limit to "50".
  • The service provider is allowed to fail on less than 0.5% of the SLA timers each period, then you should create an "SLA Success Rate" clause and configure it with a JQL like "project = ABC" and set the target to 99.5%

Limited / Unlimited

By default, the clauses are Limited and you are expected to set a limit/goal for that clause. The Contract Report will calculate whether each period is below or over that limit. Periods over the limit will be displayed as Fail and periods equal or below the limit will be displayed as Success.

The "Number of Issues" and "Total Service Hours" clauses can also be configured as Unlimited. In that case, the Contract Report will just calculate the total number of issues created or the total service hours logged and the periods will always be displayed as a success.

Amends

Amends allow you to define additional quotas or additional consumption for a period.

In some periods, a customer business might be going through busy times and the customer might want to purchase additional quota only for that specific period. Similarly, the customer might make some requests from you as part of your contract agreement but those requests might not be recorded as Jira issues on your Jira instance. In those cases, you can define these additional quotas or additional consumptions as "Amends".

  • An Amend is either a Limit or a Consumption.
  • It belongs to a specific period.
  • The Amend has a numeric value that is added to the limit or added to the consumption of that period.
  • The Amend also has a free text Notes field. The notes entered here will be displayed in the Contract Report.
  • Amends are valid for the "Number of Tickets" or "Total Service Hours" clause types. Amends do not make sense for "SLA Success Rate" clauses so they can't be defined for "SLA Success Rate" clauses.



Permissions

To provide more granular control over the access to individual contracts, TicketBook allows the configuration of Contract Permissions.

Using the Permissions tab, you can define...

  • Who can View the contract (and get contract reports based on it)
  • Who can Edit the contract, its details, amends, and permissions.
  • Who the Owner of that contract is. The Owner is a single user and always has View and Edit permissions on the contract.








  • No labels

© 2012-2015 Copyright OBSS