There are default email templates that are predefined in Prestashop. These emails are sent to a customer after (s)he creates an account on the website, subscribes to a newsletter, makes a purchase, in case of payment receiving, confirmation that the order has been shipped and some other cases. And if you want these emails to be unique and bring more information to a customer, then you simply need to modify them. Further, I’m going to show you how to change email templates in Prestashop 1.7.
You ever wondered why the estimates that the developers give you rarely match the real timeframe 100%?
Sometimes the answer might be simple “greed” or incompetence. But let’s assume for a second that you work with a competent and straightforward developer. Does it mean he’ll always commit to his deadline? Maybe. But the reality tells us that no, even the most honest and competent developer can fail the deadline.
And often it’s the client’s fault.
“Oh, he’s trying to put all the blame on the client!”: – You might think now. And you will partially be right. But I’m not here to blame. This article isn’t about pointing fingers.
This article is about minimizing the risk of you being the source of the project slowdown, time being wasted and money being spent in vain.
And here are couple things you can do:
Describe Your Project
I’ll be blunt and passive-aggressive here. We can’t see into your mind. We can’t imagine your future site for you. Over the years I became pretty good at guessing – but you should never base your business on guesswork. So the deal is – imagine your project and write it down. And the more detailed the project is the easier it’s for us to understand, comment and give a correct estimate.
It’s not only that, but we also can give our comments the benefit of the doubt. Fact is – we’ve seen a lot MORE projects than you have and if we say that a certain UI element is better done the other way – at least consider that we’re not saying that just to fish more money out of you. Especially when we ask you to drop some feature altogether.
More tips on awesome specwriting will be available by this link as soon as I get around to writing them.
Three simplest things to remember about it are:
Write stuff! – the more text there are the better.
Draw stuff! – be it wireframes or a napkin drawing – we take it all and run with it.
Look for stuff! – there are always, ALWAYS! examples of how something was done before. Look at the competitors. Look at successful websites. Show your napkin to your friend. These examples are a valuable asset in development. And it’s not “stealing ideas” – you will have something on top of that, something new. All our lives decisions are iterations on what we’ve seen previously. But to sound less philosophical: Don’t steal outright, but don’t be afraid to iterate on stuff.
As a result we are going to have a very detailed specification, broken down to tasks, with graphics and examples provided… that’s a real pleasure to estimate such projects. And their estimates are more detailed and true.
Stage Your Project
A common mistake is launching your project in a whole piece as soon it’s done. Why is it a mistake? Formal launch is different from a partial launch. All your marketing material can be targeted at the official launch date. It doesn’t mean that the beta of your project can’t be running prior to official launch.
It’s the internet! It’s all code! When somebody tells you they can’t change something easily – they may be right. But if they tell you they can’t add anything on top – they’re pathetic liars.
So take your project specification and slice it to:
- The Base
Speaking ecommerce – the basis is the shopping cart installation. It should hold your products and sell them. As soon as you bind your Paypal or whatever payment gateway you use to the store – it’s technically ready. So that is the most important part. Sometimes it’s the simplest part too.
- The Meat
Here be everything that makes your store unique and stand out. Extensions, modifications, admin tools, unique frontend and user experience features. All of this can staged and moved around so it’s kind of a big item. I’d love to tell you more about staging here (link) as soon as I write more about it.
- The Topping
Design, mobile template, social networks, cool frontend elements… More stuff about design will be written somewhere around there (link) – for now it’s an important and for some project – separate stage. Most of the time it goes throughout the whole project, with each new extension requesting template changes. So it should be broken down as well.
- The Rejects
That’s a sad thing to speak about – but sometimes something can go wrong and your project can be not ready on release date with its full potential. In case you are on a very strict deadline it’s good to know right away what your project can launch without. Put all the stuff you might forego that your project can launch on time without it.
Follow Your Project
Call your developers. Send them emails. Stay late. Rise early.
It’s your project and couple hours you don’t sleep a week can go a long way in saving you a lot of money in the future. Communication is key and you can’t always count on your developers to be interested in your success as much as you are.
There is a blurry line between being active and constantly nagging but honestly it’s better to overstep it a little at least till the moment when you are absolutely sure in your developers.
Couple more things… Always demand a set in stone weekly meeting.
Even if it’s a 2 minutes long one. Even if there are no real news. A calendar note keeps you and the developers on edge, not letting you forget stuff, forcing them to prepare for it. Send your meeting agenda couple days prior and you will ensure even better results!
And don’t forget to write the results of your meeting down.
Test your own project. Yes you are not a QA specialist. Yes we probably know how to find bugs better than you do. But this doesn’t stop developers from not noticing something; the eyesight gets a little blurry on your own project weeks and weeks into. So again – spend 15 minutes to test the latest build yourself. It isn’t much but keeps you on the same page.
Use Redmine, Basecamp, Jira, whatever floats your boat. But keep the tasks written, keep the bugs separated and keep the email discussion in separate threads.
I’m not exactly inventing something here, I doubt that you will think about it as something new. But writing this article I act exactly as you should while handling your project. Be honest, be crystal-clear about your intentions and don’t shy away from writing the most basic stuff down. It won’t hurt after all.
Happy project management!