OT Supporting an application

[salad]

I have an application written in MS-Access. It is a complete
application that manages the day-to-day operations of a business.

The program is nearly ready to be used in other customer sites.

I am wondering if any of you have advice on supporting an application.
Since it has never had any outside exposure, what I don't want is to
make a bunch of sales and not be able to support the issues that arise.
I believe as kinks are worked out with a smaller set of companies, it
can be released to more companies. I simply don't want to have a bunch
of sales but no means to handle customer support problems.

I also know that companies that purchase it will make suggestions for
enhancements. Others may need some custom programming beyond the scope
of the core program.

So I will need to supply tech support and also additional programming.

My question is "How many companies can 1 person reasonably support?"
I'm not looking for a firm figure, more an idea of what the heck I'm
getting myself into. Without a sale yet, I can't afford another
programmer. I'm wondering if there are "breakpoints" or milestones
where you need to expand and hire more people.

If you've been involved with or taken a software program from concept to
sales, I'd appreciate it if you'd share some knowledge of your experiences.

[Allen Browne]

Salad, congratulations on getting to the place where your application is
marketable.

Hopefully you will get several responses, where you gain the benefit of
everyone's experiences.

Assuming that you have done a good job with programming, and don't have lots
of experience with sales and marketing, I doubt you have too much to worry
about here. Sales will happen slowly enough. You will have the benefit of
feedback to enhance your application. By the time you have dozens of
customers to support, you will have a good, stable piece of software that
works as users expect.

Hopefully have have considered how you charge for support (regular monthly
fee, or $/hr when needed.)

No matter how good you are, there will also be some irrelevant support
questions from users, e.g. "Why won't your program accept Feb 31?", or
"Which printer did my report go to?" or "Why isn't my mouse working?" Since
Access is used by lots of people outside corporate database environments,
some of these users don't have anyone they can ask basic things like how to
set the date on their computer.

Some other suggestions to help with support:

1. Log errors
Users do not read error messages, and can't tell you what happened. Simple
error logging lets you know what the error was, when it happened, who it
happened to, and how often it recurred. You may even want to include a
command button that prints or emails the error log report so the user can
send it to you. Example:
http://allenbrowne.com/ser-23a.html

2. Consider recording basic record info
Every table I create gets 4 additional fields pasted in, to record who
created the record and when, and who last updated the record and when.
Without this, you can't verify if your application is working correctly or
not. Users will ask you, "Why didn't order 999 get invoiced last month?" If
you can demonstrate that order 999 was actually entered on Jan 3rd, and they
generated the December invoices on January 2, you can be satisfied that it
is not a bug with your invoice generating routine. Conversely, if the record
has not been entered or modified, you have proved to yourself that there is
a bug you need to solve.

