re: Motorola MPX-220 and 98500 Bluetooth "Customer Support"
I have no idea. Just feel lucky that you can train the car kit...
« June 2005 | Main | August 2005 »
My new Thinkpad T40 DVD Multi-write RW drive was not working. I called the IBM support number from their web site. They said they would send me a new drive with packing materials to send back the old drive. It arrived the next day. The new drive works. It took me 7 minutes on the phone and 3 minutes to package up the drive and call Airborne to come pick it up.
Now that's customer service. They respect my time, my competence and my value as a loyal customer.
Thanks IBM.
It's too bad more companies (like Motorola) can't learn from IBM's lesson.
Updated: July 26
I'm working with the July CTP this week I've discovered the following:
The Good News:
The Bad News:
105 days to go... if you count the weekends.
What makes the knuckleheads overseas think that their constant bombardment of messages in Chinese, Korean, Russian or Hungarian has even a remote chance of doing anything but making me (and lots of others) mad? On an average day I get over 100 messages in unreadable fonts. I wonder if they're really trying to communicate with me? Could these be fans or bill collectors? Sure, I expect they're stupid spammers trolling for the odd Chinese-reading soul out in the ether somewhere. Yup, they're using those bulk mailing lists that don't bother to differentiate between those that read their language and those that don't--or they don't care. It doesn't cost any more to send to a billion random addresses than it does to send it to one. I just wish Outlook or some layer up the line would just destroy that junk instead of clogging up my system with their jibberish. I get quite enough crap as it is.
What's going to happen is just that. ISPs are going to start figuring out that their customers don't need (or want) mail sent to them in specific character sets and they'll stop forwarding them (on request). The spammers are going to force the entire world to radically change how we exchange information. Microsoft etal. need to do a lot more--not just beat their chest. I guess they're too busy defending themselves from foreign governments and fifedoms who want a piece of the pie to bother with things that really matter.
Just my $.02.
Drive C was full...
Repaired .TEXT -- the SPAM blocker is still in place.
Let's see if comments are working againg. If not, you know how to reach me.
Thanks for your patience.
I just spent the last couple of hours writing and debugging about 40 lines of TSQL code in SQL Server 2005 Management Studio—it should have taken far less time. What a PITA. Once you’ve worked with Visual Studio for years on end, having to write code in a stone-age editor/debugger is the pits. When you get a syntax error, the line number it gives you might (if you’re really lucky) point in the general vicinity of the problem. The compiler gets really confused at the slightest mistake (missing paren or stray END statement). It also has no intellisense so as you work through the archaic T-SQL code, we make more mistakes than ever because the way CHARINDEX and some other functions accept their arguments just seems backwards—and I’ve been using T-SQL since…well, the dawn of time in SQL Server years. That’s what I get for trying to be multi-lingual.
It will be really nice when T-SQL can be coded and debugged like Visual Basic or C# (well, like Visual Basic who wants anal case-sensitivity?). And where is step-into debugging for ad hoc queries? I guess I could convert the code segments to stored procedures and run them there… but that’s not always possible. And no, this code does not make sense as a CLR function.
After four months, Motorola finally contacted me in response to a customer service request I placed March 17th. The conversation went something like this:
|
Response (Erik) |
07/04/2005 12:10 PM |
|
Dear William Vaughn, | |
|
| |
|
Customer (William Vaughn) |
07/04/2005 12:34 PM |
|
Wow… three months to reply. That’s a new record for slow service! The Motorola Hands-Free kit is a 98500. I also have installed the latest update to the phone's BIOS (last week) but it has had no effect on the ability to train the hands free kit. | |
|
Response (Erik) |
07/04/2005 02:01 PM |
| ||||
|
Well in that case let me provide you with the information of how to train it on the bluetooth car kit |
| |||||
|
| |||||
|
Response (Erik) |
07/04/2005 02:33 PM |
|
Which phone model do you have in this case? | |
|
Customer (William Vaughn) |
07/04/2005 02:51 PM |
|
Model? MPX220 and the 98500 hands-free kit. What more do you need? | |
|
Response (Erik) |
07/04/2005 03:04 PM |
|
In this case, the voice recognition with the phone does not work over bluetooth it will need to be a hard wired car kit and for the bluetooth car kit it will be the same information that I provide you before, in this case I will recommend you to get in contact with the person the installed the car kit for verification of the device. | |
|
Customer (William Vaughn) |
07/04/2005 03:09 PM |
|
The hands free device works fine with other Motorola phones (as I said) so it would be more of waste of my time and money to "verify" the device. | |
|
Customer (William Vaughn) |
07/04/2005 03:47 PM |
|
I just re-read your message. The 98500 IS a bluetooth car kit. So you're saying it should work, I should be able to train it with bluetooth? | |
|
Response (Erik) |
07/04/2005 03:57 PM |
|
Yes on the bluetooth car kit it self, yes you should be able to do that. | |
|
So… Motorola is STILL saying that the MPX-220 should be trainable by the 98500 car kit. | |
|
Customer (William Vaughn) |
07/05/2005 11:29 AM |
|
So, what is your solution? What is it going to do to get you to honor the warranty? Of course this entire conversation will be posted to my blog which is read by people (your customers) all over the world. | |
|
Customer (William Vaughn) |
07/04/2005 04:02 PM |
|
Again, I've been talking about the 98500 BLUETOOTH car kit all along. IT CANNOT BE TRAINED FROM THE MPX220. Other phones can train it over bluetooth. What other solutions do you have? | |
|
Here’s where the supervisor come in. Notice that “Marco” knows how to write English. | |
|
Response (Marco) |
07/06/2005 11:58 AM | |
|
Thank you for contacting Motorola E-mail support. | ||
|
Customer (William Vaughn) |
07/06/2005 12:13 PM | |
|
Yes, I was aware of the type of phone and its features when I bought it. However, I was not made aware of its limitations until after I bought it and the hands-free kit. Nothing on your side lead me to believe that the hands-free kit would not respond to voice dialing. At the time The 98500 was recommended as the best choice for the phone. The 98500's description included voice activation, voice dialing and other voice-activated features. If you had told me that these voice capabilities would not work with the phone I would not have spent so much time and money trying to get them to work. On more than one occasion your own support people insisted that the feature "should work" and it was a problem either with the phone (I returned it for repair) or the unit (I tested it with another type of phone). This is unacceptable. As I see it, you need to refund me the price of the hands free kit and the cost to install it and remove it. | ||
|
Response (Marco) |
07/06/2005 01:13 PM | |||||
|
Thank you for contacting Motorola E-mail support.
After that, a Motorola “Consumer Resolution” representative “Maria” called my home and we spoke for some time. I explained that I was a loyal Motorola customer. My first cell phone was a Motorola and I bought Motorola phones for my entire family. I told her I intended to use the MPX-220 as a software platform and I was planning to write a book about its use when the new OS was released (those plans are now officially cancelled). Their suggestion that I buy another Motorola phone to work with the car kit did not go over very well. I had paid a pretty penny for the MPX-220 when it first came on the market thinking that it would work with the Bluetooth devices that Motorola’s own website suggested. She wrote down that I have a MPX-200 in the call log. I told her that we (and my wife and I) are concerned about safety as while driving I can’t answer or dial the phone (as advertised) by voice command. I mentioned that the MPX-220 was discovered and connected to the blue-tooth interface within seconds on a 2005 Acura MDX (very cool). The MDX had no trouble using voice dialing with the phone in my pocket. (double cool). She offered to replace the 98500 car kit with their latest model. I asked if the new kit would work any better. She said no. I asked if she would pay to have the 98500 removed and the new “improved” kit installed. She said no. I said “No thanks”. I asked if Motorola would honor their warranty. She said that because I bought my kit from someone other than Motorola, that they could not refund the price or the cost to have it uninstalled. She convinced me to accept a speaker phone accessory for my trouble. At that point I gave up on Motorola ever doing anything substantive toward keeping me as a customer. That day I received notification that she had ordered a speaker phone accessory (about $7) that would arrive “overnight”. It never came. In curiosity, on Tuesday the 12th I called to check on the status—the order had been cancelled. Their approach to “customer satisfaction” is hardly one to win any customers. I guess my only option is to send a letter to the FTC. | ||||||
July 8, 2005 • Vol.27 Issue 27
Page(s) 21 in print issue
One of the questions I was asked at the DevTeach conference, which was held in Montreal the week of June 18, concerned placement of business logic in stored procedures. People asked, “Is this the proper place?” I told them a rather long story about when I worked for the Department of Public Safety in Austin in the ’70s.
When I was asked to program the new key-data entry system, I started out by building a set of screens that matched the forms the keypunch operators were transcribing. The routine captured the data, and when the operator pressed the Submit key, the program validated the data against the programmed criteria. This caused quite a problem for me, as the women (they were all women back then; men did not last very long as keypunch operators) complained that the technique was inefficient. They encouraged me (in no uncertain terms) to alter the program to perform more efficient edits.
When they were working with a particular part of the multipage form, the program should edit the field while they were still focused on it. (They watched the paper and not the screen.) This was more difficult to program, as some of the validation “rules” were made based on two or more related fields. For example, the AccidentDate could not precede the ArrestDate but must be greater than the BirthDate (at least by a few years). This meant that while most of the validation checks were done immediately, some were delayed until all dependent information was enteredbut rarely after the completed form was submitted. It took a bit of getting used to, but I (and the operators) finally got the hang of it, and productivity was restored. (And they began letting me in the room again.)
Business Rules vs. Validity Checks
One might call these checks business rules, but many were simply validity checks: They verified that a properly formatted and ranged date was entered in a date field, numbers that made sense were entered in the number fields, and the right code was used for the specified county. For the most part, these validity checks were clearly understood and were not subject to change.
In contrast, business rules are checks determined by business policies or practices. For example, if a driver’s blood alcohol level is greater than 1.2, the driver would be considered to be driving under the influence (as dictated by law). But given the evolving attitudes toward driving under the influence, this tolerance level is subject to change. This is clearly a business rule.
Keeping The Data Pure
The whole idea behind these client-side checks is to prevent "bad" data from reaching the database. The final wall of protection in today's databases (such as SQL Server) should include routines that validate each column as the data is entered. This can be simple to implement in SQL Server: All you need to do is assign User-defined Types (really just aliases) to each of the columns in the data table. Many columns can share the same UDT, as long as they share the same business rule to guarantee that the data is pure. For example, you can define a single UDT with a bound SQL Server Rule for ZIP-code columns to make sure there are enough digits in the right range and format.
Rules are free-standing in that they can be applied to any table in the database. If a rule is changed, all new data must conform to the new criteria. Changing existing data to conform to the new rule would be up to you and your code. If your SQL Server rules govern the range of valid data values being applied, they can certainly be dubbed “business rules,” especially if they have to correlate with other columns. However, a SQL Server rule can’t do that. All of its checks validate a single column. Check constraints do the same thing in a similar way but are different in that they are bound to a specific table and column and not to a specific UDT. Triggers and stored procedures can be used for more complex validation tasks.
Where Do Business Rules Belong?
The question remains: Where do business rules belong? Do they belong in the UI code that validates the information as it’s entered, in the middle-tier where data row columns are validated against one another or other database tables, or on the server where code is used to prevent bad data from being introduced into the database? The answer is all of the above. Business rules belong on the client system to improve data-entry productivity, in the middle-tier to improve application support productivity, and on the server to protect the data.
To help coordinate these rules, I have designed applications that import client-side rules from Extended Properties on the server so business rules and validation constraints can be centrally managed. This seems like a good trade-off. We don’t want an application that has to be redeployed every Friday at 7 a.m. as rules are updated. That’s what we did at EDS, and it made us get up too early in the morning.
I overheard that there is a “slight” problem with Passport in that it requires reauthentication of a Hotmail account after it's been connected for over 24 hours. My systems are on 7-24 so that has happened to me for some weeks now. The symptom? Hotmail account(s) in Outlook constantly prompt for a password. If you enter the right password, they just prompt again until you restart Outlook. The folks in Redmond are working on a fix.