One of the most interesting pieces to the new product will be deciding how to offer support for our clients using it. We’ve put together a list of different user types (personas) to try to discover what types of support they would prefer.

There are many choices of different support methods that we could consider including. Examples would be traditional methods, such as e-mail support, telephone support and an FAQ page. Others might be more advanced, like in-product wizards, a searchable knowledge base or live chat capabilities.

The challenge for this is pretty evident. Find a way to have a useful support system that meets every possible support need, for every possible type of client. We have to ask ourselves, “How would the client want to discover the solution to their problem?”

The support mechanisms have to be easy to use, but offer complete and fast solutions. We want to solve the client’s problem while educating them at the same time. Support will need to offer a range of tools so that we can accommodate both those who like to figure things out on their own, and those who require a little more hand holding.

The mission is to keep things both simple and powerful, so we will strive to meet that goal with Support tools to match.

If anyone has any comments or ideas to add, feel free!

Tara Hunt of photo facial recognition startup Riya has some great advice for marketing for startups.  There are some points here that definitely speak to what we’re trying to do here, and what we’ll need to continue to do as we launch this “startup project”.  Give it a read.

WeÂ’’re trying to figure out what people want in terms of a sign-up process. One of the main benefits of RMX Direct will be the ability to build relationships with many different networks that use the Yield Manager platform. Web publishers have completed many sign-up forms in order to join a network or to post on a site. Recall the last time you applied to a network or service. What turned you off?

Forms vary in length, and some that we’Â’ve seen are entirely too long. Many people with websites also have full-time jobs. For them, time is a limited and precious thing. Filling out a lengthy form just to be denied does not sound appealing. In your experience, do publishers have sign-up preferences? Before we build the sign-up screen, we want as much feedback as possible about what publishers want. Questions on our minds include:

Do publishers like to share information such as their siteÂ’’s unique visitors or monthly impressions?

Is it more time effective to provide billing information (payable name and billing address) during the initial sign-up or instead during their first account login?

In terms of information provided to the publisher at sign-up, do publishers want to know payment terms and rev share up front or are they more interested in signing up and receiving details in an acceptance letter?

What Publishers Want … Â…sounds like the title of a Mel Gibson movie. We need your feedback much more than the world needs another Gibson chick flick. What do publishers want from a sign-up process?

We’re still trying to find a name for our product, and it’s a bit of a struggle.  I think one strategy we can use to help us at least head in the right direction is to determine what type of name we need.  Here are the options

• Generic but Descriptive - This would be a name that just describes what it is, such as “Ad Manager”, “Network Manager”,  “Network Consolidator”, etc.
• Yield Manager Name - To be consistent with our other main Yield Manager products, we could choose a name that either uses “Yield” or “Manager”.  This also could play off it being a simpler or easier version of Yield Manager for Publishers.  So it could be something like “Easy Yield Manager”, “Yield Manager Lite”, or something along those lines.  I tend to personally not like calling it something that makes it feel like a dummies version.
• Creative YM Name - This would be like our code name for the product like sYMple.  The “YM” is from Yield Manager, and there are various words that work in this idea.  “Optymal”, “Symple”, “Pryme”, etc.  There are problems with some of these being trademarked.
• Nonsense Word - This would be your Google or Yahoo type name that really doesn’t mean anything.  The possibilities here are endless.
• Advertising Industry Name - Go ahead and put “Ad” or “Click” with another word.  I’d prefer to stay away from a name of this type.

Any thoughts on what type of name we should go with?

The design of API is to use numeric IDs everywhere (not billing codes), for all things like country, region etc. Orherwise if API operates with string names, it assumes that the names are “standard” (for example “USA” vs “United States” vs “United States of America”). The v 1 will provide a flat file to map names to IDs as part of documentation. Later on we’ll develop a service that allows to lookup dynamically.