forum home | register | profile | members |search | faq
homepage | lost password? | chat room
|
|
QSA ToolWorks Public Feedback Forum forum home | register | profile | members |search | faq homepage | lost password? | chat room |
| QSA ToolWorks Public Feedback Forum > Fee-Based Technical Support > Solution Developer Plan | You are not logged in. Login or Register. |
| Pages: 1 |
|
| Author: | Topic: Solution Developer Plan | |||
Matt Posts: 106 Registered: 2003-02-16  mstrange@mac.com  |
 Posted: Mar 31, 2003 6:24:34 pm    
Solution Developer The Solution Developer plan is for developers who use Helix to create solutions for their customers. These developers typically require very little help from technical support. Solution Developers have many clients; therefore they encounter a variety of situations. Their primary need is for rapid resolution when issues arise. A developer who is facing a deadline (or on site) and dealing with an issue in Helix needs to be able to talk to a technical support representative who can offer a solution that will enable the developer to finish the task. Solution Developers also create prepackaged, off the shelf applications with Helix. Solution Developers expect to gain new clients as their business grows. If they are pleased with Helix Technologies, there is a higher likelihood that they will propose Helix based solutions. Solutions Developers are our front line sales staff and should be treated as such - both in privilege and expectation. Developers creating Helix based solutions results in new Helix installations, synonymous with Helix's goal of having a larger user base. This group also expects active participation on the part of Helix Technologies to promote its offerings. Active promotion on the part of Helix Technologies should result in increased Helix work for Solution Developers. Without active assistance, the developer is more likely to search out another solution to their client needs, and Helix Technologies loses another user. Members of this group understand that it is not Helix Technologies' responsibility to find work for them, however Helix must understand that it is important to make every opportunity available to the developer for the relationship to grow. This group also looks to Helix for ways to reduce their own development/support costs. It benefits both Helix Technologies and the Solution Developer for us to provide assistance wherever possible. End user manual templates, cooperative marketing, logo usage, are tangible benefits we can offer. This is an annual plan. It does not include unlimited technical support units, but it does include other benefits that this group needs. Solutions Developers will be eligible for discounts on Helix purchases, both for themself and for resale. They will receive invitations to participate in private forums designed to specifically address the unique needs of the Solution Developers. Benefits of the "Developers Toolkit" are included in the plan. Annual renewal within this group should be high, and failure on the part of a solution developer to renew should be aggressively followed up on by Helix Technologies. If a developer drops out of this program, Helix Technologies assumes a responsibility to support the former developer's Helix clients. Developers entering this program must be made aware that we will take necessary steps to ensure that their Helix customers are properly supported. If that means referring the client to an active Helix solutions developer, even at the risk of alienating the developer, then so be it. (Historically, technical support has dealt with a moderate percentage of Helix sites that have been 'orphaned' by former developers. These sites fail to purchase Helix product upgrades and allow perceived Helix shortcomings to fester in their minds to the point that when they do contact Helix Technologies, they are either in a panic situation or are seeking help in moving data from Helix to another database solution. It is in the best interest of Helix Technologies to minimize this occurrence.) Issues It needs to be determined whether a customer acquired through a developer is in fact a customer of Helix, or of the Solutions Developer. It is our opinion that under most circumstances the end user is not a Helix Technologies customer and support is the responsibility of the Solutions Developer. Technical support should always refer these customers back to their Solutions Developer. This can create difficult logistical situations, but if we continue to treat the Solutions Developer as a partner - and therefore expect a level of responsibility from them - other issues (applying discounts, for one) become much less difficult.
|
|||
keVin Posts: 30 Registered: 2003-04-09 |
 Posted: Apr 10, 2003 8:13:20 pm
It is evident considerable time has been expended formulating these plans. My head was nodding vertically until getting to the phrase "If a developer drops out of this program, Helix Technologies assumes a responsibility to support the former developer's Helix clients." It is further indicated, "This can create difficult logistical situations." To this I add legal issues.  There is no doubt that Helix Developers love the product. As long as partnering continues the relationship should flourish. However, let's say for example that a Solution Developer faced with growing his business must branch out to another application development environment. Perhaps marketing indicates that his customers require features not evident within Helix for the foreseeable future. The cost/value of remaining a Helix Solution Developer may be challenged. The developer might make a business decision to move the clientele he has acquired to a competing product. This likely involves rewriting his solution in another programming language. It appears unethical in this situation for Helix Technologies to then, "take necessary steps to ensure that their Helix customers are properly supported. If that means referring the client to an active Helix solutions developer, even at the risk of alienating the developer, then so be it." A Solution Developer's customer base may dwindle considerably as a result of too distant though foreseeable Helix features. A customer with many client seats may refuse to upgrade until a particular feature is added -- asking the developer for a reasonable time frame. Since low-level feature inclusion is beyond the control of the developer, the deadline may slip and the customer may be lost to a solution developer supporting a competing database with the desired feature. Perhaps an office replaces its Macs with PC's or their database grows beyond the 2GB limit. It could be a performance issue. I've seen good Helix solutions die on the vine for the lack of Abacus-controlled file naming. In such situations a mutual loss is felt. It seems more appropriate for Helix Technologies to ask the "partner" about a decrease in developer revenue. Very likely the developer has already been very vocal about the needs of the clients he supports. In this situation, jumping in to supplant discussions already held by the developer would seem pointless. If the developer dies, retires, or gets in "over his head" -- making promises he lacks the proficiency to fulfill, Helix Technologies may have an ethical position to fill the void. In some respects the relationship is like a franchise. Theoretically, the corporate name is used to bring in more business. Suppose Robert operated Bob's Auto Parts store. He has loyal customers because they get to talk to Bob and he knows a lot about cars. He hears the commercials and consider the buying power of larger competitors. Feeling such a venture would benefit his customers, Bob decides to purchase a franchise license. With it comes a larger location, new marquee, franchise-branded products, and franchise fees. Now suppose Bob finds out that these products are inferior to the ones he used to sell. New customers are constantly returning purchases. Bob loses control over the type of products he can stock -- forcing him to sell outdated technology. Loyal customers of Bob's Auto Parts are complaining and threatening to take their business elsewhere. At this point Bob faces tough decisions: sell his franchise back to the corporation, file for bankruptcy, and/or reopen Bob's Auto Parts. The Helix brand now closes more doors than it opens. That is not a criticism but a well-known fact. Hopefully it will change but for now the developer either must de-emphasize the Helix moniker or do some pretty impressive convincing to market his products. Rather than mandating tertiary control over a developer's customers in such a tenuous situation, Helix Technologies should work hard to engender trust by focusing on the things within the vertical nodding area of the plan. Show developers a responsiveness to feature requests. Provide realistic time lines for feature implementation. Lay off the heavy-handy, customer-grabbing clauses. Don't add more risk to that inherently undertaken by the developer. |
|||
pampine Posts: 8 Registered: 2003-04-09 |
Posted: Apr 11, 2003 5:07:13 pm
Not only is this legally questionable, it's a waste of time until Helix is a viable product. Celebrate your first 1000 product sales by thinking about even having any solution developers, much less charging them for anything. Pam
|
| Pages: 1 |
|
| Lost Password? Powered by UPB Version : 1.8 A script by PHP Outburst |