3. Version info
For remote support, you need to provide a screen where the user can read you
version details on:
- your software
- Office service packs
- JET service packs
as well as basic info about which back end they are connected to. (Don't
laugh: users will connect to a backup, and then ask you why their data is
not consistent with everyone else's.)
Example:
http://allenbrowne.com/ser-53.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"salad" <cu*****@george.comwrote in message
news:0v******************@newsread2.news.pas.earth link.net...

>I have an application written in MS-Access. It is a complete application
that manages the day-to-day operations of a business.

The program is nearly ready to be used in other customer sites.

I am wondering if any of you have advice on supporting an application.
Since it has never had any outside exposure, what I don't want is to make
a bunch of sales and not be able to support the issues that arise.
I believe as kinks are worked out with a smaller set of companies, it can
be released to more companies. I simply don't want to have a bunch of
sales but no means to handle customer support problems.

I also know that companies that purchase it will make suggestions for
enhancements. Others may need some custom programming beyond the scope of
the core program.

So I will need to supply tech support and also additional programming.

My question is "How many companies can 1 person reasonably support?" I'm
not looking for a firm figure, more an idea of what the heck I'm getting
myself into. Without a sale yet, I can't afford another programmer. I'm
wondering if there are "breakpoints" or milestones where you need to
expand and hire more people.

If you've been involved with or taken a software program from concept to
sales, I'd appreciate it if you'd share some knowledge of your
experiences.

[salad]

Allen Browne wrote:

Salad, congratulations on getting to the place where your application is
marketable.

Hi Allen. Thank you for your kind words.

Hopefully you will get several responses, where you gain the benefit of
everyone's experiences.

I'm hoping so too.

Assuming that you have done a good job with programming, and don't have
lots of experience with sales and marketing, I doubt you have too much
to worry about here. Sales will happen slowly enough. You will have the
benefit of feedback to enhance your application. By the time you have
dozens of customers to support, you will have a good, stable piece of
software that works as users expect.

That is exactly what/where I am. Good program, little marketing
experience. I expect sales to be slow initially. I figure that for
each sale, kinks will be exposed which I can then remove.

Next month the program will receive the award for product innovation
from one of the industry's organizations. I anticipate the award will
generate some interest.

Hopefully have have considered how you charge for support (regular
monthly fee, or $/hr when needed.)

No, I haven't. I haven't gotten to that point. I don't know where to
begin for even that part.

No matter how good you are, there will also be some irrelevant support
questions from users, e.g. "Why won't your program accept Feb 31?", or
"Which printer did my report go to?" or "Why isn't my mouse working?"
Since Access is used by lots of people outside corporate database
environments, some of these users don't have anyone they can ask basic
things like how to set the date on their computer.

Yes. I expect that. We have a pretty slick documentation system in the
app. External hard copy documents are scanned in. I expect I'll have
to be an expert in scanners in short order.

Some other suggestions to help with support:

1. Log errors
Users do not read error messages, and can't tell you what happened.
Simple error logging lets you know what the error was, when it happened,
who it happened to, and how often it recurred. You may even want to
include a command button that prints or emails the error log report so
the user can send it to you. Example:
http://allenbrowne.com/ser-23a.html

I implemented such a feature a few months ago. It has helped out.

2. Consider recording basic record info
Every table I create gets 4 additional fields pasted in, to record who
created the record and when, and who last updated the record and when.
Without this, you can't verify if your application is working correctly
or not. Users will ask you, "Why didn't order 999 get invoiced last
month?" If you can demonstrate that order 999 was actually entered on
Jan 3rd, and they generated the December invoices on January 2, you can
be satisfied that it is not a bug with your invoice generating routine.
Conversely, if the record has not been entered or modified, you have
proved to yourself that there is a bug you need to solve.

Good point. I have the who created/when but not the who last updated
feature. I could implement that easily enough for the major tables.

3. Version info
For remote support, you need to provide a screen where the user can read
you version details on:
- your software
- Office service packs
- JET service packs
as well as basic info about which back end they are connected to. (Don't
laugh: users will connect to a backup, and then ask you why their data
is not consistent with everyone else's.)
Example:
http://allenbrowne.com/ser-53.html

Yes, I have an About screen that presents my software information.

I was wondering about the Office/Jet service pack points. If the
program is distributed as a runtime, do runtimes also get service packs?
Are they viewable from the help menu bar like having a full version?
Will I need to send out emails to folks when a new service pack is
available?

Thanks again.

[John Mishefske]

salad wrote:

My question is "How many companies can 1 person reasonably support?" I'm not looking
for a firm figure, more an idea of what the heck I'm getting myself into. Without a
sale yet, I can't afford another programmer. I'm wondering if there are
"breakpoints" or milestones where you need to expand and hire more people.

In addition to Allen's suggestion I'd suggest your carefully track your different
versions. I'd start with a simple text file to explain what changed in each version.

Then keep a copy of the .mdb (with full code - not a .MDE) for each verson or consider
using a source control software like Microsoft's Visual SourceSafe.

Another software you might consider creating yourself is a Problem Tracking app to keep
track of support calls, resolution, etc.

They can serve as a Knowledge Base for future support requests, allow you to prioritize
multiple requests and do reports, etc.

--
'---------------
'John Mishefske
'---------------

[Allen Browne]

Salad, John's point about version tracking is a good one.
I use a table in the front end to record each change in each version.

Re your question about runtime, the Microsoft packaging wizard is
particularly bad at this. Those who've used Sage or one of the other
installers might like to comment about how it works with those.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"John Mishefske" <jm**********@SPAMyahoo.comwrote in message
news:45**********************@roadrunner.com...

salad wrote:

My question is "How many companies can 1 person reasonably support?" I'm
not looking
for a firm figure, more an idea of what the heck I'm getting myself
into. Without a
sale yet, I can't afford another programmer. I'm wondering if there are
"breakpoints" or milestones where you need to expand and hire more
people.

In addition to Allen's suggestion I'd suggest your carefully track your
different versions. I'd start with a simple text file to explain what
changed in each version.

Then keep a copy of the .mdb (with full code - not a .MDE) for each verson
or consider
using a source control software like Microsoft's Visual SourceSafe.

Another software you might consider creating yourself is a Problem
Tracking app to keep track of support calls, resolution, etc.

They can serve as a Knowledge Base for future support requests, allow you
to prioritize multiple requests and do reports, etc.

--
'---------------
'John Mishefske
'---------------

[CDMAPoster]

salad wrote:

I have an application written in MS-Access. It is a complete
application that manages the day-to-day operations of a business.

The program is nearly ready to be used in other customer sites.

I am wondering if any of you have advice on supporting an application.
Since it has never had any outside exposure, what I don't want is to
make a bunch of sales and not be able to support the issues that arise.
I believe as kinks are worked out with a smaller set of companies, it
can be released to more companies. I simply don't want to have a bunch
of sales but no means to handle customer support problems.

I also know that companies that purchase it will make suggestions for
enhancements. Others may need some custom programming beyond the scope
of the core program.

So I will need to supply tech support and also additional programming.

My question is "How many companies can 1 person reasonably support?"
I'm not looking for a firm figure, more an idea of what the heck I'm
getting myself into. Without a sale yet, I can't afford another
programmer. I'm wondering if there are "breakpoints" or milestones
where you need to expand and hire more people.

If you've been involved with or taken a software program from concept to
sales, I'd appreciate it if you'd share some knowledge of your experiences.

One large company that supports 10 to 20 companies with the same
electronic health care billing program limits the customization to
changes that will be used by most of the companies. They basically
tell their customers, "You are not allowed to have that particular
functionality." That is not a good idea. You want to be able to make
changes for a single company without making the application much more
complicated. You don't want to support 15 different versions of the
software so you need something like conditional compilation.

Take a look at the following thread entitled "Tip - alternative to
conditional compilation"

http://groups.google.com/group/comp....1d961323f7066c

If you don't have a plan for handling this kind of branching you will
soon reach a point where you wonder why you got into the programming
business at all. I wish you success in your venture. Not many
programs reach that level, but I have been involved with some. I
remember that the idea of a huge margin from selling custom software
for the cost of CD duplication was one of my incentives for getting
into this business.

Lots of people come up with good ideas for making money. It is the
people who have followed through from concept to reality who actually
come away with the most valuable knowledge. The famed Egyptologist Sir
William Flanders Petrie remarked that the real treasure to be found in
Egypt is history rather than gold. I can't say that I've had anything
even remotely close to Lyle's success in my dealings in these matters,
but the experience is invaluable. Maybe Canadians in the 50's were
inherently more honest than the people I dealt with :-). I know where
most of the snags are going to be the next time around. Please keep us
apprised of the situations you encounter.

I have some end-to-end applications that I can market but I haven't
made one yet that I feel can separate me sufficiently from the
competition. I keep improving my skills and always look for a way to
develop a new market.

James A. Fortune
CD********@FortuneJames.com

Blue Ocean Strategy : How to Create Uncontested Market Space and Make
the Competition Irrelevant
by Kim, W. Chan.; Mauborgne, Renée.
Publication: Boston, Mass. : Harvard Business School Press, 2005.

ISBN 1-59139-619-0

>From the preface:

"Blue ocean strategy" challenges companies to break out of the red
ocean of bloody competition by creating uncontested market space that
makes the competition irrelevant. Instead of dividing up existing--and
often shrinking--demand and benchmarking competitors, blue ocean
strategy is about growing demand and breaking away from the
competition.

The contents of this book are based on more than fifteen years of
research, data stretching back more than a hundred years, and a series
of "Harvard Business Review" articles as well as academic articles on
various dimensions of this topic. The ideas, tools, and frameworks
presented here have been further tested and refined over the years in
corporate practice in Europe, the United States, and Asia.

[Tom van Stiphout]

On Sun, 21 Jan 2007 10:29:34 +0900, "Allen Browne"
<Al*********@SeeSig.Invalidwrote:

Indeed, the Microsoft one caused me headaches a few years back. Approx
15-20% of the installations of our app would not succeed without one
or more support calls.
Recently another client hired Sage to build the installer for her, and
it works flawlessly.

-Tom.

>Salad, John's point about version tracking is a good one.
I use a table in the front end to record each change in each version.

Re your question about runtime, the Microsoft packaging wizard is
particularly bad at this. Those who've used Sage or one of the other
installers might like to comment about how it works with those.

[Tom van Stiphout]

On Sat, 20 Jan 2007 19:01:25 -0600, John Mishefske
<jm**********@SPAMyahoo.comwrote:

On the topic of versioning: put a version number in both the front-end
and the back-end, and write code such that the two must be in sync for
the app to start up. You don't want FE 3 to run against BE 1.

-Tom.

>salad wrote:

My question is "How many companies can 1 person reasonably support?" I'm not looking
for a firm figure, more an idea of what the heck I'm getting myself into. Without a
sale yet, I can't afford another programmer. I'm wondering if there are
"breakpoints" or milestones where you need to expand and hire more people.

In addition to Allen's suggestion I'd suggest your carefully track your different
versions. I'd start with a simple text file to explain what changed in each version.

Then keep a copy of the .mdb (with full code - not a .MDE) for each verson or consider
using a source control software like Microsoft's Visual SourceSafe.

Another software you might consider creating yourself is a Problem Tracking app to keep
track of support calls, resolution, etc.

They can serve as a Knowledge Base for future support requests, allow you to prioritize
multiple requests and do reports, etc.

[Tom van Stiphout]

On Fri, 19 Jan 2007 17:47:40 GMT, salad <cu*****@george.comwrote:

Congrats Salad. A great achievement. I often think it's easy to get to
95% complete, but to get to 100%: golden.

Do you have a website promoting this app? I think you were working on
a ski resort app? Some of my suggestions might be tailored better if
I knew more about your app.

The topic of offering customer support is one you need to figure out
BEFORE you start selling. Clients have the right to know what they are
getting into. Perhaps it makes sense to offer first 30 days free
support, after that on T&M basis. They download and fax back a Support
Contract, and you bill against that. It may state that you can bill up
to 4 hours per issue, and if not resolved need to go to a Work Order
contract. Again, this differs widely depending on kind of application,
purchase price, etc.

-Tom.

>I have an application written in MS-Access. It is a complete
application that manages the day-to-day operations of a business.

The program is nearly ready to be used in other customer sites.

I am wondering if any of you have advice on supporting an application.
Since it has never had any outside exposure, what I don't want is to
make a bunch of sales and not be able to support the issues that arise.
I believe as kinks are worked out with a smaller set of companies, it
can be released to more companies. I simply don't want to have a bunch
of sales but no means to handle customer support problems.

I also know that companies that purchase it will make suggestions for
enhancements. Others may need some custom programming beyond the scope
of the core program.

So I will need to supply tech support and also additional programming.

My question is "How many companies can 1 person reasonably support?"
I'm not looking for a firm figure, more an idea of what the heck I'm
getting myself into. Without a sale yet, I can't afford another
programmer. I'm wondering if there are "breakpoints" or milestones
where you need to expand and hire more people.

If you've been involved with or taken a software program from concept to
sales, I'd appreciate it if you'd share some knowledge of your experiences.

[salad]

Tom van Stiphout wrote:

On Fri, 19 Jan 2007 17:47:40 GMT, salad <cu*****@george.comwrote:

Congrats Salad. A great achievement. I often think it's easy to get to
95% complete, but to get to 100%: golden.

Hi Tom:

Thanks for your support and encouragement.

I have to wonder if I am at 100%. I know there are more features my
application should offer. I have what I term a "Microsoft view" of my
program. If I wait forever to get the perfect program it will never
leave the door. If Microsoft waited for the perfect Windows, we might
never have seen version 3.1 when Windows started to gain acceptance.

Do you have a website promoting this app? I think you were working on
a ski resort app? Some of my suggestions might be tailored better if
I knew more about your app.

No. The ski resort app is Albert Kallal's. If his app is like the
pictures on his website, he does beautiful work.

My program manages a commercial subcontractor's office. The contractor
can run one or many types of businesses; hvac, electrical, plumbing, etc
from it. The target audience is companies having 5 to 20 office staff
and however many tradesmen they require in the field with annual sales
between 1 million to 100 million.

You ask if I have a website. You've exposed a "major flaw". No I
don't. I do realize it is the electronic equivilent of a business card
thatt can reach more people. It is a top priority of mine.

The topic of offering customer support is one you need to figure out
BEFORE you start selling. Clients have the right to know what they are
getting into. Perhaps it makes sense to offer first 30 days free
support, after that on T&M basis. They download and fax back a Support
Contract, and you bill against that. It may state that you can bill up
to 4 hours per issue, and if not resolved need to go to a Work Order
contract. Again, this differs widely depending on kind of application,
purchase price, etc.

Very interesting. I like the concept you described.

>
-Tom.

>>I have an application written in MS-Access. It is a complete
application that manages the day-to-day operations of a business.

The program is nearly ready to be used in other customer sites.

I am wondering if any of you have advice on supporting an application.
Since it has never had any outside exposure, what I don't want is to
make a bunch of sales and not be able to support the issues that arise.
I believe as kinks are worked out with a smaller set of companies, it
can be released to more companies. I simply don't want to have a bunch
of sales but no means to handle customer support problems.

I also know that companies that purchase it will make suggestions for
enhancements. Others may need some custom programming beyond the scope
of the core program.

So I will need to supply tech support and also additional programming.

My question is "How many companies can 1 person reasonably support?"
I'm not looking for a firm figure, more an idea of what the heck I'm
getting myself into. Without a sale yet, I can't afford another
programmer. I'm wondering if there are "breakpoints" or milestones
where you need to expand and hire more people.

If you've been involved with or taken a software program from concept to
sales, I'd appreciate it if you'd share some knowledge of your experiences.

[salad]

John Mishefske wrote:

salad wrote:

My question is "How many companies can 1 person reasonably support?"

I'm not looking

for a firm figure, more an idea of what the heck I'm getting myself

into. Without a

sale yet, I can't afford another programmer. I'm wondering if there are
"breakpoints" or milestones where you need to expand and hire more

people.

In addition to Allen's suggestion I'd suggest your carefully track your
different versions. I'd start with a simple text file to explain what
changed in each version.

Then keep a copy of the .mdb (with full code - not a .MDE) for each
verson or consider
using a source control software like Microsoft's Visual SourceSafe.

Another software you might consider creating yourself is a Problem
Tracking app to keep track of support calls, resolution, etc.

They can serve as a Knowledge Base for future support requests, allow
you to prioritize multiple requests and do reports, etc.

Great points, John

[salad]

salad wrote:

I have an application written in MS-Access. It is a complete
application that manages the day-to-day operations of a business.

I would like to thank all of you that responded, and to those that make
any other future responses. All points that have been discussed are
very useful and I plan to implement them in my system if they don't
already exist.

Again, thanks.

[Larry Linson]

A business website need not be elaborate or complicated... one term for a
minimum website is a "brochure website." And, IMNSHO, having at least that
is essential for a business selling a computer-related product. The good
news is: if you get a copy of Microsoft Front Page, and can find an
appropriate Web Presence Provider, you can have such a website done and up
in a single afternoon. Then you'll have a brief wait while your URL is
proliferated to Domain Name Servers (DNS).

Quite a few WPPs include software to promote your site with the search
engines. A friend whose livelihood is from e-commerce told me that well over
95% of the hits on his site come from search engines, so learning how to
promote your site with the search engines (beyond the promotion from that
provided software) could be a very worthwhile investment, or contracting
with a website developer who specializes in that area.

Larry Linson
Microsoft Access MVP

"salad" <oi*@vinegar.comwrote in message
news:OG*******************@newsread1.news.pas.eart hlink.net...

Tom van Stiphout wrote:

>On Fri, 19 Jan 2007 17:47:40 GMT, salad <cu*****@george.comwrote:

Congrats Salad. A great achievement. I often think it's easy to get to
95% complete, but to get to 100%: golden.

Hi Tom:

Thanks for your support and encouragement.

I have to wonder if I am at 100%. I know there are more features my
application should offer. I have what I term a "Microsoft view" of my
program. If I wait forever to get the perfect program it will never
leave the door. If Microsoft waited for the perfect Windows, we might
never have seen version 3.1 when Windows started to gain acceptance.

>Do you have a website promoting this app? I think you were working on
a ski resort app? Some of my suggestions might be tailored better if
I knew more about your app.

No. The ski resort app is Albert Kallal's. If his app is like the
pictures on his website, he does beautiful work.

My program manages a commercial subcontractor's office. The contractor
can run one or many types of businesses; hvac, electrical, plumbing, etc
from it. The target audience is companies having 5 to 20 office staff
and however many tradesmen they require in the field with annual sales
between 1 million to 100 million.

You ask if I have a website. You've exposed a "major flaw". No I
don't. I do realize it is the electronic equivilent of a business card
thatt can reach more people. It is a top priority of mine.

>The topic of offering customer support is one you need to figure out
BEFORE you start selling. Clients have the right to know what they are
getting into. Perhaps it makes sense to offer first 30 days free
support, after that on T&M basis. They download and fax back a Support
Contract, and you bill against that. It may state that you can bill up
to 4 hours per issue, and if not resolved need to go to a Work Order
contract. Again, this differs widely depending on kind of application,
purchase price, etc.

Very interesting. I like the concept you described.

>>
-Tom.

>>>I have an application written in MS-Access. It is a complete application
that manages the day-to-day operations of a business.

The program is nearly ready to be used in other customer sites.

I am wondering if any of you have advice on supporting an application.
Since it has never had any outside exposure, what I don't want is to make
a bunch of sales and not be able to support the issues that arise.
I believe as kinks are worked out with a smaller set of companies, it can
be released to more companies. I simply don't want to have a bunch of
sales but no means to handle customer support problems.

I also know that companies that purchase it will make suggestions for
enhancements. Others may need some custom programming beyond the scope
of the core program.

So I will need to supply tech support and also additional programming.

My question is "How many companies can 1 person reasonably support?" I'm
not looking for a firm figure, more an idea of what the heck I'm getting
myself into. Without a sale yet, I can't afford another programmer. I'm
wondering if there are "breakpoints" or milestones where you need to
expand and hire more people.

If you've been involved with or taken a software program from concept to
sales, I'd appreciate it if you'd share some knowledge of your
experiences.

[David W. Fenton]

"Larry Linson" <bo*****@localhost.notwrote in
news:5hSsh.381$FN1.205@trnddc08:

A business website need not be elaborate or complicated... one
term for a minimum website is a "brochure website." And, IMNSHO,
having at least that is essential for a business selling a
computer-related product. The good news is: if you get a copy of
Microsoft Front Page, and can find an appropriate Web Presence
Provider, you can have such a website done and up in a single
afternoon. Then you'll have a brief wait while your URL is
proliferated to Domain Name Servers (DNS).

I would recommend doing *more* than just brochureware website, which
isn't likely to attract much business. I would recommend *not* going
with a Microsoft-based hosting service because there's much more
variety of open source add-ins than on the MS side. Well, I guess if
an MS site is running PHP, you've still got lots of choices, but I
don't know many Windows-based hosting providers that offer PHP (but
I admit I haven't looked lately) -- it's certainly not the optimal
platform.

Anyway, I'd suggest a way to really add value is to put up one of
the open source trouble ticket packages, so your customers could use
that to register problems, and then that would allow you to track
them and respond to them in an organized fashion.

Also, good "demo" pages are important, with lots of screenshots and
explanatory text.

You could also use a Wiki to build a knowledge base in the easiest
possible fashion.

And you might consider using a database to store your pages if you
can get a database that does full-text searches. MySQL does this
extremely well, and it's very easy to create a Google-like search
function with it.

Quite a few WPPs include software to promote your site with the
search engines. A friend whose livelihood is from e-commerce told
me that well over 95% of the hits on his site come from search
engines, so learning how to promote your site with the search
engines (beyond the promotion from that provided software) could
be a very worthwhile investment, or contracting with a website
developer who specializes in that area.

Are you sure the 95% wasn't the search engine spiders hitting the
site to index? A huge amount of the traffic on my website is search
engine spiders, to a shocking extent, it seems.

In any event, the key ways to get good search engine placement are:

1. have key words in the page titles.

2. have filenames and images that you want searchable have
non-random names, i.e., names that describe the content and that
will be search terms.

3. get links to it on the web pages of websites that are
high-ranking in Google. Links in newsgroups and blogs don't count
as high as links on actual web pages.

4. make as much of your content static as possible, and don't use
frames.

5. When using a database, use GET instead of POST for the URL links
within your pages (even if you use POST for driving your search
pages, for instance) so that the URLs can be seen and followed by
search engines. Keep the query strings as short a possible and try
to use meaningful words for your criteria strings to increase the
likelihood of the pages matching search criteria.

6. Don't submit to the search engines until you've made sure you've
got a pretty good site for search engines, because there's no
guarantee of exactly when the spiders will revisit your site in
order to get the improvements that will bring your site up in the
rankings.

7. it doesn't matter if you hold off on getting links from other
sites until after you've submitted your site to the search engines.
Once those links are up, they will automatically raise your Google
Rank.

8. don't worry too much about META keywords, as most of the search
engines ignore them. But don't neglect them, either. They can still
be useful in some contexts, and the METE description is what is
displayed in the search results by a lot of search engines.

9. use HTML navigation, not Flash or DHTML. HTML navigation can be a
great source of keyword embedding because you can use the links to
increase the number of keywords that are in your pages.

There's nothing magic about getting good search engine placement.
You just want to make sure you get as many of the terms people will
search for into the title and link and body texts of your pages. The
easiest way to do this is to do some test searches for criteria you
think would apply and then seeing what comes up, and which search
terms get you the best results. Then take those terms and make sure
your site uses them liberally, though don't try to overdue it --
repetition in one of the categories (i.e., title, text, links or
image names) doesn't help you to any significant degree (and can get
you in trouble because some search engines see it as trying to game
the rankings), but repeating a keyword in each of the categories on
each of many pages does help.

