Upselling (or Up-selling, or Upsell) is a simple way to increase your average revenue per customer. It’s easy and effective. At the time of purchase simply offer your customers extra options or a more valuable deal.
This is just a short list of what you can offer to your customers besides your main software product:
Nevertheless, try to choose upsell options wisely in order not to turn your order page into a pile of junk and scam-like offers.
Also don’t force your customers into up-selling options as it won’t be appreciated.
This is not my habit to copy posts from other sources but this time I couldn’t resist. The info below seems to be very useful for any ISV and everyone who deals with sales copy writing.
Here are 7 ways to use numbers to increase the selling power of your next promotion:
Original source: www.technicalcommunicationcenter.com
Author: Bob Bly
Numbers gain attention, arouse curiosity, and add credibility to product claims.
1 – Make percentages look larger.
Taking percentages out to the second decimal place makes them look bigger, because there are 2 extra digits.
Good: 230%
Better: 230.47%
2 – The magic of 2,000.
When you have 2,000 or more of something, you can legitimately say you have “thousands.”
Good: 2,100 subscribers.
Better: thousands of subscribers.
Thousands sounds better because it could be anything from 2,000
to 999,999.
3 – Almost/over.
When you want to make a number bigger than it is, compare it to the nearest round number using the words “almost” or “over/more than.”
Good: 17 years of experience.
Better: almost 20 years of experience.
Good: 21 years of experience.
Better: more than 20 years of experience.
4 – Use credible numbers.
The rule of thumb is to use the round number when you are talking theoretically, and the odd number when you are presenting hard data.
Theoretical: “Make $100,000 as a professional massage therapist.”
Hard data: “Last year Henry earned $100,287.45 in his massage therapy practice.”
5 – Do not write numbers as words. Use numerals.
Good: Seven ways to reduce PC down-time.
Better: 7 ways to reduce PC down-time.
6 – Write fractions as whole numbers rather than percentages.
Good: 30% of wine bottles have cork rot.
Better: 3 out of 10 wine bottles have cork rot.
7 – Use the largest unit of measure possible to make a number sound big.
Good: 25 years of service.
Better: A quarter of a century of service.
When we think about affiliates we usually consider them as webmasters or newsletter owners who put affiliate “Buy Now” links on their websites or plug them into e-mail newsletters.
The on-line affiliates can reach only a fraction of potential users of your software products. There are many prospects who cannot be reached by on-line marketers because they spend just a little time on the Web or don’t trust on-line sales copies.
In the same time, there are many people who could recommend your products offline: on conferences, presentations, user group meetings, etc.
But long affiliate links with personal code are useless in this case because they are hard to remember. The prospects will hardly follow the affiliate link. They will likely go to main product URL and will order from there. Thus the affiliate won’t receive the commission for that lead. This is bad.
If you use Plimus.com for managing your affiliate program then there is a way to help your affiliates to sell offline.
Setup a discount coupon and assign it to an affiliate. The affiliate may give that special coupon code to prospects and they will apply it on your website when ordering the product.
There are two obvious benefits:
Also, on Plimus you can setup the coupon to completely absorb the discount value and it won’t be deducted from affiliate commission. This will also inspire your affiliates.
I hope this idea will help you make you affiliate network more profitable.
If you’d like to sell our help authoring tool Dr.Explain offline by using this approach and to get paid then join our affiliate program and request for your personal coupon.
This is just a few facts from the history of our product, Dr.Explain. I feel a bit nostalgic for that time of big dreams and hopes. Now it’s just a business.
I think these facts could inspire the new rising startups.
Could you disclose something interesting from your product’s history?
If you have ever released an update of your software product then you likely faced the problem of notifying your existing customers about the update. In this post I’d like to give a simple yet very important advice how to notify your customers properly.
Releasing the upgrade is a very important task. After several months of development and testing you may get tired and miss some important details on the final stage – distribution and official announcement.
Here is a list of the most common issues that may happen during the release and reduce the effectiveness of your announcement:
You must detect the possible unexpected problems and fix them before all your customers have received the announcement message. The trick is easy – send your announcement by portions.
The first pilot portion of your mailing must be sent just to a few customers, about of 100-150 contacts. Those users must be as different as possible: from different countries, with different operating systems, corporate and home users, old clients and newbies, etc… Usually the first mailing to such small yet contrasting group of users allows detecting the possible issues in your release or notification. In the same time you won’t be overwhelmed with support request from thousands of disappointed people.
Wait for about a day for possible problem reports and initial feedback. If everything is OK then you may send another portion of mailings to about 5-10% of your customers. Wait for another day. If everything is OK this time then continue sending your announcement by portions of 15-20% with pauses of several hours between each session.
This simple approach will allow you to:
If you are serious about writing a good documentation for your software either with our help authoring tool – Dr.Explain, or with another one, then you definitely should subscribe to the following blogs on technical writing, software help and documentation authoring. To be honest I even included links to blogs of our direct competitors.
I say “Thank you!” to our fellow customer and partner Craig Prichard, a technical communicator, who gave me many new links for this list.
Cherryleaf Technical Authors’ Blog
A blog site from Cherryleaf, a technical communication UK company by Ellis Pratt. Ellis regularly gives comprehensive review of the industry news as well as practical articles on technical writing.
Harry Miller’s Technical Writing Blog
Harry’s blog contains not only written content about documentation, technical writing, and technical editing, but many podcasts as well.
HelpStuff Blog
A famous blog by Char James-Tanny (JTF Associates) about all aspects of helping software end-users.
I Came, I Saw, I Learned…
A blog by Kevin A. Siegel who has written more than 100 step-by-step computer training books and has been a software trainer for more than 15 years.
E-Learning, Moodle, Technical Writing, and Training
William Rice is an educator, trainer, and writer. Most of his posts are either articles or tutorials about his professional pursuits: e-learning, Moodle, technical writing, and training.
I’d Rather Be Writing
A blog about technical communication by Tom Johnson. Tom covers many topics from any kind of user guides and design documentation, to audiovisual tutorials and drawings, or other explanatory content that is of a technical nature.
Gryphon Mountain Journals
Ben Minson is a technical communicator. He creates documentation and training on applications that are produced in-house. Writing is what Ben does. He thinks that when he die, the mortician will have to pry the keyboard loose from his cold, dead clutches.
OneManWrites
That OneMan is Gordon McLean, a technical author with a passion for good communicative information products. Another Gordon’s passion is web design. In his posts Gordon keeps balance between practical issues and theory of technical writing.
Charles Jeter Blog
Charles writes mainly about technical communication aspects in Web 2.0 world, e.g. work-flow collaboration and e-learning.
User Assistance
An exploration of issues pertaining to online help by Michael Hughes, PhD. As you can see from the blog’s title Michael focuses mainly on embedded user assistance, usability issues and user behaviour.
Just Write Click
A blog by Anne Gentle, a senior technical writer who is blogging about technical writing, information architecture, topic authoring, social media, and other communication technologies.
Mike’s Web Log
In this blog Mike Pope, a technical writer, covers various topics from writing and editing, to teaching and movies, and to politics and musics.
monkeyPi
An interesting point of view on usability, visual & technical communication, and software design.
Great Documents
In this blog Keith Johnson, a technical writing & software documentation specialist, gives many useful tips not only about documentation writing but on successful blogging, SEO, and social networking.
Scott on Writing
Scott Mitchell is a freelance writer, trainer, and consultant. In his technology-related blog Scott talks about technical writing, technology, and ASP.NET
Sharon’s MadCap Blog and Mike’s MadCap Blog
The two blogs by Sharon Burton and Mike Hamilton from MadCap Software. It’s always interesting to know what your competitors do
Technically Speaking
Paul Pehrson is another technical writer who blogs about various aspects of his job: writing tools, software, grammar, technologies and other important topics.
The Content Wrangler
A great resource for everyone who deals with technical content writing, editing, publishing and delivering. There is a lot of practical articles and industry news.
Communications from DMN
Aaron Davis and Scott Nesbitt, two experienced technical communicators, post their ideas and opinions, as well as links to information that they find interesting and hope that you will too. As you will see from their posts, Aaron and Scott have a wide range of interests when it comes to technical communications.
HelpScribe
A pretty young but very interesting blog by Craig Haiss, a technical writer. Craig started his blog to share his professional knowledge with colleagues. That’s great!
Usable Help
A blog of Gordon Meyer, an interaction and instructional designer. Gordon is a professional author and speaker on the topics of help system design. His posts on software help, usability and testing are always very practical and focused.
Of course there are many other blogs on help authoring, technical writing, e-learning and technical communication. I listed only the most popular and active, i.e. with new posts in 2008. If you know other good blogs on these topics, please add them through comments. Thank you!
This post is a brief digest of most important events in our company for the past several weeks. In order to keep this blog mostly self-hype free I summarized all our news in a single short post.
Dr.Explain 3.1 release
We’ve recently released the new version of our software help-authoring tool, Dr.Explain 3.1.
This update is a great step in the product history. Until the version 3.1, many software developers and vendors have been using the Dr.Explain to document their Windows software, HTML pages, or Flash (SWF) applications.
Now, the Dr.Explain 3.1 enters the Java world. Java developers can benefit from the same technology, and automatically generate professional documentation for their Java applications made with Swing components.
Besides the support of Java applications, Dr.Explain 3.1 brings more new functions that will help software vendors produce astonishing documentation even faster. The customizable capturing scenarios allow to precisely specify which window element or HTML tag to analyze or to skip, how to handle its child elements, and how to name and to annotate it. Other gems of the new version are new graphical effects and image rendering technology. All screenshot images, callout lines, text label fonts, shadow and blending effects are drawn with high precision which leaves no chance for fuzzy edges, making documentation illustrations look clean, realistic and nice (beautifully clear).
More info: www.drexplain.com
New Dr.Explain forum
If you have questions, concerns or ideas regarding the Dr.Explain software and if you want to discuss it with other users or with Dr.Explain team publicly then I invite you to join our forum at: http://www.drexplain.com/forum
This week I, Dennis Zhuravlev (a.k.a. Dennis Crane), the CEO of Indigo Byte Systems, will attend the ISDEF 2008 conference in Moscow, Russia. If you attend this event also then I will be happy to meet you there.
There are lots of possible reasons to meet me there:
If you’re going to ISDEF, please let me know via e-mail or comment. I’m looking forward to meet you on ISDEF 2008.
If you decide to split your software product into several editions with different settings then you will likely wonder how to name them. Naming software editions depends upon what do you offer and what do you limit in each edition. There are several common approaches in building editions:
Here is a list of common edition names. The hints in parenthesis designate which of the approaches each name suits better.
Level 1
Junior (F)
Beginner (F)
Student (U)
Educational (U)
Light (F)
Lite (F)
Bronze (F,U,N)
Empower (F,U,N)
Starter (F)
Level 2
Standard (F,U,N)
Regular (F,U,N)
Intermediate (F,U,N)
Personal (U,N)
Home (U,N)
Silver (F,U,N)
Level 3
Advanced (F,U)
Professional (F,U)
Business (F,U,N)
Commercial (F,U)
SOHO /Small Office or Home Office/ (F,U,N)
Company (F,U,N)
Gold (F,U,N)
Mega (F,U,N)
Level 4
Deluxe (F,U,N)
Architect (F,U,N)
Site (F,U,N)
Enterprise (F,U,N)
Platinum (F,U,N)
Premium (F,U,N)
Exclusive (F,U,N)
Ultimate (F,U,N)
This list gives you an idea how to get started with your own software editions. Combine names from different levels to build your own successful product line.
If you know more naming examples then post them as comments please.
[Editor's Note: This post comes from Craig Prichard, a Technical Communicator. He has provided beta and usability testing for Dr.Explain, wrote the sample project (GUI) that is distributed with the latest version, and is the "voice" of this video.]
Dennis has generously provided me enough rope to hang myself. I hope to make a hammock and just hang out a little instead. We’ll see.
This post comes from the perspective of a Technical Communicator. 25+ years of software development, business analysis, beta and usability testing, and technical communication in its many forms have confirmed to me that these principles are universal to anyone faced with creative problem solving.
Technical Communication (TC) has many facets but at the core of every effort, deliverable, meeting or other task is the challenge to solve a problem. Whether the task is to write or otherwise communicate an explanation of how to do or use something, convince a client to use your services, resolve an interpersonal conflict between yourself and someone else or between others, or determine the best content delivery medium for a specific scenario, you will always have two challenges: clearly identifying the problem and producing a satisfactory solution to it. Sometimes the problem is cognitive, e.g. learning and explaining. Sometimes the problem is emotional, e.g. conflict resolution. Sometimes the problem is spiritual, e.g. conflict of interest. Sometimes the problem is physical, e.g. constrained by available resources. And most of the time the problem is a lovely blending of components that taxes body, soul, and spirit. The remainder of this article will be based on two (1) assumptions (I know what they say about “assume”, thank you):
1. You have identified the problem. This would make a good topic for another post.
2. You believe a satisfactory solution can be achieved. I believe there is an achievable satisfactory solution to every problem, which would make good topic for another post.
How do I get from point #1 to the end of point #2? I don’t have any idea how to solve the problem. Or, more likely, I have some idea of how to solve the problem but there are pieces missing that need to be filled in.
First, let’s modify our taxonomy. Do not refer to this as a “problem” any longer. It may seem trite or contrived to call it a “challenge” or “opportunity” when the terms are synonymous. But actually they are not. Would you refer to training for a 10 KM run as a “problem” or a “challenge”? It’s a matter of choice. You choose to participate in a 10 KM run and know that without training first, your results will likely be less than satisfactory. You refer to the effort with a term that, in your mind, is less negative than “problem”. For motivation sake you choose a term that encourages rather than discourages. For motivation sake you need to think of the TC effort now facing you in terms that do not discourage. One reason you might be having difficulty crafting a solution to the challenge is that your mindset regarding it is unnecessarily negative. Turning the corner from “Woe is me” to “I shall overcome” (thank you Martin Luther King Jr.) can help the creative juices to flow again.
Challenge Types and Suggestions:
My first point is about perspective; having a perspective about the challenge that doesn’t drain you of confidence to overcome it. The next point is also about perspective; looking at the opportunity to see what it is and what it isn’t. When I need to produce a deliverable that similar to numerous deliverables I have produced in the past, there is little need for creativity beyond the content itself. It’s when the deliverable is different in some way that the need for creativity arises. Understanding what is different is key to focusing your creativity productively. This is “thinking outside the box” and critically important in sparking creativity:
Challenge Types and Suggestions:
Next, at a more practical level, am I as prepared as I can be to be creative right now?
Here is a recap of ways to help the creative juices flow:
There is no new research or startling information here. You know all this. But I hope that by putting it together as I have done, you will have greater ease in diving into, uh-oh, what’s about to walk into your office…
As always, your feedback is appreciated.
Craig Prichard
Technical Communicator
craig dot prichard AT gmail dot com
http://members.shaw.ca/craig.prichard
This post is a short list of basic rules for those who has recently signed up for Google AdWords account and doesn’t want to waste much money for learning curve.
Please consider the advice below with “for the first time” remark.
Focus on high quality traffic first
Differentiate your ads
Improve your campaigns
Start little and look what happens. Once you feel that you have full control and understanding of how Google AdWords works then you may turn on other countries, languages, campaigns, and ads.
Google AdWords is not a rocket science but it requires your attention and constant control to get maximum ROI out of your budget when you’re getting started.