How To Create Your Own Successful And Profitable Affiliate Program

Most of the truly successful marketers have three competitive advantages :

• They run successful Affiliate Programs (Part 1)
• They own large Opt-In Lists and have large traffic (Part 2)
• They create their own products (Part 3)

Step #1 - Three Affiliate Program Opportunities

• Opportunity 1 - Using Own Products and Services Combining your own products with a successful Affiliate Program is almost a license to write your own checks.
• Opportunity 2 - Using Resell and Master Rights Products Surprisingly, as you will see in step 4, you can create and run an Affiliate Program even if you don't have your own products and services.
• Opportunity 3 - Substitute Joint Ventures All successful Affiliate Programs are joint ventures in miniature. Your affiliate partners require as much of your support and commitment as would any JV partners.

Step #2 - The Top Ten Features Of A Good Affiliate Program

1. It delivers consistent sales for Affiliates, by marketing products with high consumer benefits.
2. It operates on a Leveraged I'ncome Pay structure, which extends a number of levels deep.
3. It operates on a Residual I'ncome Pay structure giving Affiliates repeat I'ncome.
4. A good program has high quality marketing tools and incentives for the Affiliates.
5. It pays out big percentages of the sale to the Affiliates and it pays promptly
6. The administration function tracks and corrects affiliate issues quickly, and effectively.
7. A good program trains and supports Affiliates enthusiastically.
8. It offers Affiliates complimentary, high value, front and back end products for promotion.



Add caption

9. It handles all end customer care issues. 10) A good program constantly tests new ideas to support and strengthen ties with affiliates and end customers alike.

Step #3 - "Own Product Affiliate Program"
Most people join an Affiliate Program on the strength and reliability of its compensation plan.
* Compensation Structure Planning :

• Who can join the program Is it open to anyone or just selected, approved partners ?
• Downline matrix structure for Leveraged I'ncome How deep is the matrix of downline earnings for Leveraged I'ncome ?
• Residual I'ncome Payments Does the program pay Residual I'ncome, on repeat subscriptions for as long as the end customer renews ?
• Minimum Payment amounts, and deadlines. Policy on payments, returns and deductions from Affiliate payments must be clear from the beginning.
• Affiliate monitoring of the program Affiliates must be able to easily monitor referrals and earnings. Clear and accurate reports to Affiliates should be available online or sent by e-mail.

* Marketing Plans
Develop high quality graphical links that Affiliates can use on their own websites to point to your program. These include

• Web Templates and copy
• Banner Links
• Button Links
• Text Links

Write e-courses coaching your Affiliates on what works best in promoting your products and services.
Do not make the mistake of thinking that when they sign up the whole thing will run on autopilot.
* Legal Issues
Consult professional, qualified lawyers to help you draw up your program terms and conditions before you go to market. The upfront cost involved may save you greater expense in the future.
Step #4 - Resell and Master Rights Product Affiliate Programs
An Affiliate Program without your own products is possible, but use caution - it is less likely to be a huge earner, than one promoting your own stable of products.
Why would anyone join an Affiliate Program to promote a resell or master rights product, that they could buy and sell earning 100% of the profits ?
The answer is reduced effort, time and money.
An Affiliate Program for resell or master rights products saves the affiliate from having to buy, process, add value to and give customer service to the resell rights product.
It becomes an easy I'ncome stream that people may want to join.
The trick in this situation is to

• Spot a product with selling potential, that is relatively scarce and has not been over marketed.
• Create the Affiliate Program where the product owner has failed or is incapable of seeing the market opportunity.

Remember caution - Do not spend huge sums setting up this type of program because the "Return on Investment" is likely to be low.
Step #5 - Mini Joint Venture
JV partners bring "something with them, to the party" - This might be funding, a huge opt-in list, a product or service, or ideas.
Affiliate partners on the other hand, bring only their desire to promote your products and services.
However, the practical day to day administration of the two types of programs is very similar.
For instance:

• You should coach affiliates and JV partners in the best way to market the products.
• You must listen to their issues and deal with them effectively and efficiently
• You must make sure they are happy with the program arrangements, in order that they promote it strongly and join up for future promotions.

JV's and Affiliate programs are different, but only in small details. Treat them with similar care.
Step #6 - Affiliate Program Automation
Quality tools are indispensable for Affiliate Program Automation