Last of all, the web page is likely to be your number one marketing
tool, so be sure to take some time with it and invest regular energy
in keeping it up. And don't just think of it as marketing to get
*new* clients -- supporting existing clients (as with the trouble
ticket system and Knowledge Base wiki) is also an aspect of ongoing
marketing because if your business is anything like any of the ones
I know of, many of your new customers will come from referrals.

Sounds like a lot of work, and particularly so if you don't already
have experience building websites.

But it's definitely worth it in my opinion.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Larry Linson]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote

I would recommend doing *more* than just
brochureware website, which isn't likely to
attract much business.

I agree, but getting the brochure site up will prevent your losing business
because "anybody who doesn't have a website shouldn't be in the computer
business", in the meanwhile.

I would recommend *not* going with a Microsoft-
based hosting service because there's much more
variety of open source add-ins than on the MS side.

Using Microsoft Front Page to create the website does not imply it has to
run/reside on a Windows server or Microsoft IIS. My friend with the
e-commerce site used Front Page to create his site, which runs on a
Linu*/Uni* server, and to which he has added pre-written scripts and written
some of his own.

. . .

Are you sure the 95% wasn't the search engine
spiders hitting the site to index?

That's not what I understood him to say. And, given that is his livelihood,
he is very knowledgeable and collects very good statistics. But, my
understanding of what he was talking about will definitely be on a lower
level than his knowlege of this subject.

