Hello, everyone!!

I've been a lurker for a few months and really value this site -- you all have such great imput and make me realize I'm not the only one going thru the "bad guy" syndrome at work while upgrading us from QS-9000 to TS2.

Okay, I have a question now, and if this has previously been addressed, please ignore, tell me to go away, and/or give me a link to the thread -- that would be appreciated.

7.2.2 ~ Where the customer provides no documented statement of requirement, the customer requirements shall be confirmed by the organization before acceptance.

HUH? :confused:

First of all, how do you implement that -- do you really have to say to the customer "um, are there any other requirements you're not telling me about that I need to confirm" -- sounds a tad insulting to me ...

Second of all, how would you document that this has been done -- I did download an awesome contract review check list posted by a member on this site, and it does have a box marked "requirements not stated by customer are defined" ... but how would you prove that?

Any input would be greatly, greatly appreciated. It's hard enough to get my coworkers on board with this stuff -- now I have to ask them to be mindreaders AND document the information they mindread!!! :bonk:

My tool of choice would be "Quality Function Deployment" (QFD). QFD is a planning tool which translates customer needs and wants into significant items on which to focus time, product improvement efforts, and other resources. If your company uses it with some discipline you may reduce the overall product development cycle.

Don't forget that sometimes customers like to get on the phone and order things. In this case you know what the customer wants, it's just not documented. I believe this is really the intent of that text in the standard.

The "requirements not stated by customer are defined" part really comes in when you know more about your product than your customer, or when some things are just assumed but not stated. If I mail-order a toaster in the USA, I don't specify that it needs to be 115 volts. But if it shows up requiring 220, I'll be pretty hot...

My tool of choice would be "Quality Function Deployment" (QFD). QFD is a planning tool which translates customer needs and wants into significant items on which to focus time, product improvement efforts, and other resources. If your company uses it with some discipline you may reduce the overall product development cycle.

Ben ~ I did forget to mention that we are a value-added distributor. 90% of our business is straight distribution -- so our APQP process as it currently stands is making sure customer requirements are known and quoting them the correct product for their application. We do cut parts to length, also ...

As a distributor, I want to keep this all as simple as it can be -- sometimes the customer will ask us to send them 500' of a specific product they call out -- I guess what I'm saying is I just want to keep this as simple as possible for us (isn't that what we're all trying to do?)

I *really* appreciate your response!!

Karin

Don't forget that sometimes customers like to get on the phone and order things. In this case you know what the customer wants, it's just not documented. I believe this is really the intent of that text in the standard.

The "requirements not stated by customer are defined" part really comes in when you know more about your product than your customer, or when some things are just assumed but not stated. If I mail-order a toaster in the USA, I don't specify that it needs to be 115 volts. But if it shows up requiring 220, I'll be pretty hot...

I wish the writers of the standard would ask normal people to read it over before they expect us to implement it -- I hate being in the position of interpreting their intent ...

And I appreciate your response ~ but let me ask, how do I document an assumption that we're meeting the customers' specifications? Should I work it into a procedure? Do you have any tips you can give?

Thanks so much!!!

I wish the writers of the standard would ask normal people to read it over before they expect us to implement it -- I hate being in the position of interpreting their intent ...

And I appreciate your response ~ but let me ask, how do I document an assumption that we're meeting the customers' specifications? Should I work it into a procedure? Do you have any tips you can give?

Thanks so much!!!


Karin:

Welcome to the Cove!