• Affiliate Scripts - These are commercially available scripts that allow you to set up programs of various complexity in terms of compensation plans, account management, and program administration.
• Administration Tools - These allow you to see in detail which Affiliates are performing and deserving of more of your effort, time and attention and which ones are not and can therefore be dropped from the program.
• Sequential Autoresponder - Use this to coach and train your Affiliates by sending them regular e-mail.
• VoIP Communicators - These allow you to hold Cheap Live training and support seminars where your Affiliates can virtually attend, see, hear and talk to one another from across the Globe without the need for expensive travel or phone costs.
• Payment Processor - This is the facility by which your Affiliate partners will be paid.
• Product Fulfillment - A successful program will generate many sales and the fulfillment process must be able to cater for the heavy workload.
• Customer Care - The extra sales means that you may need to handle higher levels of end customer issues including returns.

What is a Good Program Spec?

Since the industry is preoccupied with producing software faster
(and not necessarily better), let's stop and consider how we typically approach programming and allow me to put my spin on it. There are fundamentally three aspects to any program development effort: defining the program's specifications, designing and writing the program itself, and testing it. The software engineering gurus in the industry are primarily concerned with the internal design of the program, but there
is now a raft of consultants trying to determine the best way to
approach the program externally. Why? Because there is now many ways for producing software than just writing source code using a common text editor; e.g., visual programming aids/prototyping tools, workbenches, 4GL's, program generators, etc. Such tools take the need for writing precise source code out of the hands of the programmers and allows them to concentrate on basic screen and report layout. They are excellent tools for most programming assignments, but they cannot do 100% of all of the programming for all applications. We still require
professional software developers with an intimate knowledge of programming languages and design techniques. Regardless if we write a program by hand, or use some sort of interpreter/generator, we still need to provide the programmer with precise specifications in order to perform their work.
Seldom do companies make use of a uniform approach for producing program specifications. It is not uncommon for programmers to receive specs in obscure ways, such as a memo from an end-user (the back of a cocktail napkin is my personal favorite). Rarely are specifications given in a consistent manner that can be evaluated for completeness. A standard approach would improve productivity and communications within the programming staff alone.
What should a good program spec include? Actually, its not too
difficult to figure out...
ELEMENTS OF A PROGRAM SPECIFICATION
Each program should be defined in terms of:

1. Input Descriptions (to collect data or request an output) - be it implemented by a GUI, command line interface, verbal, optical, or through some other screen interface. All inputs should include: a. Name, alternate ID, program label, description. b. Defined layout and examples. c. Input transaction specifications, including default values and editing rules for data to be collected. d. Messages; e.g., data validation, and general processing. e. Panels (for screens). f. Relationship of inputs to outputs.
2. Output Descriptions (to retrieve data) - be it implemented by a GUI, printed report, audio/video, or through some other screen interface. All outputs should include: a. Name, alternate ID, program label, description. b. Defined layout and examples. c. Panels (for screens), maps (for reports). d. Messages; e.g., general processing and program specific information/warning/error messages.
3. Data Structure Descriptions (data bases, files, records, and data elements). NOTE: Programmers should NOT be in the business of designing data bases as they will only do what is convenient for their application, not others (thereby missing the opportunity for a company to share and re-use data). Physical files should be defined by Data Base Administrators. a. All data structures should include: Name, alternate ID, program label, description. They should also include... b. Data Bases - organization, key(s), labels, volume/size, backup requirements, internal structure. c. Files (both primary and working) - organization, key(s), labels, volume/size, backup requirements, internal structure, file-to-file relationships. d. Records - form, length, key(s), contents, record-to-record relationships. e. Data Elements - class, justification, fill character, void state, mode, picture, label, size, precision, scale, validation rules. If generated data, rules for calculation. If group data, rules for assignment.
4. Program Description: a. Name, alternate ID, program label, description. b. Characteristics: Required processing speed, memory requirements. c. Dependencies to other programs externally (e.g., batch job stream). d. Dependencies to modules internally (e.g., DLLs, subroutines, etc.) e. Functions to be performed with Inputs, Outputs, and Data Structures (create/update/reference). f. Special processing rules (logic for processing) g. Command language required to execute the program (e.g., command files, JCL, etc.) h. Physical environment where program will be executed. i. Test Plan and how to assemble test data. j. Method of implementation - programming language(s) to be used, design techniques to be observed, tools to be used.