But, it's easy for me to believe... a site selling reading accessories, book
covers, book caddies, etc. does not seem to be something you'd be likely to
just stumble onto.

Larry

[Darryl Kerkeslager]

"salad" <oi*@vinegar.comwrote

I have read your posts in this newsgroup for quite awhile, and have seen you
give many helpful responses. It is unfortunate that you will lose this
"reference" to some potential clients because you have not used your
complete name.

--
Darryl Kerkeslager

[salad]

Darryl Kerkeslager wrote:

>>"salad" <oi*@vinegar.comwrote

I have read your posts in this newsgroup for quite awhile, and have seen you
give many helpful responses. It is unfortunate that you will lose this
"reference" to some potential clients because you have not used your
complete name.

Hi Darryl:

Thank you for your comment regarding my responses.

Unfortunately I am an opinionated person, especially on politics. As
such, using my real name in newsgroups has given me some headaches in
the past. I wish we could all be "real" and get along, even if we
disagree on certain issues. Unfortunately, spammers will use newsgroups
to harvest email addresses. Malicious people can use them to attempt to
attack a person. And malicious people can stalk and harrass. I have
limited my spam and attacks by having a fake email address.

[Tim Marshall]

salad wrote:

My program manages a commercial subcontractor's office. The contractor
can run one or many types of businesses; hvac, electrical, plumbing, etc
from it.

