…do you have other recommendations for a mid sized company like my clients that would enable us to grow into the potential we have as a direct to consumer player? A tall order, I know, but love your thoughts.

While I am not a marketing expert, I do feel comfortable speaking from the standpoint of tools and usability. There needs to be a new emphasis on lowering the operational footprint of the tools we provide for clients. After all, the building that a store resides in shouldn’t require the level of attention that marketing, products and customers demand. As a developer, I believe that is the philosophy that we need to emphasize moving forward – the tool needs to be built with a clear emphasis on fitting into existing business processes as much as possible instead of carelessly redefining them, and in the process creating more work on the operational side. In addition, the tools themselves need to serve marketing directives better, which means adding features in that allow marketing departments to test, gather and abstract data into something that can be employed in marketing and operational directives.

In the context of e-commerce, the problem lies in the fact that otherwise decent core e-commerce packages, make it cost prohibitive to make any sort of change to the system, and it doesn’t need to be like that. If designed right, the actual code framework should be able to handle most or all of the customization needs a client has. That way, if something does need to change, less time can be spent customizing and therefore reducing TCO (total cost of ownership) of the tool set.

Generally speaking I see the rising stars in direct to consumer as having expertise with and providing non-invasive, adaptable, (robust, portable) open source tools as well as being experts at converting raw data into real marketing and operational strategies for their clients. These are lofty goals to be sure, but it is time for us, the techies to listen to the marketers and to the users to create tools that work with and serve the clients better.

What do you think?

The difference between bridging and hybridization

By definition, Bridging occurs when two applications with separate code bases and two separate database schema share a link that allows them to exchange data and synchronize to each other either in real time or via scheduled processes such as a CRON job. The major drawback is that you are dealing with two packages, two code bases, and two database schema. Double the updates, (potentially) double the server overhead, and double the fun headaches.

In contrast, a hybrid app is one that is tightly integrated. It should share the same code base/framework and it definitely shares a common database schema. In fact, I would hesitate to call a hybrid solution “hybrid” if you were dealing with more than one code base or framework. In fact, why don’t we just put our foot down on this right now. If it doesn’t share a framework or code base (and someone is actually trying to make it coexist in the same package), there will be hell to pay and souls to eat. No, that’s not a threat, it’s a promise.

What will it look like? How will it work?

All jokes aside, the next logical step is to visualize a truly hybridized e-commerce & CMS system. Here are a few thoughts on what you might get.

• One code base for both tools
• One database for both tools
• One back end interface for both tools (and any modules that comprise the back end functionality).
• All E-commerce tools/assets manageable within the context of the CMS, implemented in a normal CMS fashion
  

E-commerce tools should not monopolize a page’s functionality

There is a reason that I italicized the sentence fragment above:

…within the context of the CMS, implemented in a normal CMS fashion

A CMS controls the structure and content of a site. So to shall it (as I’m wielding my stone tablets here) control the implementation of the e-commerce tools. This is really a big departure from the traditional way of thinking about how to structure an e-commerce site, and therein lies the problem. A traditional e-commerce site has little or very limited CMS functionality, and usually it is added as an afterthought. For example- in a traditional e-commerce application, there is a single page dedicated to all product listing functionality. Essentially, this page becomes a dedicated controller but will be wrapped in a template with some static or near-static content. You may have some includes which get dropped in left, right, header and footer, but essentially if you want to take things further and place a listing somewhere else (perhaps within another page), you are out of luck. The same goes for any other piece of the e-commerce tool set. The checkout is defined by the code in the page, rather than being one component in the page.

To solve this issue, you need a CMS that emphasizes modular design and allows you to manage where tools go in the front end, not as pages but as components on pages, and it also should seamlessly fit into the existing templating architecture. I know, it sounds like a lot. I’m awful demanding, aren’t I?

There are always naysayers…

I’m hoping that this article stimulates a hearty debate. I’m sure e-commerce purists will find fault in my assessment of what should be when it comes to bringing these tools together, for example, that in some way we may be sacrificing some sort of feature set or overcomplicating things for the end user admin. Just remember, I don’t like hearing myself type as much as I like hearing you type!

Okay, let’s say the client is a perfect client in the sense that they never challenge the limit of what the quote ecompasses in terms of project scope. How often have any of you had a client who doesn’t challenge those boundaries in passive-aggressive ways if not directly? I’m going to guess the answer is “rarely”. Feel free to correct me on that assumption.

So, we all are trying to build strong working relationships with these clients, but whether they know it or not, they always have a bigger picture in mind no matter how clearly defined the project’s tasks are. At some point, its just not worth it to spell it out due to time constraints anyway, right?

So, if that is the challenge, how do we try to mitigate the risk of overruns while keeping a client happy? Here are a few improved uses of your quoting time to ensure you get a fair price and minimize the risk of going over on the quote.

Tip 1: Ask more questions, ask relevant questions, and ask follow-up questions

The golden rule should be “assume nothing and ask everything” when in the discovery process. Don’t just find out what the tool is for, ask how they execute in real life. This will give you a much better understanding of the operational side that you are most likely being paid to automate to a certain extent. If you can’t visualize yourself doing a given task then ask more questions until you feel like you could go in and do the task or process yourself with minimal guidance. Sure, you may be committing more time at this stage than usual, but you are reducing the potential for massive time drainers later that come when you have to change something already built.

Tip 2: Put the cost in context – justify your price with a cost analysis

The more information about the current cost of doing whatever it is you are going to assist them with, the better off you are. If you present them with a $5000 quote out of context, the first question they will have is “why so much?” But if you find out that the only alternative is a 3rd-party system that charges a setup fee and a monthly fee, you can show them savings over time instead of the initial investment. What is even better is that when you come back with a slightly lower quote, you can mention the savings you are giving them when compared to the other option they are considering. If they are not aware of an alternative, be bold – find that alternative, figure out a 3-year cost for them, and then you can show them how they will save money by working with you instead.

Tip 3: Present the draft quote to the potential client and eliminate the uncertainties as much as possible

When I started freelancing, in my eagerness to get started on a project I would hand off a quote as a final quote and then say something like “we can tackle the unknowns as they come”, which is amazingly reckless and of course, I was sinking my own ship. I had no defense when the client would remember an 11th-hour feature that needed to be there, and to keep them happy, I would just throw it in. After a while I realized I needed to slow down, and approach the situation from in a much more careful, thorough manner. That isn’t to say I don’t still have quotes where I underestimate, but it happens a lot less than it used to.

Tip 4: If you can, build in a financial safety net

If you think you can squeak in a percentage of the total quote as a financial safety net, you should. Although I would recommend a 10% buffer, anything helps. You also reduce headaches for your client by not needing to get additional funds approved for the little stuff.

Of course, there are many other ways to refine your quoting process, but my personal experience has shown that emphasizing these four things has helped smooth out the process, keep the client satisfied, and keep the value of the project from becoming an issue. If you have other tips or techniques, I’d love to hear about them. Thanks for reading!