ePublisher includes tools to create designs (Pro), stamp them out (Express), and automate builds (AutoMap).  The thing is, AutoMap, as it exists today, is not always the right fit for our users.  It offers more capability than some folks will ever leverage.  For them, AutoMap is simply too expensive.  Others make extensive use of AutoMap’s command-line capabilities to maximize their use of the product.  In their eyes, AutoMap is huge bargain.

I’d like to figure out how we can better address both types of customers in the future.  Doing so might mean splitting AutoMap into distinct products.  Let’s see if we can define some product offerings that better fit everyone’s needs.

I’ll start off with a list of functions AutoMap presently provides:

• Scheduled generation
• On-demand generation for scripting integration
• CMS integration capabilities
• Pre/Post generate actions (useful for source-control integration)
• Notifications (E-mail)

Our Sales team tells me they have a further need to distinguish between:

• AutoMap on a server
• AutoMap on a client

Here, the server case represents AutoMap being used as a centralized resource by a number of users.  The client case represents customers looking to keep their Express projects up-to-date or integrating AutoMap into their nightly build processes.  Obviously, we’d like to find a way to provide a client-side user with a reasonably priced offering.

Finally, there are always the things that AutoMap doesn’t quite do yet, such as support for job queuing.  Job queuing would ensure a system could not be overwhelmed by multiple, simultaneous conversion requests.

Tell me now.  If WebWorks were to build one or more products based upon the AutoMap of today, what combination of functions would you need for success in your organization?