I hope I can offer some sobering thoughts without being branded as a wet
blanket or a flame baiter. This is a long response and I hope you will
take the time to go through it and not get too angry with me.

I work in a field similar to what you describe above. It's called
computerized maintenance management systems, or "CMMS". The major
successful CMMSs out there, including the Oracle application I
administer and run, look nice, seem to do the data management jobs they
are designed for and impress a lot of people in the facilities/asset
management, industrial maintenance and hospital instrumentation fields.
However may of these database applications are houses of cards; if you
do something outside of the very narrow design parameters, the whole
thing falls down.

Much of the fragility in CMMS applications I have seen has been due to
poor decisions by designers in data structure and departures from
acceptable relational design principles (yes, Jet is not truly
relational, blah, blah, blah, but RD can and should be applied to Jet
applications). There are a whole host of different issues I've
encountered with several CMMS products, but relationship design, ie,
setting up of database level constraints to data is one of the major
headaches.

The major Oracle CMMS I work with has also won awards from a number of
our industry's professional associations. To many of my colleagues at
other facilities, the CMMS we use is the cat's meow. However, to other
colleagues who must delve deep into the structure of the CMMS to get
reports or discover trends, the picture below the pretty wrapping is
like taking the top fruit off the basket and finding rotten apples below.

A couple of things you should keep in mind.

1) There is no such thing as a "universal" contractor's office. In
other words, everyone will do things differently and as you develop your
customer base, your mind will boggle at the ways you never dreamed your
application will be used. 8)

2) In the beginning, you will get ideas for new reports and forms to do
with displaying data, trend analysis and so on. However, as time goes
by, you will start encountering clients who are not very imaginative and
will demand "improvements" to your application. Be very, very careful
when this happens. Make sure you look closely at how your appication
flows and how it is structured, because very often "new things" some
people demand can be accomodated if they can just think a little
differently. You will be surprised how many truly dumb people there are
out there who will insist on your re-inventing the wheel.

3) In keeping with 2, above, the customer is *NOT* always correct - if
you jump to every request, remember that sometimes these requests for
changes in the program can be outside of the scope of the intent of the
application. Make sure you have a road map and try and stick to it or
at least make sure your departures from the main route are simple day
trips that keep in view of your main road. EFFECTIVE DATA STRUCTURE
THAT MAKES SENSE AND KEEPS TO RD PRINCIPLES will always make such "day
trips" or any other enhancements so much easier for you.

4) You will *NEVER* successfully have a comprehensive reporting system
on the data your system tracks that will satsify *ALL* customers. You
will encounter intelligent clients with some knowledge of Access or
database design in general who will want to be able to use your data
structure to create their own reports and even tinker with or enter data
into your system en masse or in methods you never thought of (think
integration with financial systems). Once again, effective data
structure is the order of the day that will help your clients and help
your own sanity.

5) Point five touches on some of the points already mentioned.
Nowadays, when my organization contracts a construction company or
service company, the contractor is often required to provide electronic
data related to the project. I have been called on to visit a
contractor's site and look carefully at their information system(s) to
see how the data we want can be lifted from their system. Frequently,
we need to feed them information that needs to be brought into their
system (imported somehow).

Such integration could be for financial transations (the number one
reason), submitting completed equipment labelling (HVAC, plumbing,
electrical, industrial or building systems), work authorization records
and so on.

So, what I'm trying to say is that eventually, you *WILL* be judged on
your data structure and your system *WILL* have to undress itself for
examination or receipt of data from OUTSIDE of the application that is
built around your data structure. This is when systems that seem
excellent to lay folk (ie, non-IT people) can really start to look a bit
stark.

I guarantee you that people *WILL* eventually need to see/use your data
outside of your application. The measure of any database system is the
validity of its database structure and the robustness of its historical
information. All else, including the interface, is ultimately expendable.

