Return to Answer

Short answer

Don't formalize. Communicate more often.

Long answer

I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

"emergency" fixes needed overnight

If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

nothing for a week

So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

About the formalizing: there are several ways to put everything down in formal documents (time planning, Service Level Agreements, etc), but consider before proceeding:

1. Negotiating and documenting can take a lot of time, compared to the amount of actual work. You'll want to bill your customer to some extent for all this time spent, so effectively, you just become a more expensive supplier. Project size is key. The larger the project, the more sense this approach makes.
2. What do you prefer? To call the customer each other day and change the schedule if and as needed (negotiate) or grind down all the details beforehand in a contract?

To answer your last question: yes, you can put deadlines on the customer in the contract and/or time plan. However, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.

Short answer

Don't formalize. Communicate more often.

Long answer

I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

"emergency" fixes needed overnight

If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

then nothing for a week

So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

Specifically: Is there some standard (contractual) language, which nicely places fixed deadlines on the customer as well?

Yes, you can: there are several ways to put everything down in formal documents (contract, time planning, Service Level Agreements, etc), but consider before proceeding:

1. Negotiating and documenting can take a lot of time, compared to the amount of actual work. You'll want to bill your customer to some extent for all this time spent, so effectively, you just become a more expensive supplier. Project size is key. The larger the project, the more sense this approach makes.
2. What do you prefer? To call the customer each other day and change the schedule if and as needed (negotiate) or grind down all the details beforehand in a contract?

Finally, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.

Short answer

Don't formalize. Communicate more often.

Long answer

I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

1. "emergency" fixes needed overnight: If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

2. nothing for a week: So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

About the formalizing: there are several ways to put everything down in time planning etc, but because people will tend to feel that a) things are now fixed in stone and b) there is no flexibility, this can become a tedious process. Better to call each other every day and change the schedule if needed (negotiate) than getting bogged down in contracting / formalizing.

To answer your last question: yes, you can put deadlines on the customer in the contract and/or time plan. However, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.

Short answer

Don't formalize. Communicate more often.

Long answer

I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

"emergency" fixes needed overnight

If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

nothing for a week

So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

About the formalizing: there are several ways to put everything down in formal documents (time planning, Service Level Agreements, etc), but consider before proceeding:

1. Negotiating and documenting can take a lot of time, compared to the amount of actual work. You'll want to bill your customer to some extent for all this time spent, so effectively, you just become a more expensive supplier. Project size is key. The larger the project, the more sense this approach makes.
2. What do you prefer? To call the customer each other day and change the schedule if and as needed (negotiate) or grind down all the details beforehand in a contract?

To answer your last question: yes, you can put deadlines on the customer in the contract and/or time plan. However, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.

Short answer: don't formalize. Communicate more often.

Long answer: I think this situation calls for better expectation management (communication). Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

1. "emergency" fixes needed overnight: If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

2. nothing for a week: So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

About the formalizing: here be dragons. There are several ways to put everything down in time planning etc, but because people feel things are now fixed in stone and there is no flexibility, this can become a tedious proces. Better to call each other every day and change the schedule if needed (negotiate) then getting bogged down in contracting / formalizing.

To answer your last question: yes, you can put deadlines on the customer in the contract and/or time plan. However, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.

Short answer

Don't formalize. Communicate more often.

Long answer

I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.

1. "emergency" fixes needed overnight: If you mean that the moment the customer finds bugs, they need to be fixed "right now": is it fair for a customer to expect this? I think not. Bugs take time to fix and the team should get that time. Tell them beforehand, that they can expect their fixes "X" days after they report them. If they object, negotiate. In any case, make it explicit when they can expect their fixes.

2. nothing for a week: So what's going on here? Are they not using the product or just not talking about it? Radio silence? Let me know and i'll update my reply.

About the formalizing: there are several ways to put everything down in time planning etc, but because people will tend to feel that a) things are now fixed in stone and b) there is no flexibility, this can become a tedious process. Better to call each other every day and change the schedule if needed (negotiate) than getting bogged down in contracting / formalizing.

To answer your last question: yes, you can put deadlines on the customer in the contract and/or time plan. However, instead of naming fixed dates, I would recommend to name your deliverables (update, patch, new release, etc) and indicate how much time is needed after the customer delivers their input/test results/etc. That way, when the customer is late with their results, they cannot expect you to deliver overnight.

Hope this is usefull. If anything incorrect / missing, let me know and i'll update my post.