> -----Original Message-----
> From: Mary Jo Sminkey [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 07, 2007 11:21 PM
> To: CF-Community
> Subject: How to get rid of a customer??
>
> be open source like osCommerce and not cost anything. I can't imagine
> how much work it will be to support someone like this *after* they buy
> the product, but how do you get rid of them *tactfully*?
Sounds to me like this is a classic case of not knowing when the "free
consultation" ends. ;^)
I'm assuming but it sounds like you're playing dual roles: Sales for a
"packaged product" and development/professional services for that product.
You need to separate your roles. For free clients just get the "sales
person" role. Your answers should:
+) Be as brief as possible (within reason). Your job here is simple
information, not enlightenment.
+) Refer constantly to the public marketing materials: don't
re-answer questions answered in those materials. This assumes that the
public materials are relatively complete - if they're not then you should
expect lots of questions. ;^)
+) Lack technical detail. Requests for technical detail should be
delayed until the discovery phase of a project. You can reasonably say
"those are details I feel more comfortable discussing after we've formalized
our relationship."
+) Limit yourself in time and scope. When you hit your limit
recommend that a formal engagement begin to better understand the customer's
needs. Answer all queries with that recommendation.
The basic rule of thumb, I think, is (in the sales role) to stop just short
of offering any true value. Once you start providing value to the client
then you should get paid for it. And remember: helping a client define what
they want is very valuable.
In this case I would recommend suggesting a short-term formal engagement.
This would be a requirements definition project (discovery).
The deliverable of the project would be a generic business requirements
document. This document would capture the client's needs, concerns and
technical requirements. It would not offer any specific solutions to those
requirements (define the problem, not the solution). It could be as large
and detailed as a full functional specification or it could be smaller, less
detailed and just represent the basic customer needs.
A second document would address how your product would, specifically, meet
the needs defined in the functional requirements document.
The resulting documentation would form the foundation of a larger project.
It would be useful to the client whether or not you actually completed the
work. Helping somebody articulate their thoughts is an extraordinarily
valuable service.
He might take offense at such a suggestion - in which case: problem solved.
;^) If not then you might be more willing to deal with him once he's
started to pay you.
It's probably our own fault but there's a rampant, deep-seated impression
that developers should give more up for free than other professionals. Try
getting that same amount of work out of a doctor or a lawyer or a
construction contractor and see how far you get without a check in your
hand.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
CF 8 â Scorpio beta now available,
easily build great internet experiences â Try it now on Labs
http://www.adobe.com/cfusion/entitlement/index.cfm?e=labs_adobecf8_beta
Archive:
http://www.houseoffusion.com/groups/CF-Community/message.cfm/messageid:237912
Subscription: http://www.houseoffusion.com/groups/CF-Community/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.5
