Maker Pro
Maker Pro

Handling a "bad" customer

J

Jim Thompson

Jan 1, 1970
0
Well, they can't spare any. They need it to sop up all the beer they
spill, and to catch the batshit.

John

Guano... isn't that what Texans put on their tacos ?:)

...Jim Thompson
 
J

John Smith

Jan 1, 1970
0
People who work in retail for low pay need to be insulted--heck, they
should be flogged in public--that is one of the worst jobs I can imagine
and you are a fool to do it if you aren't paid DAMN WELL for it...
People can't help but notice you are a fool for doing it--and treat you
as you deserve--since when you have taken enough of this abuse, you
ABUSE THE CLIENTS/CUSTOMERS back--it can all be overlooked, just a job
related hazard... <grin>

John
 
G

Guy Macon

Jan 1, 1970
0
John said:
People who work in retail for low pay need to be insulted--heck, they
should be flogged in public--that is one of the worst jobs I can imagine
and you are a fool to do it if you aren't paid DAMN WELL for it...
People can't help but notice you are a fool for doing it--and treat you
as you deserve--since when you have taken enough of this abuse, you
ABUSE THE CLIENTS/CUSTOMERS back--it can all be overlooked, just a job
related hazard... <grin>

Very insightful. I think you hit the nail on the head. It's a
classic positive feedback loop.

(BTW, I saw your other tries, but couldn't approve them and still
keep my promise to keep the topic at least somewhat related to
product development. I hope that this doesn't keep you from posting
things that *are* at least somewhat related to product development;
That was a really good observation about retail.)
 
W

Winfield Hill

Jan 1, 1970
0
Guy Macon wrote...
Excuse me, what a bunch of disrespectful P.O.S. towards those poor
folks who have to take what they can get by way of employment.
Very insightful. I think you hit the nail on the head. It's a
classic positive feedback loop.

(BTW, I saw your other tries, but couldn't approve them and still
keep my promise to keep the topic at least somewhat related to
product development. I hope that this doesn't keep you from posting
things that *are* at least somewhat related to product development;
That was a really good observation about retail.)

Hold it, Guy, are you saying this is a misc.business.product-dev post?
The headers don't show it as anything other than a bog-standard s.e.d.
post, which doesn't need, nor tolerate, your personal "approval." Can
you tell us what's going on here with this cross-contamination stuff?
 
J

John Smith

Jan 1, 1970
0
Winfield:

I am more than qualified into making such statements--although 52 now, I
once was 17 with a job in retail--more than one retail job as a matter
of fact--I stand behind all I have said--although it ain't pretty--it is
TRUE!

Warmest regards,
John
 
K

Kelly Hall

Jan 1, 1970
0
Robert said:
In short, ignorance and dummies are not allowed (or quiet either).

That's a great idea, but you will leave an awful lot of money on the
table if you decide that you'll only sell to smart people.

Speaking as a propeller-headed engineer, I'm very impressed by companies
who have products and marketing that allow the folks on the other half
of the median intelligence line to see the need for, buy, and be happy
with a product.

Kelly
 
K

Kelly Hall

Jan 1, 1970
0
Joel said:
The whiny customer does ask for many things that aren't reasonable in an
inexpensive product (full power-on self tests), although it's also true that
in many cases a lot of self-diagnostics can be added without changing the BOM
price at all by just adding more software. Of course I have no idea if that's
the case for the particular product in question here.

Unless I've been mislead for the last couple of decades, software is one
of the most expensive items on the BOM. To quote viciously from Jack
Ganssle's column:
http://www.embedded.com/showArticle.jhtml?articleID=161600589

==
Firmware is the most expensive thing in the universe. In his book
Augustine's Laws, Lockheed Martin's Chairman Norman Augustine relates a
tale of trouble for manufacturers of fighter aircraft.6 By the late '70s
it was no longer possible to add things to these planes because adding
new functionality meant increasing the aircraft's weight, which would
impair performance. However, the aircraft vendors needed to add
something to boost their profits. They searched for something, anything,
that weighed nothing but cost a lot. And they found it—firmware! It was
the answer to their dreams.

The F-4 was the hot fighter of the '60s. In 2004 dollars these airplanes
cost about $20 million each and had essentially no firmware. Today's
F-22, just coming into production, runs a cool $257 million per copy.
Half of that price tag is firmware.