In conclusion, I see lots of CMMS applications out there that have
garnered praise from their users, but when examined closely out of
necessity as described in points 4 and 5, above, look very ugly without
their clothes and make-up. It's important that the application's
insides hold up to the same level of scrutiny and appreciation as the
wrapping of its outward appearance.

With that in mind, I do hope that you have reconsidered your dislike of
relationships....
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

[salad]

Tim Marshall wrote:

salad wrote:

>My program manages a commercial subcontractor's office. The contractor
can run one or many types of businesses; hvac, electrical, plumbing, etc
from it.

I hope I can offer some sobering thoughts without being branded as a wet
blanket or a flame baiter. This is a long response and I hope you will
take the time to go through it and not get too angry with me.

Hi Tim:

I did take the time, and will reread again, to make sure I got your
points. I don't get angry with advice, I need to hear pros and cons.
Comments below.

I work in a field similar to what you describe above. It's called
computerized maintenance management systems, or "CMMS". The major
successful CMMSs out there, including the Oracle application I
administer and run, look nice, seem to do the data management jobs they
are designed for and impress a lot of people in the facilities/asset
management, industrial maintenance and hospital instrumentation fields.
However may of these database applications are houses of cards; if you
do something outside of the very narrow design parameters, the whole
thing falls down.

Much of the fragility in CMMS applications I have seen has been due to
poor decisions by designers in data structure and departures from
acceptable relational design principles (yes, Jet is not truly
relational, blah, blah, blah, but RD can and should be applied to Jet
applications). There are a whole host of different issues I've
encountered with several CMMS products, but relationship design, ie,
setting up of database level constraints to data is one of the major
headaches.

The major Oracle CMMS I work with has also won awards from a number of
our industry's professional associations. To many of my colleagues at
other facilities, the CMMS we use is the cat's meow. However, to other
colleagues who must delve deep into the structure of the CMMS to get
reports or discover trends, the picture below the pretty wrapping is
like taking the top fruit off the basket and finding rotten apples below.

A couple of things you should keep in mind.

1) There is no such thing as a "universal" contractor's office. In
other words, everyone will do things differently and as you develop your
customer base, your mind will boggle at the ways you never dreamed your
application will be used. 8)

Point well taken. I wrote this program with a person that has the
industry knowledge, I the tech knowledge. His sales and number of jobs
has increased dramatically using the program. But he was a person that
realized early on that in order to succeed or be one step ahead of the
pack he would commit himself to technology. He's talked to people in
the past, asked them how they do things. Enough companies to surprise
me don't have a computer system to help. Others do things with Excel.
I am sure some of these companies are bloated with extra workers
required just to put out fires. I view my application as nothing more
than a tool to run a business. It doesn't do accounting as there are
other suitable programs to do that. It doesn't do estimation for the
same reason. It doesn't guarantee success. It can't. We could give
the program to two companies. One company could be a roaring success,
the other go bankrupt in a year. I think sharp management and a
commitment to technology and the application will make the difference.

2) In the beginning, you will get ideas for new reports and forms to do
with displaying data, trend analysis and so on. However, as time goes
by, you will start encountering clients who are not very imaginative and
will demand "improvements" to your application. Be very, very careful
when this happens. Make sure you look closely at how your appication
flows and how it is structured, because very often "new things" some
people demand can be accomodated if they can just think a little
differently. You will be surprised how many truly dumb people there are
out there who will insist on your re-inventing the wheel.

The last 2 major applications I wrote are for the sharpest business men
I've met. In the first application, I used to have all sorts of ideas
for reports. "I can create a report to do this, do that, and this one
will be excellent." And I was met with "I'm glad for your enthusiasm
but I really don't need that. It doesn't meet my needs, I can see the
results elsewhere, etc." The end result is at both companies the report
requirements have been minimal. Sure there are some, rarely are they
printed. I've been at other offices where people couldn't attend
meeting unless they had lots and lots of reports to carry in, maybe a
box full, just to impress others. I can guarantee you that at best a
summary report would do them better.

I will attempt to keep, to the best of my ability, a firm control on
"report bloat".

3) In keeping with 2, above, the customer is *NOT* always correct - if
you jump to every request, remember that sometimes these requests for
changes in the program can be outside of the scope of the intent of the
application. Make sure you have a road map and try and stick to it or
at least make sure your departures from the main route are simple day
trips that keep in view of your main road. EFFECTIVE DATA STRUCTURE
THAT MAKES SENSE AND KEEPS TO RD PRINCIPLES will always make such "day
trips" or any other enhancements so much easier for you.

I agree. I have an idea of where I want this program to go. If I get
bogged down on inconsequentials I won't be able to get work done. I do
expect I will get some excellent suggestions, and they can/will be
implemented, but I want those suggestions to compliment the core
product, not have a custom app for each customer.

4) You will *NEVER* successfully have a comprehensive reporting system
on the data your system tracks that will satsify *ALL* customers. You
will encounter intelligent clients with some knowledge of Access or
database design in general who will want to be able to use your data
structure to create their own reports and even tinker with or enter data
into your system en masse or in methods you never thought of (think
integration with financial systems). Once again, effective data
structure is the order of the day that will help your clients and help
your own sanity.

Yes. I figure if they want to create their own reports they can. And
so my system will be exposed. I guess I need to make sure they know I
will not be responsible if they update tables outside of the
application. I can be responsible for my code, not theirs.

My target audience are not major GCs. They work on a diffent level and
have different requirements. Mine is the smaller commercial
subcontractors that actually do the work in the field. So I don't
expect too much tinkering by others.

5) Point five touches on some of the points already mentioned. Nowadays,
when my organization contracts a construction company or service
company, the contractor is often required to provide electronic data
related to the project. I have been called on to visit a contractor's
site and look carefully at their information system(s) to see how the
data we want can be lifted from their system. Frequently, we need to
feed them information that needs to be brought into their system
(imported somehow).

Such integration could be for financial transations (the number one
reason), submitting completed equipment labelling (HVAC, plumbing,
electrical, industrial or building systems), work authorization records
and so on.

So, what I'm trying to say is that eventually, you *WILL* be judged on
your data structure and your system *WILL* have to undress itself for
examination or receipt of data from OUTSIDE of the application that is
built around your data structure. This is when systems that seem
excellent to lay folk (ie, non-IT people) can really start to look a bit
stark.

Not worried about that much. Could I have done things better? Yes, in
a couple of places and I'll find out about others as time goes on and
they can be corrected or enhanced. But you do what you do with the
resources you have.

I guess what I'm saying is...I don't look at my application as an
enterprise application.

I guarantee you that people *WILL* eventually need to see/use your data
outside of your application. The measure of any database system is the
validity of its database structure and the robustness of its historical
information. All else, including the interface, is ultimately expendable.

