November 5, 2014 at 12:25Problems in the implementation and sale of electronic document management systems
Our organization develops and sells an electronic document management system and platform in Ukraine. In the article I want to share my experience in communicating with customers, from acquaintance to discussing “improvements” and possible problems with closing system sales contracts. The "rake" we are stepping on will be described.
It is rare that a workflow system is easy to learn. But the one who needs it, of course, understands, studies, often with our help. Everything is used - ICQ, Skype, forum, telephone conversations.
We have a free version for 5 users on our site, you can study it unlimitedly. There is also a trial license for half a year for 50 (or more) users. The customer studies, immediately builds his business processes, designs document types, makes users and departments. All this time he lives quietly and enjoys, without concluding a contract and without costs on his part. Do not like it - quit and leave. Upon agreement with us, he can extend the trial license for as long as we like until we recognize him as a “cheater”.
Finally, our customer decided "Yes, we will take and implement your system!". That sounds great, but so far this is just the beginning. We determine the number of modules, how many client places are needed - the cost is calculated easily, the site has a calculator. What follows next? Come on, sign the contract, get a license and use it!
But no - it turns out that the customer still needs something. Namely - customization, refinement for yourself, as well as this “little list” of wishes and innovations, without which it seems to him simply impossible to continue further. In this list, usually no one poses the problem of implementation, it is somewhere far away, but in the list, in fact, software development.
If your customers can write technical assignments, you are incredibly lucky. Even more fortunate if you are paid for the time spent on the preparation of the ToR. But, the classic customer is not the director of the company, but rather its technical experts plus their leadership. For example, one or two employees of the IT department and their head. People are techies, but they do not always know how to write and explain.
As a result, you can get from them only a “general description” of what they want, but asking them questions and clarifying details is your concern. The person says: “I want your system to be integrated with 1C!”. For him, this seems to be obvious and there is nothing to discuss, but you, as a developer, know that this is only the tip of the iceberg. Points in TK are added as you wish. There is no limit to perfection and you need to say in time, “Wait, let's still, we will sign the statement of work.” The signed TK gives you a fixation of requirements and at least somehow protects from immense development.
Most likely, you will encounter the problem of “detailing TK”: to write in more detail or vice versa, to limit yourself only to general formulations. If you start writing details, there will not be enough time and energy. Do not write - admit a free interpretation. But you can accept the rule: "everything that is not described in the ToR does not need to be understood and should not be." There is only one problem with this - for your customer, this rule should be obvious and understandable. It is worth trying to convince him of this, but the law has not been written for him, he will be offended and demand.
Technical issues are interesting, but we forgot the main thing for which we are working. And we work for the money. A signed and paid contract brings money to the company, and you, as a developer (or implementer), may receive a bonus. And here the most unpleasant site begins.
From the moment the customer began to study your system and the time when he "reached" the signing of the contract, it may take a lot of time. For example, six months. But here's the thing: techies have already announced the approximate purchase amount. For this, “money was allocated to the budget” and it seems that one thing is clear: the thing that was in the cost calculator on the site reflects the cost of the product’s license, but, alas, does not include the cost of all those “improvements” that are from you the customer wants to receive. You are very lucky if the customer is ready to add money and take into account the cost of improvements. In the worst case, the cost of the product allows you to close your eyes to the fact that they won’t pay separately for the work.
The correct way out when selling complex software systems is to separate flies and cutlets. Here is the license, here you have paid for the "finished system", the price that is listed on the site. This is one contract. And here is the second contract, which is called the “Agreement for the implementation and revision”. It describes all the wishes, all the technical points and it is evaluated and paid separately.
Why is it important? Because you will receive money only after closing the contract with an act. So, it will be very easy for you to transfer the license for the product “out of the box”, and you have already earned money.
Fulfillment of the technical task is a difficult thing, there is your own schedule, but you have already sold the product and received the first part of the income. Having fulfilled the ToR and having closed the second contract, you will receive your money for “improvements”.
And there is a wrong way out too, and it is “loved” by all customers: they will cram the cost of selling the license and add a certain amount for “improvements”, but they will issue it as one contract. So it’s easier for them - because their leadership will “break” if it signs two pieces of paper, and not one. And most importantly - now you are in their power. Until you fulfill all the wishes, all the technical “goodies” and everything that has been spelled out as “improvements”, you will not get anything. The contract may even “freeze” - a difficult situation in the organization of the customer, the crisis, there was money - but they are already gone. Sorry, but alas. You will not sue him anyway.
We have the wrong approach in our organization. We stepped on this rake many times and whether it will be possible to “break” it is still unknown. Please tell us in the comments about your experience how you sell “box systems” and how you make improvements and suggestions. It would be very interesting to know if your customers are willing to pay for “improvements” amounts comparable or greater than just the cost of the product “out of the box”.
Acquaintance of the customer with the system
It is rare that a workflow system is easy to learn. But the one who needs it, of course, understands, studies, often with our help. Everything is used - ICQ, Skype, forum, telephone conversations.
We have a free version for 5 users on our site, you can study it unlimitedly. There is also a trial license for half a year for 50 (or more) users. The customer studies, immediately builds his business processes, designs document types, makes users and departments. All this time he lives quietly and enjoys, without concluding a contract and without costs on his part. Do not like it - quit and leave. Upon agreement with us, he can extend the trial license for as long as we like until we recognize him as a “cheater”.
We will take your system, but ...
Finally, our customer decided "Yes, we will take and implement your system!". That sounds great, but so far this is just the beginning. We determine the number of modules, how many client places are needed - the cost is calculated easily, the site has a calculator. What follows next? Come on, sign the contract, get a license and use it!
But no - it turns out that the customer still needs something. Namely - customization, refinement for yourself, as well as this “little list” of wishes and innovations, without which it seems to him simply impossible to continue further. In this list, usually no one poses the problem of implementation, it is somewhere far away, but in the list, in fact, software development.
Development of technical specifications
If your customers can write technical assignments, you are incredibly lucky. Even more fortunate if you are paid for the time spent on the preparation of the ToR. But, the classic customer is not the director of the company, but rather its technical experts plus their leadership. For example, one or two employees of the IT department and their head. People are techies, but they do not always know how to write and explain.
As a result, you can get from them only a “general description” of what they want, but asking them questions and clarifying details is your concern. The person says: “I want your system to be integrated with 1C!”. For him, this seems to be obvious and there is nothing to discuss, but you, as a developer, know that this is only the tip of the iceberg. Points in TK are added as you wish. There is no limit to perfection and you need to say in time, “Wait, let's still, we will sign the statement of work.” The signed TK gives you a fixation of requirements and at least somehow protects from immense development.
Most likely, you will encounter the problem of “detailing TK”: to write in more detail or vice versa, to limit yourself only to general formulations. If you start writing details, there will not be enough time and energy. Do not write - admit a free interpretation. But you can accept the rule: "everything that is not described in the ToR does not need to be understood and should not be." There is only one problem with this - for your customer, this rule should be obvious and understandable. It is worth trying to convince him of this, but the law has not been written for him, he will be offended and demand.
A contract that is good for the customer
Technical issues are interesting, but we forgot the main thing for which we are working. And we work for the money. A signed and paid contract brings money to the company, and you, as a developer (or implementer), may receive a bonus. And here the most unpleasant site begins.
From the moment the customer began to study your system and the time when he "reached" the signing of the contract, it may take a lot of time. For example, six months. But here's the thing: techies have already announced the approximate purchase amount. For this, “money was allocated to the budget” and it seems that one thing is clear: the thing that was in the cost calculator on the site reflects the cost of the product’s license, but, alas, does not include the cost of all those “improvements” that are from you the customer wants to receive. You are very lucky if the customer is ready to add money and take into account the cost of improvements. In the worst case, the cost of the product allows you to close your eyes to the fact that they won’t pay separately for the work.
The right approach
The correct way out when selling complex software systems is to separate flies and cutlets. Here is the license, here you have paid for the "finished system", the price that is listed on the site. This is one contract. And here is the second contract, which is called the “Agreement for the implementation and revision”. It describes all the wishes, all the technical points and it is evaluated and paid separately.
Why is it important? Because you will receive money only after closing the contract with an act. So, it will be very easy for you to transfer the license for the product “out of the box”, and you have already earned money.
Fulfillment of the technical task is a difficult thing, there is your own schedule, but you have already sold the product and received the first part of the income. Having fulfilled the ToR and having closed the second contract, you will receive your money for “improvements”.
Wrong approach
And there is a wrong way out too, and it is “loved” by all customers: they will cram the cost of selling the license and add a certain amount for “improvements”, but they will issue it as one contract. So it’s easier for them - because their leadership will “break” if it signs two pieces of paper, and not one. And most importantly - now you are in their power. Until you fulfill all the wishes, all the technical “goodies” and everything that has been spelled out as “improvements”, you will not get anything. The contract may even “freeze” - a difficult situation in the organization of the customer, the crisis, there was money - but they are already gone. Sorry, but alas. You will not sue him anyway.
Total
We have the wrong approach in our organization. We stepped on this rake many times and whether it will be possible to “break” it is still unknown. Please tell us in the comments about your experience how you sell “box systems” and how you make improvements and suggestions. It would be very interesting to know if your customers are willing to pay for “improvements” amounts comparable or greater than just the cost of the product “out of the box”.