SEEK Hackathons are all about building new and innovative products to help our customers — they are exciting and I wanted to work on a hack that was bleeding edge, technologically advanced and buzzword compliant. I was hoping to win one of the awards on offer, but unfortunately that didn’t happen. I ended up working on a hack that was complicated, extremely challenging and meant working with some pretty ancient software. However, it did end up going into production and became an enormously rewarding experience.
So, my hack idea was to revamp our invoices — I can hear how excited you are already. But wait. Think about it: invoices go to all your clients, they are an important part of your business, but do you ever give them a second thought? Here at SEEK, our invoices had not changed in who knows how long. The design was archaic (see the image below), it didn’t reflect SEEK Branding, and we were still asking people to pay by cheque. I realised it wasn’t the sexiest idea for a hack, but I was determined to go ahead and put a team together to make our invoices pretty. Here’s how we did it…
Step 1 Defining the problem in detail
We asked the question “Why exactly are we sending invoices?”. And, it’s not just to get money. There were four main reasons — advising of payment due or credit owing, instructions on how to pay and advising customers of new products, plus we wanted to ensure our branding followed marketing guidelines. Based on our existing invoice (see image right), we had four problems:
1. Call to action was unclear — invoices, receipts and credit notes all looked the same (occasionally people actually paid on a credit note (when there was no amount owing) — that’s a good signal that something is wrong)
2. Paying by cheque appeared to be the only payment method — we had managed to hide the credit card payment details so that most people couldn’t see them
3. Branding did not match our current guidelines
4. No option to update customers about new products
In addition we use a document management system that is primitive, difficult to program and generally hard to work with. In the past, we had actually thought of buying software to produce a better invoice but the software was expensive to buy and licence.
Step 2 Getting the right people involved from the beginning
I knew I needed to get all parts of the business on-board to ensure success. User Experience (UX) was very important as we wanted to make the invoices pretty using SEEK colours and branding; we wanted to provide a clear call to action; and we needed to make the purpose very clear — is it an invoice, a credit note or a receipt? To get people from across all areas of the business that are currently impacted by our poor design, I approached departments such as Finance, and Marketing directly. My hack idea was enthusiastically received by everyone I spoke to, which made me feel that this was going to work.
Step 3 Realising it doesn’t need to work
It was time to start hacking and I had started to learn HTML & CSS with a view to exploring the creation of invoices within HTML. After that we could convert them to PDF. We found an opensource HTML to PDF converter, so our effort was concentrated on building the solution in HTML. However, I soon realised that we couldn’t get a working version coded prior to the marketplace showcase on the final day. So we decided we’d use mock-ups and just present a proof of concept instead — while highlighting how awful our existing invoice looked by comparison.
The UX designer cleaned up the copy, made the payment options clearer and created a dynamic banner as a new marketing channel. We created three separate formats — Credit Note, Paid in full and Invoices. Meanwhile everyone else was hard at work testing our design, looking for information we wanted to display as a priority and spruiking our hack.
The proof of concept was started and finished during the 3-day Hackathon. We were excited during the marketplace judging, as our hack was very popular with the Execs, many of whom insisted that we must get this invoice fixed as soon as possible, especially after seeing the existing invoice. Sadly we didn’t win an award, but we did receive a special mention for People’s Choice and with all the Exec support, we were sure we could still push this hack to production.
Step 4 Never giving up
Within a month of the Hackathon, Finance had built the business case and got Pretty Invoice approved thanks to our completed proof of concept. In hindsight, I can see that the next stage involved a bit of over-promising — I thought I could get it done in 2 weeks, but it actually took 6 weeks due to some unforeseen challenges. I knew that there were some issues to be addressed, but had no idea how truly complex it was until I had started the programming. In addition the scope increased with the addition of payment receipts for paid-in-full invoices. Plus, we needed to ensure we covered all the delivery methods — print house, mail room, document imaging and email provider. I was convinced I could do this easily, but a problems reared their ugly heads almost straight away.
Issue #1
Our document management system couldn’t print PDF’s as it uses its own standard format.
This derailed everything and I was close to giving up. There seemed no way around this. However, I eventually came up with a work-around — putting the files onto the file server. Then I wrote a program using C# to scan the folder and print to our third party software. I thought we were in the clear, and then I hit the next bump in the road.
Issue #2
The mail room system couldn’t read the address field and didn’t support Roboto font, it only supported TrueType fonts.
This was a big issue from a UX point of view — we’d spent ages finding the right font and certainly didn’t want to change it now. This felt like another derailment and it took me a week to come up with another option — I changed the font in the address area to Arial and made it capitals so it didn’t appear really different to the body font. I thought it would be plain-sailing from here on, but then along came…
Issue #3
This next issue was a major one — the third party document imaging system couldn’t read the PDF which had been created with our opensource software — it read the text as images. Still not giving up though. Surely someone else had experienced this problem, so I started searching online. Eventually I found what I was looking for in a C# library — which we purchased for a small amount. Then I wrote a C# program encoding all fonts as Roboto except the address which was encoded as Arial. Simple really. On to the next stage — deployment.
Step 5 Using Agile
Our team doesn’t usually use Agile however I decided that small deployments would make more sense as I could get instant feedback from Finance. We made these small deployments of the product and had Finance compare the old invoice to the new invoice, without actually sending the new version to the customer. It didn’t take long before we had our final product ready to go. The feedback we received was that they looked great, a lot clearer and easier to read, definitely more professional and “Why wouldn’t you want to pay your invoice when it looks that damn good? “. See the finished product below.
This was a hack that in the words of one of our Execs “just had to be done”. Team Pretty Invoice worked really hard to get this hack to production and I doubted it could be done more than once. But now it’s out there.
Our hackathon idea didn’t win an award but went to production anyway which is a great achievement in itself.