I agree mostly. To the company, data is all important. To me,
forms/reports/tables/queries are the most important. All I do is
manipulate data so it is presentable to the customer. If the company
lost their data, they're SOL. If I lose my forms/reports, queries...the
same holds true.

In conclusion, I see lots of CMMS applications out there that have
garnered praise from their users, but when examined closely out of
necessity as described in points 4 and 5, above, look very ugly without
their clothes and make-up. It's important that the application's
insides hold up to the same level of scrutiny and appreciation as the
wrapping of its outward appearance.

It will.

With that in mind, I do hope that you have reconsidered your dislike of
relationships....

LOL. To anyone reading this, I guess you'd call that an inside joke.

Thanks, Tim.

[Allen Browne]

"salad" <oi*@vinegar.comreplied in message
news:6G******************@newsread3.news.pas.earth link.net...

>
Unfortunately I am an opinionated person, especially on politics...

Hey, salad, whatever your politics, do *not* wear a T-shirt that says George
Bush is a terrorist. They'll throw you off the plane:
http://abc.net.au/news/newsitems/200701/s1831559.htm

[David W. Fenton]

"Larry Linson" <bo*****@localhost.notwrote in
news:j3Xsh.3246$QE6.670@trnddc02:

"David W. Fenton" <XX*******@dfenton.com.invalidwrote

I would recommend doing *more* than just
brochureware website, which isn't likely to
attract much business.

I agree, but getting the brochure site up will prevent your losing
business because "anybody who doesn't have a website shouldn't be
in the computer business", in the meanwhile.

But it really needs to very quickly become more than that. I had a
client who spent a lot of time putting up a gorgeous brochure-ware
site, and got lots of feedback of the "but why can't I search your
inventory?" variety. We later put up searchable inventory and now
the problem is that people can't wrap their heads around the idea
that 100% of the inventory is not on their website.

So, you have to remember that people get very strange impressions
form a website, and may never come back if what they encounter is
inadequate.

I would say it's better to have something ugly and filled with
relevant information than to have an empty website with a pretty
design, so anyone tempted to use one of those canned templates
should probably think again.

I would recommend *not* going with a Microsoft-
based hosting service because there's much more
variety of open source add-ins than on the MS side.

Using Microsoft Front Page to create the website does not imply it
has to run/reside on a Windows server or Microsoft IIS. My friend
with the e-commerce site used Front Page to create his site, which
runs on a Linu*/Uni* server, and to which he has added pre-written
scripts and written some of his own.

Has Front Page improved its HTML? In the past it created very ugly
HTML that was often IE-specific, or that used overly complext
stylesheet formatting (way beyond what was needed). I have heard
that it's better, but by default, does it produce clean, simple
HTML?

I personally don't see the point of a program like Front Page. It's
not elaborate enough for managing large websites, and it does too
much for you, in an environment that's really quite simple (all the
HTML you need you can learn in one hour; all the stylesheet coding,
in two more).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

salad <oi*@vinegar.comwrote in
news:6G******************@newsread3.news.pas.earth link.net:

As
such, using my real name in newsgroups has given me some headaches
in the past. I wish we could all be "real" and get along, even if
we disagree on certain issues. Unfortunately, spammers will use
newsgroups to harvest email addresses. Malicious people can use
them to attempt to attack a person. And malicious people can
stalk and harrass. I have limited my spam and attacks by having a
fake email address.

I use my real name, post a human-readable email address that has
never received even one piece of spam, and am easily contacted by
anyone who wants to do so (either by unmunging the email address, or
by going to one of my web pages below).

So, there really isn't anything to fear in using your real name,
except if you aren't willing to stand by your words.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

salad <oi*@vinegar.comwrote in
news:6G******************@newsread3.news.pas.earth link.net:

Unfortunately I am an opinionated person, especially on politics.
As such, using my real name in newsgroups has given me some
headaches in the past. I wish we could all be "real" and get
along, even if we disagree on certain issues. Unfortunately,
spammers will use newsgroups to harvest email addresses.
Malicious people can use them to attempt to attack a person. And
malicious people can stalk and harrass. I have limited my spam
and attacks by having a fake email address.

BTW, I get more than half my Internet-based referrals from my Usenet
posts. That's not half my referrals (most are from Real-Life
people!), but it is definitely worth it to me to have me be a
recognizable contributor in these newsgroups.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertheriumwrote in
news:ep*********@coranto.ucs.mun.ca:

