I hope you find my writing and business tips and observations useful. My business and blog are dedicated to helping businesses communicate clearly and reach their potential.
Read, subscribe to my newsletter, enjoy!Tash
being vague builds anticipation – or annoyance?
A clear sign for the end of the metcard for trains in Victoria
I’ve travelled on some trains lately which is not something I do very often these days (working from home doesn’t require a lot of train trips!) and read some messages about the new ticketing system.
Now, I called it a new system because it is replacing our old system but it has been in use since the end of 2009! Basically, the myki card is an electronic contact system for public transport throughout Victoria instead of our old metcard system.
Myki has been phased in and many people were still using the metcards earlier this year.
Notices in trains
At each end of train carriage in Melbourne, a ticker system gives messages such as the name of stations as the train approaches.
Recently, that is in October and November 2012, I’ve seen the following message:
myki is replacing metcard in 2012
What do you think of this message?
Build anticipation
Sometimes, not giving the full story is a great way to keep people interested and motivate them to find out more.
Like at the end of season a TV show will have Mary heading into danger while John is arrested on his way to rescue her. If you care about John and Mary, you are drawn to see the next season.
So being vague can have advantages.
I’m not so sure that a vague ‘2012’ is good enough for something like ending a ticket system. Especially as I remember 1 July being advertised as the date metcards stopped…
Commitment or safety?
If I tell you that the blog posts you asked me to write will be ready at 1pm on Monday, you have a clear expectation. And I have made a commitment so will provide the blog posts on time.
If I had told you they’d be ready on Monday afternoon, I have given myself a little more time to get them finished but you still have a commitment to rely on – you know you will have them by Tuesday morning.
Would you be very impressed if I said ‘yes, I’ll write you some blog posts this month and let you know when they’re ready’?
There are times when you can’t be sure of a delivery date so you use less concrete references to save problems and complaints – it gives the business a safety net really.
Maybe I’m just cynical but I think too much safety net behaviour reduces your credibility and people don’t trust you. We have respect for someone brave enough to stand up and say “I will do this by this time” – even if they later adjust the timeframe a little.
So I am not impressed by a message that myki is replacing metcards in 2012.
2012 covers 12 months (10 of which have gone!) and 365 days.
2012 doesn’t give me clarity of when I must change systems. It feels like they have no faith in meeting deadlines so have extended it as much as possible to protect themselves rather than push to meet it.
I think even ‘myki is gradually replacing metcard during 2012’ would have been better if various dates were involved for phasing in myki. Or update the message during the year to be more specific, such as ‘metcard not for sale from July’ and ‘metcard readers now deactivated’.
Make your commitment
What do you think of this public message?
Does something so vague give you enough faith to trust the system? Maybe it seems reasonable to you?
When you are choosing suppliers, how committed do you expect them to be?
Document codes
Do you manage a lot of documents? Do you worry about old versions getting confused with new versions?
This is why you see a document code on many documents, especially those from major organisations. They make it easy to tell one version from another at a glance – this is known as version control and can save a lot of problems.
Where do document codes come from?
There is no central system for giving documents codes – each business makes up its own system and introduces it as it is the business who needs to use the codes.
What does a document code include?
While there is no single coding system, most codes will include the date as that is the simplest way to determine how old a document is.
Other than that, it is up to you how the code is created. The complexity of your code will also depend on the number of documents you deal with – a few documents can be numbered 1 to 20 for example, but a large number of documents may be better divided into types and then given a number (e.g. F1 is form 1 and L24 is letter 24).
Tips for creating document codes
Here are a few tips from the systems I have created and used in the past:
- include a version number so it is easy to refer back to previous versions. Particularly useful if two versions come into the same date period!
- leave a gap between numbers so it is easy to add related documents later. For example, application form is F1 and change of address form is F5 so you can later add an increased cover application as F2
- use dots rather than slashes to separate sections of a code – slashes can be misinterpreted by scanning software. So try 09.2010 instead of 09/2010
- group like documents for simplicity, and consider naming them differently
- if documents change fairly regularly, use month and year, not just the year in the codes
- choose a consistent spot to place document codes – e.g. bottom left corner of the last page. It won’t work for all documents but it helps to have a starting point
- record the document codes so it is easy to update them and to know which version is the most recent
Recent Comments