In-house software engineering standards complements any program specification (and should provide guidelines for writing the specification). Such standards define "best practices" for design and conventions to be observed during programming. As an aside, the objective of software engineering should be: Maintainability (easy to correct and update), Performance, Design Correctness (proof), International support (to accommodate languages and cultures), Integration (sharing and re-using code), and Portability (platform independence).
Between the programming spec as listed above and a good set of programming standards, it becomes rather easy to implement any program, be it by hand or through the use of a generator. As a matter of policy, specifications should be written under the assumption that a program generator will be used. This forces us to be more precise in our specifications.
OKAY, SO HOW DO WE GET THERE?
When it comes to assembling a program spec, I am of the philosophy that "You eat elephants one spoonful at a time." It is difficult to gather the specs for a single program in one fell swoop. Plus, when we consider most development projects today involve more than one program, the problem is further complicated. For major development efforts, I am of the opinion that "layers" of documentation are required. For example, under "PRIDE-ISEM, we view a system as a collection of sub-systems (business processes), implemented by procedures (administrative and computer), administrative procedures consist of operational steps (tasks), and computer procedures consist of programs (which can be sub-divided into modules if so desired).
Basically, "PRIDE" views a system as a product that can be engineered and manufactured like any other product. From this viewpoint, we can make use of other engineering techniques, such as a top-down blueprinting approach to documentation where levels of abstraction define the different levels in the system hierarchy. For example, the Phase 1 Information Requirements contained in the "System Study & Evaluation Manual" define what system(s) are needed (either new or existing systems requiring modification); the Phase 2 "System Design Manual" includes specifies the sub-systems; the Phase 3 "Sub-System Design Manual" specifies the procedures
in the business process; the Phase 4-I "Administrative Procedure Manual" specifies the operational steps, and; the Phase 4-II "Computer Run Book" specifies the programs. This blueprinting approach allows us to progressively refine our specifications until we reach the bottom of the product structure. In other words, it is not necessary to define everything about an Input, Output, File, or Data Element all at once, but rather to initially identify the need for them, then progressively refine the details until we are ready to program.
This approach to documentation is sometimes referred to as "step-wise refinement" whereby the design of a structure, such as a product or building, is refined over various levels of abstraction. Only when we have completed these architectural
designs can the product move to manufacturing/building. Imagine trying to build an automobile or skyscraper without such a technique. It would be virtually impossible. Why should systems be any different? In order for this approach to
work, you must accept the concepts: a system is a product; that there are various levels of abstraction to it, and; there are standards for documenting each level. This is considerably different than a "forms driven" approach to development;
e.g., fill out forms in a regimented sequence without any thought in regard to the design of the system. Instead, documentation should be a natural by-product of the design process.
This also makes a clear delineation in terms of "types" of specifications; for example "information requirements" and "programming specs" are miles apart in terms of content and purpose. Whereas the former is a specification regarding the business needs of the user, the latter is a technical specification
for the programmer to implement.
This blueprinting approach also highlights the need for basic systems work in the earlier phases of design, with the programmers being the beneficiaries of more precise specifications (as opposed to vague concepts), thereby
simplifying their job.
CONCLUSION
So, what is a good program spec? Anything that eliminates the guesswork for the programmer. Consider this: if the up-front system design work was done right, programming should be less than 15% of the entire development process. Then why does it currently command 85% of our overall time (and financial resources)? Primarily because we have shifted our focus and no longer believe we are being productive unless we are
programming. After all, programming is perhaps the most visible evidence of our work effort; system design is less tangible.
Let me illustrate, back in 1976 I took an entry level COBOL training course from IBM in Cincinnati. Our class was divided into teams of three people and each team was given problems to solve. When we received an assignment, the other two programmers in my team immediately started to write code,
key their entries (Yes, we used keypunch equipment back then), then compiled the program. Inevitably, there were errors and they would go back-and-forth correcting errors until they finally got it right. As for me, when I got an assignment, I would pull out a plastic template and paper, and work out the logic of the program before writing the code. I would then key and compile, and would always complete the assignment before my partners. Curiosity got the better of me and I asked them, "Why do you do it that way?" They contended this was how they were expected to work by their superiors; that they weren't being productive unless they were producing code. I countered that even though they were faster at producing code, I was still beating them every time, simply because I was thinking the problem through.