Convert visits to sales to repeat purchases

The moment you start seeing more than a thousand unique visitors in just one day, we won’t be surprised if you’d be grinning ear to ear the entire week. But when weeks turn into months, you’ll then remember why you started off on this venture in the first place … and it wasn’t about just owning an immensely popular website.

People, like you, who’ve chosen to invest in eCommerce were most likely thinking along the lines of great ROI, revenues, and profits. Now that you have thousands of visitors, how would you like to have, say for a start, 1% of them buying the products on your site?

You know more about your own product prices; you do the math. But what might really interest you is that a slight change in that 1% conversion rate can already spell a big difference in your profits. Now imagine bringing that 1% up to at least 10%. That’s possible, but not if you simply rely on guesswork.

We rely on tests applicable to complex multi-variable systems, just like today’s typical eCommerce websites, in determining which combination of copy text, landing page images, form layouts, and background colours generate higher conversion rates.

Here’s how we’ll convert your visitors into buyers:

  • We’ll conduct A/B or even multivariate tests on your eCommerce website, thus eliminating guesswork in determining how to increase those conversion rates.
  • We’ll perform on-site and off-site web analytics to gain a deeper understanding of web usage to aid in our optimisation operations.
  • Through our expertise in copywriting, graphics and web designing, UI designing, and website QA, we can enhance and fine tune your site to give each visitor a uniquely engaging browsing experience.
  • We can also integrate CRM (Customer Relationship Management) systems so that you’ll have the technical advantage to turn one-time buyers into repeat customers.

Check our similar posts

Can you do away with the Project Initiation Meeting?

Project initiation meetings are often skipped to fast-track projects. Once a sponsor is found, organisations go straight to project planning and execution. But based on our own experience, holding a project initiation meeting can actually eliminate many issues that may crop up in the future and hence may speed things up instead in the long run.

It is in the project initiation meeting where your project objectives and scope are clarified and all stakeholders are brought to the same page. Project sponsors and stakeholders will have to know in a nutshell what is needed from them, what the possible risks are, what different resources are required, and so on. So that, when it’s time to proceed to the next phase, everyone is already in-sync.

So what are taken up in such a meeting? Perhaps an actual example can help. Sometime in the past, we set out to work on an eCommerce website project. After conducting the project initiation meeting, these were some of the things we were able to accomplish:

  • Identified deliverables e.g. site design, interface to payment system, etc.
  • Come up with the project phases
  • Agreed what should be in and out of scope
  • Defined the acceptance test criteria
  • Identified possible risks
  • Identified the possible training and documentation work needed
  • Established whether any analysis was required, e.g. as with regards to payment interfaces
  • Formulated disaster recovery plans
  • Defined roles and responsibilities
  • Drafted timelines and due dates

Aren’t these covered in project planning? If the project is a big one, the answer is no. In a large project, project planning is a much more exhaustive activity. In a project initiation meeting, only the basic framework is defined.

Some questions may still remain unanswered after a project initiation meeting, but at least you already know what answers you need to look for. In the example we gave earlier, we left the meeting knowing that we needed:

  • a list of all necessary hardware to estimate the costs
  • to identify possible dependencies we might have with third parties
  • to identify what software had to be bought and what skills we needed to hire

When it was time to proceed to project planning, everyone involved already knew what direction we were taking. In effect, by not skipping the project initiation meeting, we were able to avoid many potential obstacles.

Benefits Realisation Frameworks – A Useful Handle

One of the greatest challenges of project management is maintaining top-down support in the face of fluctuating priorities. If you elect to take on the role yourself and are peppered by other priorities, it can be a challenge to exactly remember why you are changing things and what your goals are. Sometimes you may not even notice you have reached your goal.

The Benefits Realisation Chart-room

The Benefits Realisation Model is a framework on which to hang key elements of any project. These traditionally include the following, although yours may not necessarily be the same:

  • Definition of the project goal
  • Quantification of intended benefits
  • Project plan versus actual progress
  • How you know you reached your goal
  • Quantification of actual benefits