(yes, Jet is not truly
relational, blah, blah, blah, but RD can and should be applied to
Jet applications

Huh? Exactly how is Jet not truly relational? By what definition do
you say it's not? I can't see that *any* DBMS that I know of is
relational if Jet is not.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

salad <oi*@vinegar.comwrote in
news:6G******************@newsread3.news.pas.earth link.net:

Unfortunately I am an opinionated person, especially on politics. As
such, using my real name in newsgroups has given me some headaches in
the past. I wish we could all be "real" and get along, even if we
disagree on certain issues. Unfortunately, spammers will use
newsgroups to harvest email addresses. Malicious people can use them
to attempt to attack a person. And malicious people can stalk and
harrass. I have limited my spam and attacks by having a fake email
address.

I have never had any problem with this.

I guess it's because I am so meek.

[Tim Marshall]

David W. Fenton wrote:

Huh? Exactly how is Jet not truly relational? By what definition do
you say it's not? I can't see that *any* DBMS that I know of is
relational if Jet is not.

That was to keep the lurkers from cdt happy. There have been many
threads there, including spill overs to here (Google on Bob Badour, for
example, or Celko) on why Jet is not truly relational. Then again, some
of these are the same people that insist Oracle is not relational and
the only true rdbms is some obscure product I can't remember the name of.

And I can't remember exactly why Jet (or Oracle or MS SQL) does not
fully meet the 12 rules by EF Codd that make a database "truly"
relational and nor do I care.

I believe it's not so much the tool that makes an application relational
as it is the method by which the tool is used. You've probably had
experience with people who call themselves developers who put together
"applications" that are really just spreadsheets and anything but
relational.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[salad]

Allen Browne wrote:

"salad" <oi*@vinegar.comreplied in message
news:6G******************@newsread3.news.pas.earth link.net...

>>
Unfortunately I am an opinionated person, especially on politics...

Hey, salad, whatever your politics, do *not* wear a T-shirt that says
George Bush is a terrorist. They'll throw you off the plane:
http://abc.net.au/news/newsitems/200701/s1831559.htm

Hi Allen. I heard about that! It's is similar to parents that have
disruptive kids but do nothing to quell their obnoxiousness. In this
case, Qantas did some quelling.

The guy wanted to make a point. Similar to an evangelical, foisting his
opinion on others whether or not they want to hear it. Sometime you
just have to get along with others in order to get ahead. He got left
behind.

[Lyle Fairfield]

salad <oi*@vinegar.comwrote in news:chvth.14613$yx6.5280
@newsread2.news.pas.earthlink.net:

The guy wanted to make a point. Similar to an evangelical, foisting his
opinion on others whether or not they want to hear it.

What is the T-Shirt had just said, "George Bush lied about the weapons of
mass destruction and started an illegal war of aggression that has led to
the deaths of thousands of Americans and tens of thousands of Iraqis and
this war has not had, and has no prospect of having, any verifiable
ameliorating result!"?

Would anyone have wanted to hear (see) that?

Maybe some would have liked the opportunity to say, "Right, that's what
Jesus would have done!"?

[Darryl Kerkeslager]

"salad" <oi*@vinegar.comwrote

Hi Allen. I heard about that! It's is similar to parents that have
disruptive kids but do nothing to quell their obnoxiousness. In this
case, Qantas did some quelling.

Not at all similar. Parents can and should limit the free expression of
children. And those who would say that wearing a T-Shirt is disruptive to
an airplane are just the kind of reactionaries that he was trying to toy
with.

--
Darryl Kerkeslager

[Lyle Fairfield]

On Jan 23, 4:40 pm, salad <[e-mail]:

The guy wanted to make a point. Similar to an evangelical, foisting his
opinion on others whether or not they want to hear it.

What if the T-Shirt had just said, "George Bush lied about the weapons
of
mass destruction and started an illegal war of aggression that has led
to
the deaths of thousands of Americans and tens of thousands of Iraqis
and
this war has not had, and has no prospect of having, any verifiable
ameliorating result!"?

Would anyone have wanted to hear (see) that?

Maybe some would have liked the opportunity to say, "Right, that's what
Jesus would have done!"?

[Tom van Stiphout]

On Sun, 21 Jan 2007 18:55:42 GMT, salad <oi*@vinegar.comwrote:

When tailoring a support contract, you may want to follow to the
extend possible the mores of the audience. In this case, (sub-)
contractors are used to work fixed bid. They don't quite understand
how you would work T&M. Do you not stand behind your product? If your
app is broke, why should I pay for you to fix it? Isn't writing
software just like laying brick?
For this audience, you might want to go with a higher price, and then
follow up with some "free" support. Or give them several options to
choose from so at least they can make a trade-off decision.
Surely they all pay their accountant and their lawyer by the hour, so
you should not feel obligated, but it may help you to gain their
confidence if you work with business practices they use themselves.

We had a client we would not charge travel time to. He just couldn't
fathom that we would. Otherwise liked our rates just fine. You try to
accommodate.

Regards,

-Tom.

<clip>

>

>The topic of offering customer support is one you need to figure out
BEFORE you start selling. Clients have the right to know what they are
getting into. Perhaps it makes sense to offer first 30 days free
support, after that on T&M basis. They download and fax back a Support
Contract, and you bill against that. It may state that you can bill up
to 4 hours per issue, and if not resolved need to go to a Work Order
contract. Again, this differs widely depending on kind of application,
purchase price, etc.

Very interesting. I like the concept you described.

>>
-Tom.

<clip>

[salad]

Lyle Fairfield wrote:

On Jan 23, 4:40 pm, salad <[e-mail]:

>The guy wanted to make a point. Similar to an evangelical,
foisting his opinion on others whether or not they want to hear it.

What if the T-Shirt had just said, "George Bush lied about the
weapons of mass destruction and started an illegal war of aggression
that has led to the deaths of thousands of Americans and tens of
thousands of Iraqis and this war has not had, and has no prospect of
having, any verifiable ameliorating result!"?

Would anyone have wanted to hear (see) that?

By the time anyone read that much verbage they'd be bored.

>
Maybe some would have liked the opportunity to say, "Right, that's
what Jesus would have done!"?

I'll tell you who the real terrorists are on the planes I've flown on.
It's the pint sized person in front of me that absolutely needs to lean
back the seat in the sardine-like fuselage and crushing my knees.

[salad]

Darryl Kerkeslager wrote:

"salad" <oi*@vinegar.comwrote

>>Hi Allen. I heard about that! It's is similar to parents that have
disruptive kids but do nothing to quell their obnoxiousness. In this
case, Qantas did some quelling.

Not at all similar. Parents can and should limit the free expression of
children. And those who would say that wearing a T-Shirt is disruptive to
an airplane are just the kind of reactionaries that he was trying to toy
with.

Yes. He's still in Australia and the rest of the people on his flight
are at their destination. He really showed them who's boss.

[salad]

Tom van Stiphout wrote:

On Sun, 21 Jan 2007 18:55:42 GMT, salad <oi*@vinegar.comwrote:

When tailoring a support contract, you may want to follow to the
extend possible the mores of the audience. In this case, (sub-)
contractors are used to work fixed bid. They don't quite understand
how you would work T&M. Do you not stand behind your product? If your
app is broke, why should I pay for you to fix it? Isn't writing
software just like laying brick?
For this audience, you might want to go with a higher price, and then
follow up with some "free" support. Or give them several options to
choose from so at least they can make a trade-off decision.
Surely they all pay their accountant and their lawyer by the hour, so
you should not feel obligated, but it may help you to gain their
confidence if you work with business practices they use themselves.

We had a client we would not charge travel time to. He just couldn't
fathom that we would. Otherwise liked our rates just fine. You try to
accommodate.

Excellent points.

Are these types of contracts something I can write or is it best to have
a lawyer create them?

>
Regards,

-Tom.

<clip>

>>>The topic of offering customer support is one you need to figure out
BEFORE you start selling. Clients have the right to know what they are
getting into. Perhaps it makes sense to offer first 30 days free
support, after that on T&M basis. They download and fax back a Support
Contract, and you bill against that. It may state that you can bill up
to 4 hours per issue, and if not resolved need to go to a Work Order
contract. Again, this differs widely depending on kind of application,
purchase price, etc.

Very interesting. I like the concept you described.

>>>-Tom.

<clip>

[Tim Marshall]

salad wrote:

I'll tell you who the real terrorists are on the planes I've flown on.
It's the pint sized person in front of me that absolutely needs to lean
back the seat in the sardine-like fuselage and crushing my knees.

Hear hear!!!! Such ignorami need to be thrown out the plane at 30000
feet!!!!

OTOH, it really is the fault of the bloody airlines cramming us in
almost like those poor folks stuffed into slave ships a few hundred
years ago. The more they can increase your misery, the more money they
make.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Lyle Fairfield wrote:

I guess it's because I am so meek.

We all want a piece of the earth when you inherit it...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me