Yes. I'll click on a banner for something that looks interesting. I've found some good sites (like think geek) that way. I don't mind banners when the page isn't full of them, and when they don't distract from the rest of the page.
I completely agree. GalCiv is a great game, and the developers seem to have an interest in keeping it fun to play. Its also very expandable with user created modules, so it doesn't get boring after a few rounds.
"Legislation introduced in Colorado and Missouri would create a central database of residents who don't want to receive unsolicited e-mail and would allow consumers to sue marketers who ignore their wishes."
This is a nice idea, but most of the spam I get is forged so knowing who to sue would be hard. Plus, I'd worry that spammers would just use the do not email list as a source of email addresses. With phone calls, at least, you can trace who called if you need to. Trying to trackdown hijacked-account@foreign-isp.com will be much harder.
A few suggestions: 1. Create a knowledge base for the help desk describing how to fix common issues, and then have an escalation procedure for how to resolve issues that are not covered. Even if you think that everybody should know how to solve issues this will help you by ensuring that constant procedures are being followed, that you don't have problems where one person fixed a problem before and now another person cannot. It will also help you get a good feel for what kind of issues you know how to deal with, and which you need more information in.
2. Use a ticketing system and make sure everybody uses it. If you cannot track how many issues you have received they never happened. A good ticketing system will also guide your reps in what important data needs to be recorded for every call. A ticket system make it easier for one tech to take over where another left off. Finally, it can provide statistics on problem trends that your developers can use for correcting problems, or for proving to the programers that a problem does exist.
3. You need management buy in to get the development team to stop accepting requests from end users without going through the help desk first. This will be hard at first since your users don't trust the help desk, but they will never trust it unless they are made to use it.
4. Make sure your front line has the tools and training necessary to resolve the bulk of the issues they get. If problems can get solved by the front line peoples the customers will have more respect for them and there will be shorter waits for upper levels to help with common issues. If you have common tasks that are too complicated for your first tear team then create scripts, batch files, or small programs to automate the process.
5. Train your help desk on how to respond to questions they don't know the answer to. They should avoid telling the customer "I don't know how to do that" and say something like "Hold on while I research that issue for you". The costumer doesn't need to know if they are solving the problem themselves or talking to someone more experienced. As soon as the user thinks they are taking to someone who cannot help them, they will not be likely to cooperate and will try to get right to the person they think can resolve the issue (second tear, development, etc).
The only problem with charging even a small fee for an old game is that once people paid for the game they would expect support. Many publishers do not have the resources to support these old games which might not run corectly on newer computers.
The way the license is written, if you use any open-source software, you have to make the rest of your software open source....Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works
I think the nice people at M$ are having trouble understanding the difference between using open source software and using the code from open course software. While this could be pure M$ cluelessness and refusial to understand concepts that are forgen to them, I wonder how many other people aviod open sourse and free software because of simler concerns.
Everyone.net respects the privacy of referred persons and they will not be contacted further by Everyone.net except once to update them about their entry status at the end of the contest.
Weather or not you believe what they say is up to you, however, my guess is that they are more interested in spreading word of their existence then in annoying potential customers. After all, the price of an AIBO is probably still cheaper then many conventional advertising campaigns and will bring many people to the site. Even without spamming, they could do quite well as a result of the publicity.
Slashdot Mirror
I have to say, I never expected to see Sus3an mentioned on Slashdot.
After seeing signs with her name on them all over campus my freshman year, it took me quite a while to realize that the spelling wasn't a typo.
Given that you knew both Sus3an and Cobalt, I suspect you were on campus at the same time I was.
Yes. I'll click on a banner for something that looks interesting. I've found some good sites (like think geek) that way. I don't mind banners when the page isn't full of them, and when they don't distract from the rest of the page.
I completely agree. GalCiv is a great game, and the developers seem to have an interest in keeping it fun to play. Its also very expandable with user created modules, so it doesn't get boring after a few rounds.
"Legislation introduced in Colorado and Missouri would create a central database of residents who don't want to receive unsolicited e-mail and would allow consumers to sue marketers who ignore their wishes."
This is a nice idea, but most of the spam I get is forged so knowing who to sue would be hard. Plus, I'd worry that spammers would just use the do not email list as a source of email addresses. With phone calls, at least, you can trace who called if you need to. Trying to trackdown hijacked-account@foreign-isp.com will be much harder.
A few suggestions:
1. Create a knowledge base for the help desk describing how to fix common issues, and then have an escalation procedure for how to resolve issues that are not covered. Even if you think that everybody should know how to solve issues this will help you by ensuring that constant procedures are being followed, that you don't have problems where one person fixed a problem before and now another person cannot. It will also help you get a good feel for what kind of issues you know how to deal with, and which you need more information in.
2. Use a ticketing system and make sure everybody uses it. If you cannot track how many issues you have received they never happened. A good ticketing system will also guide your reps in what important data needs to be recorded for every call. A ticket system make it easier for one tech to take over where another left off. Finally, it can provide statistics on problem trends that your developers can use for correcting problems, or for proving to the programers that a problem does exist.
3. You need management buy in to get the development team to stop accepting requests from end users without going through the help desk first. This will be hard at first since your users don't trust the help desk, but they will never trust it unless they are made to use it.
4. Make sure your front line has the tools and training necessary to resolve the bulk of the issues they get. If problems can get solved by the front line peoples the customers will have more respect for them and there will be shorter waits for upper levels to help with common issues. If you have common tasks that are too complicated for your first tear team then create scripts, batch files, or small programs to automate the process.
5. Train your help desk on how to respond to questions they don't know the answer to. They should avoid telling the customer "I don't know how to do that" and say something like "Hold on while I research that issue for you". The costumer doesn't need to know if they are solving the problem themselves or talking to someone more experienced. As soon as the user thinks they are taking to someone who cannot help them, they will not be likely to cooperate and will try to get right to the person they think can resolve the issue (second tear, development, etc).
Good Luck
The only problem with charging even a small fee for an old game is that once people paid for the game they would expect support. Many publishers do not have the resources to support these old games which might not run corectly on newer computers.
Hmm, check out http://www.brunching.com/toys/mrtname.html
Read Beggars in Spain by Nancy Kress. She explores the idea of what happens to people who are geneticly altered to not need sleep.
You could start by doing a WHOIS lookup on your domain since that usually returns the registrar. You could also ask your ISP for the information.
Good Luck
I think the nice people at M$ are having trouble understanding the difference between using open source software and using the code from open course software. While this could be pure M$ cluelessness and refusial to understand concepts that are forgen to them, I wonder how many other people aviod open sourse and free software because of simler concerns.
https://www.safeweb.com/o/_i:_o(154):www.slashdot
Does https mast the url? If not all someone would need to do is look at the full url to see where you were visiting.
Toysmart is TRUSTe certified. Why am I not surprised?
Everyone.net respects the privacy of referred persons and they will not be contacted further by Everyone.net except once to update them about their entry status at the end of the contest.
Weather or not you believe what they say is up to you, however, my guess is that they are more interested in spreading word of their existence then in annoying potential customers. After all, the price of an AIBO is probably still cheaper then many conventional advertising campaigns and will bring many people to the site. Even without spamming, they could do quite well as a result of the publicity.