Another way of describing Benefits Realisation Frameworks is they answer four fundamental questions that every project manager should know by heart:

  • What am I going to do?
  • How am I going to do it?
  • When will I know it’s done?
  • What exactly did I achieve?

The Benefits Realisation Promise

An astounding number of projects fail to reach completion, or miss their targets. It’s not for nothing that the expression ?after the project failed the non-participants were awarded medals? is often used in project rooms. We’re not saying that it is a panacea for success. However it can alert you to warnings that your project is beginning to falter in terms of delivering the over-arching benefits that justify the effort.

When Projects Wander Off-Target

Pinning blame on participants is pointless when project goals are flawed. For example, the goals may be entirely savings-focused and not follow through on what to do with the windfall. At other times realisation targets may be in place, but nobody appointed to recycle the benefits back into the organisation. This is why a Benefits Realisation Framework needs to look beyond the project manager?s role.

Realisation Management in Practice

If the project framework does not look beyond the project manager?s role, then it is over when it reaches its own targets ? and can even run the risk of being an event that feeds entirely off itself. In order to avoid a project being a means to its own end, this first phase must culminate with handover to a benefits realisation custodian.

An example of this might be a project to centralise facilities that is justified in terms of labour savings. The project manager?s job is to build the structure. Someone else needs to rationalise the organisation.

In conclusion, the Benefits Realisation Framework is a useful way of ensuring a project does not only achieve its internal goals, but also remains a focus of management attention because of its extended, tangible benefits.

How DevOps oils the Value Chain

DevOps ? a clipped compound of development and operations – is a way of working whereby software developers are in a team with project beneficiaries. A client centred approach extends the project plan to include the life cycle of the product or service, for which the software is developed.

We can then no longer speak of a software project for say Joe?s Accounting App. The software has no intrinsic value of its own. It follows that the software engineers are building an accounting app product. This is a small, crucially important distinction, because they are no longer in a silo with different business interests.

To take the analogy further, the developers are no longer contractors possibly trying to stretch out the process. They are members of Joe?s accounting company, and they are just as keen to get to market fast as Joe is to start earning income. DevOps uses this synergy to achieve the overarching business goal.

A Brief Introduction to OpsDev

You can skip this section if you already read this article. If not then you need to know that DevOps is a culture, not a working method. The three ?members? are the software developers, the beneficiaries, and a quality control mechanism. The developers break their task into smaller chunks instead of releasing the code to quality control as a single batch. As a result, the review process happens contiguously along these simplified lines.

Code QC Test ? ? ?
? Code QC Test ? ?
? ? Code QC Test ?
? ? ? Code QC Test
Colour Key Developers Quality Control Beneficiary

This is a marked improvement over the previously cumbersome method below.

Write the Code ? Test the Code ? Use the Code
? Evaluate, Schedule for Next Review ?

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ?on the same side of the organisation?.

The Key Role that Application Program Interfaces Play

Application Program Interfaces, or API?s for short, are building blocks for software applications. Using proprietary software-bridges speeds this process up. A good example would be the PayPal applications that we find on so many websites today. API?s are not just for commercial sites, and they can reduce costs and improve efficiency considerably.

The following diagram courtesy of TIBCO illustrates how second-party applications integrate with PayPal architecture via an API fa?ade.

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ?on the same side of the organisation?.

imgd2.jpg

The DevOps Revolution Continues ?

We close with some important insights from an interview with Jim Stoneham. He was general manager of the Yahoo Communities business unit, at the time Flickr became a part. ?Flickr was a codebase,? Jim recalls, ?that evolved to operate at high scale over 7 years – and continuing to scale while adding and refining features was no small challenge. During this transition, it was a huge advantage that there was such an integrated dev and ops team?

The ?maturity model? as engineers refer to DevOps status currently, enables developers to learn faster, and deploy upgrades ahead of their competitors. This means the client reaches and exceeds break-even sooner. DevOps lubricates the value chain so companies add value to a product faster. One reason it worked so well with Flickr, was the immense trust between Dev and Ops, and that is a lesson we should learn.

?We transformed from a team of employees to a team of owners. When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.? (Jim Stoneham)

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Ready to work with Denizon?

Contact Us Today