What I think of here (and we're ISO 9001, not TS, so take it for what its worth) are things like type of packaging and labeling, if a Certificate of Analysis is required, and if shipping information needs to be emailed or faxed. The customer might not think of stating the requirements for these up front, and that will cause problems when the item(s) show up and do not conform with their Quality System.

For instance, we have no stated requirement that the bags of our material should still be upright on the pallet when the customer's truck arrives at the customer's dock. Is it a requirement, nonetheless? You betcha!

Hope this helps

Craig

...how do I document an assumption that we're meeting the customers' specifications? Should I work it into a procedure? Do you have any tips you can give?
How do you have your other "contract review" requirements documented? A verbal order is really no different than a PO or contract. You're already required to have records of review of requirements, only in this case you don't have anything in writing from their end. Just write down their requirements then review them the way you would any other order.

One last thought - you aren't required to have a record that you confirmed their order, but I would recommend a confirmation email or fax in case there's a dispute later...

BTW, I think that there are really two things that are being discussed in this thread - 7.2.2 review of requirements (which I'm addressing in this post), and 7.2.1b-d determination of requirements. I'm trying to keep clear what we're talking about.

...The "requirements not stated by customer are defined" part really comes in when you know more about your product than your customer, or when some things are just assumed but not stated...

I struggled with the Review vs. Determination thing too and this is what I also took it to mean in the end. I've attached an exerpt from our policy manual - some of our customers know exactly what they want, others rely on us to determine what they need. What do you guys think?

BTW, I think that there are really two things that are being discussed in this thread - 7.2.2 review of requirements (which I'm addressing in this post), and 7.2.1b-d determination of requirements. I'm trying to keep clear what we're talking about.

Oops - you're right. I was looking at 7.2.1.

For 7.2.2 - we use a verbal order form.

I struggled with the Review vs. Determination thing too and this is what I also took it to mean in the end. I've attached an exerpt from our policy manual - some of our customers know exactly what they want, others rely on us to determine what they need. What do you guys think?

PS - We're ISO not TS.Am I the only one who NEVER was confused about the intent of 'confirming customer requirements'?

It always seemed straightforward to me:
If the customer didn't provide WRITTEN detailed description of his requirements for a custom product (versus off-the-shelf item), it was our job to ask questions until we were sure we understood. Once we made the determination, we WROTE it down (copy to customer for confirmation via FAX or [now] email when time was a factor.)

With an off-the-shelf item, we made doubly sure customer made no error when ordering by phone ("Part number 15-345? Yessir, to confirm so I have it right, you want a green spindizzy for a framsit. Is that correct?")

Am I the only one who NEVER was confused about the intent of 'confirming customer requirements'?

It always seemed straightforward to me:
If the customer didn't provide WRITTEN detailed description of his requirements for a custom product (versus off-the-shelf item), it was our job to ask questions until we were sure we understood. Once we made the determination, we WROTE it down (copy to customer for confirmation via FAX or [now] email when time was a factor.)

With an off-the-shelf item, we made doubly sure customer made no error when ordering by phone ("Part number 15-345? Yessir, to confirm so I have it right, you want a green spindizzy for a framsit. Is that correct?")

Thank you, Cari, and Wes --- I've downloaded Cari's form and will look at it, and Wes, yes, we know we have to meet customer requirements -- that's not what the issue is with my company. We probably fill close to 150 orders a day and we're supposed to add the time to that to predict what the customers might want? Just a little nuts if you ask me.

Thanks everyone for your help!!!

Karin -

My apologies - my mind grabbed onto "7.2.1b) requirements not stated by the customer but necessary for specified or intended use, where known", where you were asking about 7.2.2 regarding undocumented requirements.

BTW - Welcome to the cove :bigwave:

For what it's worth, Ithink 7.2.1b goes further. We used to have customers call and say "put some of that yellow stuff on our bolt". The responsibility is now given to us to not only cover all the standard questions but to also anticipate unspecified requirements based on our expertise as a supplier.
One way to think of it is to pull out all those old customer complaints that were traced to missunderstandings at the time of contract. Dust off the "unjustified" ones where a new requirement was suddenly added without the customer telling us. All these odd issues we ran into in the past should now be standard questions in contract review/APQP.
Now when a customer asks for some yellow stuff we need to be asking about the application and what is expected of it. If our questions lead to a requirement of the yellow stuff holding up under 700 degrees F., we need to tell the customer they should be looking at green stuff instead.
IMHO the new standard puts responsibility for customer perception squarely in the supplier's lap. It is up to us to be the expert in the buy/sell relationship and to provide the customer with any and all information to provide better service - no matter if the customer thinks to ask.
JMHO

Dave

I think you've got the right approach to this Dave. Of course this doesn't have to be rocket science. Fast food places have been doing it for years.
"Do you want fries with that?" = 7.2.1b
"You ordered a greasy burger, large fries and a large orange drink. That'll be $53.58 at the drive up window." = 7.2.2 confirmation.

I think you've got the right approach to this Dave. Of course this doesn't have to be rocket science. Fast food places have been doing it for years.
"Do you want fries with that?" = 7.2.1b
"You ordered a greasy burger, large fries and a large orange drink. That'll be $53.58 at the drive up window." = 7.2.2 confirmation.

I get what you're all saying, I really do, and trust me, our little co. of 14 employees wouldn't have 10 million in sales if we didn't take care of the customers -- and by taking care I mean exceeding their expectations.

Here's my problem, tho -- not to beat a dead horse -- if the McPlace above were being audited, how would you PROVE to the auditor that you gave that verbal confirmation? Am I just being too picky here? This is a big thing for us.

Thank you everyone for the advice and the welcomes!

PS To Cari, what you sent me was a great reference tool -- thanks.

I get what you're all saying, I really do, and trust me, our little co. of 14 employees wouldn't have 10 million in sales if we didn't take care of the customers -- and by taking care I mean exceeding their expectations.

Here's my problem, tho -- not to beat a dead horse -- if the McPlace above were being audited, how would you PROVE to the auditor that you gave that verbal confirmation? Am I just being too picky here? This is a big thing for us.

Thank you everyone for the advice and the welcomes!

PS To Cari, what you sent me was a great reference tool -- thanks.

Tell them the same thing I do; It's on the computer screen.

You don't have to prove it. If there is no required record, the auditor has the responsibility to find whether you are or aren't doing it. They can do this by observing personnel doing it, or by interviewing them. A skilled auditor will be able to ask the right questions to find out what they are doing. If they get the same response from several people, that would be considered "objective evidence" that it was (or wasn't) being done.

If there is no required record, the auditor has the responsibility to find whether you are or aren't doing it.

Did I really read that???? WOW a voice of reason! I'm kidding but you make good sense here.

Karin,
Your proof is the Sales $ and Customer Sat scores, along with the procedure, the interview etc.

Thank you so much to everyone -- it's so nice to have other folks' opinions to consider.

Karin

Here's my problem, tho -- not to beat a dead horse -- if the McPlace above were being audited, how would you PROVE to the auditor that you gave that verbal confirmation? Am I just being too picky here? This is a big thing for us
This conversation is being recorded for quality assurance purposes. Just kidding.

How about a check box on your order form indicating verbal confirmation?

You might try defining for your organization the "basics" for taking an order. We actually just discussed this very issue with our registrar yesterday (here for our last, hopefully, QS audit before "transitioning"). In our world, for instance, if you want steel there are BASIC things we need to know, like what thickness, what width, what alloy, what tensile strength, etc. We OFTEN have customers who call and give us width, thickness, and what the part is they'll be making, but nothing else. It is then up to us to DISCERN what rockwell strength, tensile strength etc. will be required for the customer to make that part successfully. And in such cases we will document the addition of those specs to the customer order as an "internal spec" - not something the customer asked for, but something we KNOW THEY NEED (that's the mind-reading part) to make the part successfully.

So, for your process you might look at defining what those basics are, and then establishing some sort of method for asking the question when the customer fails to give you any of those basics. And if they really don't have that info to give you, figuring out a way to document that basic requirement ANYWAY.

This conversation is being recorded for quality assurance purposes. Just kidding.

How about a check box on your order form indicating verbal confirmation?

LOL - good one Al. Also a good suggestion - nice and simple.

You might try defining for your organization the "basics" for taking an order. We actually just discussed this very issue with our registrar yesterday (here for our last, hopefully, QS audit before "transitioning"). In our world, for instance, if you want steel there are BASIC things we need to know, like what thickness, what width, what alloy, what tensile strength, etc. We OFTEN have customers who call and give us width, thickness, and what the part is they'll be making, but nothing else. It is then up to us to DISCERN what rockwell strength, tensile strength etc. will be required for the customer to make that part successfully. And in such cases we will document the addition of those specs to the customer order as an "internal spec" - not something the customer asked for, but something we KNOW THEY NEED (that's the mind-reading part) to make the part successfully.

So, for your process you might look at defining what those basics are, and then establishing some sort of method for asking the question when the customer fails to give you any of those basics. And if they really don't have that info to give you, figuring out a way to document that basic requirement ANYWAY.

Thank you so much SteelWoman!!! This really clears it up for me and will help us implement this so well! I really appreciate it.

Karin :)

Aw, gee... you're making me blush! :o :o

Glad I could help. That's what the Cove's all about, right?

A couple of thought here. First, a short story.

Back in the 70's, when I was in college, I had my hair rather short. I had a roommate who had his long. One day he went to my barber to get his hair cut. He came back fuming. The barber asked how he wanted his hair cut, and his response was: "Over the ears", meaning he wanted it overlapping the top of his ears. The barber cut it over the ears, as in not touching. They both said the same words, but had two different concepts.

It is our (the organization) to ensure we understand what the customer wants. Most times verbal orders are repeated to help prevent mixups. When the standards says "confirmed... before acceptance". I think that is what they are saying.