The DoD contractors succeeded beyond their wildest dreams.
==

That said, I think POST code ought to be nearly free because the
software folks should have written that code early on if only to verify
that the first runs of the hardware performed adequately. Better to
ship that stuff, hidden from the user, unless you absolutely have no
room in the ROMs for it.

Kelly
 
M

Mac

Jan 1, 1970
0
(Note for those who dislike moderated newsgroups; you may wish
to check your Subject header and edit it to your liking.)
^^^^^^^

ITYM "Newsgroups."

--Mac
 
G

Guy Macon

Jan 1, 1970
0
Kelly said:
That said, I think POST code ought to be nearly free because
the software folks should have written that code early on if
only to verify >that the first runs of the hardware performed
adequately. Better to ship that stuff, hidden from the user,
unless you absolutely have no room in the ROMs for it.

Just for completeness, I can think of other situations where POST
(Power On Self Test) code should be omitted.

[1] When the I/O is so limited that you simply don't have a way of
conveying the result of the POST. One embedded system I worked on
had as it's only output a doll moving her hand in a somewhat random
manner. It didn't make a lot of sense to write a POST that waved
one way if it passed and another when it failed and then expecting
the average toy buyer to understand that.

[2] When there is nothing that the customer can do if it fails.
Another embedded system I worked on was a toy that had one button
as the only input, and a voice as the only output. The button
simply applied power to the electronics, which then turned on a
transistor to supply power after the button was released, said
the phrase, then turned itself off. That was a case where neither
a POST or a watchdog made any sense The watchdog resets the CPU
and that is being done anyway, and the POST checks the hardware,
but hearing the phrase does that. Other examples where where
there is nothing that the customer can do if it fails come to mind,
such as the electronics that makes a bomb go off when it reaches
the target.

[3] When you need very rapid recovery from a power-on reset. This
is a surprisingly common situation in small embedded systems that
sit powered off, are turned on by another part of the system to do
some work and then turned off when they are done. not having a
POST can easily double the battery life if the run time is short.

Note that in the above cases it may still be appropriate to have
a self test, but started with some special key combination or
triggered by holding an unused pin high during power-up.

I do agree that in most cases there should be a POST, and that it
should be the first thing the software folks write. Doing it that
way allows them to understand any quirks in the hardware, and also
makes it less likely that a hardware change with undesirable side
effects gets through to production.

It's also a great way to resolve finger-pointing between hardware
and software engineers. Whenever a "that's a hardware problem!
No it's software problem!" dispute happens, I ask the software
engineer to add a test to the POST that makes it fail when the
hardware failure occurs. (It is important when doing this to
let the POST loop all night or all weekend to catch intermittents)
If they can do that, it's a lot easier for the hardware engineer
to address a problem that causes a POST failure. If they *can't*
do that, it is likely to be a software problem.
 
T

Tobias Brox

Jan 1, 1970
0
[Guy Macon]
I have my own opinion about
how the author of the page should have handled this, but I would
like to hear some other opinions first.

So, we are waiting ;-)
 
J

John Larkin

Jan 1, 1970
0
[Guy Macon]
I have my own opinion about
how the author of the page should have handled this, but I would
like to hear some other opinions first.

So, we are waiting ;-)

Maybe some of us are. If Guy wants to hijack posts from s.e.d. to
kickstart his personal newsgroup, he's better come up with a few less
boring subjects.

John
 
G

Guy Macon

Jan 1, 1970
0
Tobias said:
So, we are waiting ;-)

To my way of thinking, every communication with a customer having
technical problems should contain a cut and paste section saying:

[1] Feel free to contact us by telephone at 1-800-555-5555,
by email at [email protected], or on the web at
[ http://www.example.com/support/ ].

[2] We offer a money back guarantee; if for any reason you are
not satisfied with your purchase, feel free to return it for a
full refund, including shipping both ways. See
[ http://www.example.com/support/ ] for details on how to return
the product.

[3] We have a FAQ page with information about operating and
troubleshooting our product. The answer to your problem may
be there.

A happy customer tells a friend. An unhappy customer tells
all of his friends. An unhappy customer who is clearly in the
wrong might respond to your pointing that fact out by putting
up a [Your Company Name]sucks.com website. Apologize, refund,
block all purchases from that person, and then stop responding
to them. Not very satisfying, but it maximizes profits over
the long run.

That's my opinion.
 
Top