Distribution, Manufacturing, and Internet Modules

[JRobinsonVLS]

I'm curious to find out if there are any other users of the EBM module in MAS who have found a way to deal with the growing challenges of SEO (Search Engine Optimization.)

Due to the fact that there is no unique URL generated for each product in EBM, there is no easy way we've found for the search engines to catalog our site. We have nearly 10,000 products up there, and the search engines are having a terrible time indexing what we have.

EBM is long overdue for an update to how the web works today. If we can't have someone type one of our products into Google and have it appear in the results, but our competitors can using other software, where is the advantage of the integrated module?

Please share your thoughts and experiences.

[mas90guru]

Jeff,

I had a similar issue with one of my clients Inkjetwarehouse. We didn't manage the eBusiness (they did it on their own) but my understanding is they had to do a good deal of this manually.

The guy who set it all up for them also works (strangely enough) for an SEO organization. I can give you his email if you're interested. I'm sure he could at least share his experiences with eBusiness and the steps he had to take.

[JRobinsonVLS]

Thanks Wayne, I'd be interested in talking to anyone with a different perspective than our own. Manually is what we're seeing a lot of as well, and that's the frustrating part to all of this - an integrated module that requires so much effort to advertise your wares online.

Our SEO company has recommended pulling out of using the EBM module. Their argument gains momentum when you take into account that it is difficult to generate revenue due to the module's shortcomings. If the module prevents us from effectively advertising what we have, then are we really gaining much from an integration? Sure it's awesome to have the latest pricing there, and for our existing customers, it's wonderful. But existing customers are not going to grow our business beyond a certain level. EBM needs to take into account we want to bring NEW customers into our business, not just service our existing base.

I'm not ready to throw in the towel just yet on the module, but I'm also willing to concede there is always the possibility of a better way that what is currently in place.

[mas90guru]

One product that comes up a lot in discussions about Sage MAS 90 or 200 eBusiness is In-Synch.

I sent my client an email to see if he would join use here. They really did a tremendous job on their site and overcame a lot of the issues.

My sense has always been that the eBusiness is for light use. My problem is that light use always grows and migrates to more customized use (despite our best initial intentions). These projects which start small have a way of growing very more complex very quickly.

[JRobinsonVLS]

Thanks Wayne.

I took a quick look at that link, and it reminds me of Scribe, which we already own. I know we have that as a fallback should we decide to abandon EBM, use a better webside cart program, and then feed that into MAS via Scribe, but I don't think that's really the best way for us just yet.

Regardless of the level of complexity of your e-commerce site, the inability to be able to shop for something that has a hard URL link that can be indexed, emailed, copied, pasted, etc is essential in the world of ecommerce today.

If you want to buy something from me and I can't cut a paste the link that takes you to that exact product on my store, how am I really taking care of you as my customer.

I'm heartened by the lastest round of Sage adapting to what the customer needs to make the product more usable. This falls into that category in my opinion.

[DFeller]

You can actually create links directly to categories or to items themselves, but the base product doesn't provide for this out of the box.

Dawn

[JRobinsonVLS]

---

DFeller wrote:

You can actually create links directly to categories or to items themselves, but the base product doesn't provide for this out of the box.

Dawn

---

Yea, I'm aware of that, and we actually do that quite a bit when it comes to e-marketing pieces. We'll imbed that into the flier.

Where it becomes an issue is when you have people who aren't aware of that code (customers and normal CS employees) who simply can't cut and paste the address in the browser navbar, or use the "send this page or link by email" to someone who is trying to find a specific product.

If I'm looking for "Product X" on the web, it's very difficult, if not impossible to have Google and the other major engines to return that my e-commerce site even carries the item. For someone who is browsing for price comparison and has a list of links for that product to various shopping sites, once they manage to find it on mine, they have no easy way to "right-click" and save my item's direct link to refer back to it later. That is a huge disadvantage in trying to sell over the web.

[RobWaite]

In regards to In Synch and data replication.

I  currently have on the table for development methods to replicate data to a SQL over Web Services. If you are interested I can copy you on its functionality when I have it finished.

I will need to be able to Synch data to an Customized Ecommerce site I have develped with ASP I was hoping to get direct access to a replicated SQL server on our network but have hit an impass with the network administrator on the sercurity of opening port 80... This is what has been driving my need for data replication via Web Services on a disperate Web Server.

[MBrown4931]

In situations like you're describing we've been referring clients to WebSitePipeline (a web developer and site hosting company). They have pre-build integrations with MAS 90/200 using Insynch by ROI Consulting, Sage Payment Solutions, and Avatax by Avalara. This costsa little more than EBM but it sounds like your client has outgrown an entry-level solution.

[mas90guru]

Keep an eye out for Myron Stevenson on here -- he's involved in reviewing this for a client at the moment as a well and may have some additional feedback.