Good morning, Please see additional feedback below based on your questions.

Could you please provide some feedback on how this customer plans to use the volume restrictions? Are these limits for courier volume across the whole year, quarter, or month?

-> This would be a daily limit that would need to be set by carrier. For Example, FedEx might have a different daily limit than Canada Post.

When are we supposed to reset the limit again? I assume at the end of the set period

-> The limit should reset at midnight every day.

Looks like we would need to disable the account and enable it back at certain times. Is the expectation to default to a specific other account/carrier, or is the expectation that this will only apply to the cases where the customer is rateshopping and we will just roll to the next available carrier?

-> The expectation is that the courier billing account should not allow any shipments at all once the limit is reached. This is regardless if rate shopping or if we are passing down the SCAC and Service Level. In case of Rate shopping, Techship should ignore this carrier once the limit is reached and look at other available carriers.

Finally, does the API of these carriers not provide us with a notice that a limit has been reached? I would have expected a carrier like FedEx to include an additional fee for exceeding the agreed-upon volume in the API. However, in this case, perhaps rate shopping across several airlines will suffice.

-> The client informed us that the carrier API does not provide a notice or error once the limit is reached. They have logic on their parcel shipping system to failover to the next available carrier once the daily limit is reached. In our case, rate shopping should ignore this carrier and look at the other available carriers. If we pass down the specific SCAC and service level, Techship should throw an error to specify that the limit is exceeded.

Thank you, can you please provide next steps and approximate timeline of when this feature can be implemented?

Thanks,

Mark

Good morning, Please see additional feedback below based on your questions.

Could you please provide some feedback on how this customer plans to use the volume restrictions? Are these limits for courier volume across the whole year, quarter, or month?

-> This would be a daily limit that would need to be set by carrier. For Example, FedEx might have a different daily limit than Canada Post.

When are we supposed to reset the limit again? I assume at the end of the set period

-> The limit should reset at midnight every day.

Looks like we would need to disable the account and enable it back at certain times. Is the expectation to default to a specific other account/carrier, or is the expectation that this will only apply to the cases where the customer is rateshopping and we will just roll to the next available carrier?

-> The expectation is that the courier billing account should not allow any shipments at all once the limit is reached. This is regardless if rate shopping or if we are passing down the SCAC and Service Level. In case of Rate shopping, Techship should ignore this carrier once the limit is reached and look at other available carriers.

Finally, does the API of these carriers not provide us with a notice that a limit has been reached? I would have expected a carrier like FedEx to include an additional fee for exceeding the agreed-upon volume in the API. However, in this case, perhaps rate shopping across several airlines will suffice.

-> The client informed us that the carrier API does not provide a notice or error once the limit is reached. They have logic on their parcel shipping system to failover to the next available carrier once the daily limit is reached. In our case, rate shopping should ignore this carrier and look at the other available carriers. If we pass down the specific SCAC and service level, Techship should throw an error to specify that the limit is exceeded.

Thank you, can you please provide next steps and approximate timeline of when this feature can be implemented?

Thanks,

Mark