Marvel Internet Group blog

First of all - Happy New Year!! I hope everyone enjoyed the break, if you managed to take one. The last new year’s resolution I have remaining, is to increase the communication between myself and all of the great people that we have met using the software, or following the JR blog; I will be damned if I will break that one too!

What happened in 2009

2009 was a big year for JustRosters. It evolved from an idea, into a working product, then manifested into a feature rich rostering solution; and all in a matter of months! We have continued to make changes and build features based on feedback from our clients, and we are very happy with the stability of the platform.

All up we helped 243 companies around Australia assign 25,416 shifts to their 5,455 staff, with very few issues. Due to commitments with our ‘day job’, we did not get to develop or sell JR anywhere near as much as we wanted, but this will be changing ASAP!

Here are a few of the things we are working on now, or will be working on very soon:

- A support forum, in which to discuss all matters rostering, with other managers.

- Integration with Facebook.

- Award wage management; for improved cost forecasting.

- 2-way notifications which allow staff to confirm availability / shift changes by replying to SMS’s or emails sent from the system.

To be honest, we are not doing enough as far as marketing or selling JR goes at the moment; this is misguided considering how well the product is received by the people who do hear about it. We are currently looking for an energetic, hungry, sales person to help our client numbers explode. We are happy to offer a small salary with a generous commission structure, to the right person.  If you are interested or know anyone with mad skills in selling, please email me.

Happy rostering!

Aulay Macaulay
JustRosters Founder

It has taken a couple of weeks longer than we planned, but it’s ready to go!

For all existing JustRosters members, the best way to see what we have added is to log in to your account and have a play around.

If you haven’t started a JustRosters account yet, or just want peek at version 2, check out the new feature tour page.

We have also added discounted yearly subscription options, change our pricing to Australia Dollar, and updated the affiliate program to give companies promoting JustRosters higher commissions.

Huge thanks to everyone who has helped us plan out, develop and test the new features. Please contact us if you find any bugs we have missed. In return we will add 100 SMS credits to your account (valued at $25) free of charge.

Happy rostering!

P.S. Anybody with an expired free trial from the first version of JustRosters is welcome to another 30days. Just contact us with your username and we will add it on.

Just a quick post to let everyone know Marvel Internet Group’s first in-house web start-up, JustRosters, has officially launched!

JustRosters is a web application developed to make the creation and distribution of staff rosters easier, faster and more accurate. For a full list of features and a free trial, head over the JustRosters website.

Huge thanks to Alan, (lead designer) and Paul, (lead developer) for helping make this happen.

For those following the 8 part build, I will write part 6 and 7 soon.

Customer service email management can often be problematic for companies that offer email based support for their clients. Marvel Internet Group is responsible for handling customer service email messages of some applications that we have developed for clients. One such application has over 1400 user’s support request to manage; we do this with just two staff, before it is even time for lunch.

For some it can be difficult to co-ordinate efforts to ensure that a customer’s inbound enquiries are resolved as quickly as possible. Using a highly structured system for so few staff members will lead to increased cost per response and slow down overall response time. A system that is too simple will mean co-ordination failures leading to confused or neglected customers.

Marvel Internet Group’s solution to this problem is to use a Gmail account for customer service email management. This is achieved by creating a single Gmail address for all customer service support requests. With Gmail’s labelling feature we can quickly label emails based on source so that the support person can be focused on supporting a single application or all applications’ customers. The general work flow that prevents neglect of customers as well as ensuring a streamlined support process is to check, label, and action. This involves having the first person to view the mail account go through all mail and either archive, label another staff’s name, or take action on an email. Then as other staff members check the account they can see which items require their attention.

Prior to implementation of this customer service email management system we had difficulties delegating and following through with customer enquiries that fell out of the support staff’s field of expertise. Using labels such as “waiting”, “todo”, and “complete” each request can be delegated and tracked with ease with staff members in and out of the company. The result of utilizing this customer service system is greatly reduced time spent on support as items are either actioned, delegated, or waiting. Finally an end-of-week or end-of-month review of all incomplete messages prevents any request from falling through the cracks.

To try this for yourself simply create or forward your support emails to a free Gmail account and let your staff understand the simple work flow of: check, label, action. Having your support request come from custom support forms will also save you even more time!

It is about 1month since we started building JustRosters, and what a month it has been! Paul, Alan and I are working on it full time at the moment, and hope to have it complete launched in around 2weeks. The original plan shows building the front-end website as step 6, but in reality this was happening at the same time as the code writing. We finished the front-end ‘store front’ first, so it’s time to share some of our experience and results (print screens can be found after the fold).

We had already established a basic look and feel while designing the back-end mock-ups, so the front-end needed to become an extension of that. Like any web entrepreneur, I spent a few hours half my life looking at other ‘successful’ sites with a similar target market, noting down design and navigation elements I liked. I built a basic sitemap in notepad, and started writing copy for each page. The sitemap went like this:

• Homepage
• Why JustRosters?
• Pricing and signup
• Order pages (linked from pricing and signup page)
• Affiliate program
• Login page x 3 (for administrators, staff, affiliates)
• Contact us page
• Any legal pages I needed + a sitemap, 404 page etc.

If you take out all the ‘standard’ web application pages I was left with 4. The homepage, the ‘why’ page, the pricing page and the affiliate program page. These had to be ‘conversion kings’, so I was intent on making them perfect.

It’s funny, most people think a designer is responsible for what a website ANY type of interface ends up looking like, but I think the copy writer has an equal part in the end product. The words we chose ultimately decide how each page can fit together. After what felt like an eternity of writing and re-writing sales copy, (ok, it was only about 4days), I got Alan onto the designs.

Nothing builds excitement quite like watching a front-end site come together in front of you. I was extremely impressed by how it was unfolding, and found it hard to stop hitting the refresh button every 5mins Alan was working on it. Here are some screen shots of what we came up with:

There is still a lot to do between scripting the home-page demo movie, having the legal guys go over the legal stuff and getting all the copy re-checked by a cool little Aussie start-up called Editeam. The semi-completion of the front-end has provided a huge psychological boost for the team and an opportunity to go get some feedback from some of the people I contacted way back in stage 1.

Hour logs show about 40 hours spent on copy writing and 75 on design. It might sound like a lot for a 15 page site, but I figure the difference between a 4% conversion rate and a 2% conversion rate could be the difference between becoming a millionaire or just a 500thousandaire

Deciding how (and what) to charge for JustRosters was definitely a task I had under-estimated. I started by looking at the pricing for some of sites I discovered in Part 1. Of the sites with pricing listed, (I hate sites that do not list prices!), there seemed no typical pricing model. I decided to tackle this problem from the ground up; for my benefit as much as any future clients.

Once off vs. subscription
This was a pretty easy decision to make; monthly subscription. Client benefits of the subscription model include low up-front cost, ability to stop using the system anytime without losing an ‘investment’ and the reassurance we will continue to work for their business month after month. Benefits for us include a steady flow of income on those rainy months and an easier sell.

Include SMS, or charge extra
One of the major costs in running a service like JustRosters will be the SMS’s notifications which are sent out. My initial thought was to roll this into the cost of the subscription; I quickly decided this was unfair for businesses that do not use this feature. To make things simple I created some SMS credit bundles (with pricing related to quantity), and made a note to include a small amount of SMS credits in each months renewal, for free.

How to split the pricing levels fairly
While providing a ‘one size fits all’ pricing scheme would make things simple, it is not really practical. As the amount of staff each company has increases, so will the cost of our time / resources to support them. Comparing information on typical business sizes I decided on 4 plan sizes:

Micro: 0-10 staff.
Small: 11-25 staff.
Medium: 26-50 staff.
Large: Unlimited staff.

While the unlimited plan seems fairly open ended, I figured income from SMS bundles will increase relative to the businesses size, so I was not concerned about the strain a 500-employee company might put on the system at this stage.

Summery
Now I knew I would charge businesses of each size monthly, it was time to build a spreadsheet factoring expenses and a desired profit margin. I would love to be to say this delivered me some golden numbers which I have used, but it really only gave me an idea on what I ‘needed’ to charge to make the business viable with around 500 clients (my first goal).

I rounded these numbers to slightly prettier ones, and moved on wondering how I ended up spending a day on something I thought would take a couple of hours

EDIT, February 27, 2009: I have decided to reduce my prices by about one third. I have done this for a couple of reasons. First, the weak Australian dollar. Since our pricing is based on USD, I do not want my fellow Aussies having to break the bank to pay for JustRosters each month; the economy over here is bad enough for us. Secondly, the software is brand new. We really want to get as many people on the system giving us feedback ASAP. We can always move the pricing up later and hold it for the guys that get on it early.

EDIT, March 02, 2009: One of our competitors has just re-launched their website with new pricing. I am happy to see it comes in around 3x the cost of JustRosters.

At this stage of development, all the designs we had on paper were rough sketches and ideas in our heads. So it was now time for me to step in and create digital mock-ups that turned these ideas into a functional interface.

The first step was to create a simple template for JustRosters to make user interaction as easy as possible. I created the design using Photoshop, and then converted to a HTML template using my favourite scripting program, Notepad++. We kept the template very minimalist to maximise screen real estate for the major functionality, including the main roster interface.

We also decided to have all user ‘action’ forms displayed in a toolbar on the right side, which is shown at all times. The forms are added to the toolbar using the javascript library jQuery. We used the side action bar for a number reasons:

1. The user never has to navigate away from the page they are currently on to perform related actions.
2. The roster interface is never covered by a pop-up when a action needs to be made.

jQuery was used a lot throughout the interface for a number of different functions and effects, from adding the input forms to the toolbar, to styling the tables and forms. I use it because it is very easy to use and lightweight, and it achieved its functionality automagically without adding extra markup to the HTML.

The next step was to turn each of the sketches into functional pages, this is where we ran into our first major hurdle. The main page of the roster interface needs to display a calendar that shows the dates of the roster period along the top row, and the staff members of the roster listed down the left column. It sounds simple until you start testing with a 2 week roster featuring 50 staff…. in a small screen. We needed the grid to scroll but it was important to keep the top row (dates) and left row (staff) in view at all time. After about 4hours of Google searches we found no real solutions (but hundreds of people looking for one). After a lot of playing around with this, we got it working!!! When we get some time we will release the code snippeits.

From here on it was all smooth sailing. The rough sketches were transformed into an easy to use interface.

After 96hours working on the mock-ups (40hours spent on the roster view alone), they are finally complete. Now it is time for Paul to step in and code the guts of the application, turning it from a puppet to the real thing. I will have bigger rant about the roster view shortly

The sketches were done and we were itching to get started with the backend HTML mock-ups in stage 4.

Because we have been involved in the ‘setting up the project’ stage so many times, we find it quick and easy. I will leave to more technical details for Paul to cover shortly, but here is what I needed to do:

Step 1 – Buy a domains, certificate and hosting
I headed over to webhostingmarvel.com (shameless plug) and ordered a domain name, secure certificate and some US virtual dedicated hosting. It just so happened I had a 100% discount code I will consider moving the site to a fully dedicated server before launch, in the meantime the VPS will be fine.

Step 2 – Setup email
10mins later the hosting was setup and domain propagated. I headed straight for the Google Apps signup page. I won’t get started on why I love Google Apps in this post, let’s just say it allows me to forget about the dramas associated with standard email accounts and support ticket systems. For now the free addition will do. If we manage to fill a 7.2gig email box with support requests, shelling out $50/y for a Google Apps premium account will be the least of our worries!

Step 3 – Install Live help and mailing list software
I had already made the decision to exclude contact phone numbers from the JustRosters website. This is not because we are a dodgy company, I just think Live Help is faster and offers more accountability (a transcript of every issue) compared to a phone call. We can also monitor the Live Help from home so our support hours become almost 24/7! Our live help system of choice is Livezilla. It takes an hour or so to setup but it is free and has proven very robust.

Our mailing list software of choice is Pommo. Again, free, and very easy to setup. I got Alan to throw a subscribe box on the JustRoster’s homepage in case anyone actually reads this blog and wants a 6months free trial when we launch (hint, hint).

Step 4 – Build a shared doc with usernames / passwords
I created a new Google Doc and pasted in FTP, DB, Google Apps details etc. This doc is then shared with Paul (lead developer) and Alan (lead designer). If we need to add more staff at a later date, I will create separate documents to share with them. While having usernames and passwords pasted in plain text does not sound ideal, it beats using the same password for everything, writing them on a bit of paper or emailing them around. The Google doc can only be accessed via each of our master passwords over a HTTPS connection, so I am happy with the security.

That is the project pretty much setup and ready to get started on. Only about 3hours of my time needed and the cost of a domain, certificate and server. Stay tuned (or subscribed?) for Paul’s technical follow-up post and Alan’s coverage of Part 4 – Building the HTML mock-ups and design.

With any web application there is usually a learning curved involved for the end users before they are familiar enough with the concepts and work flow to explore the application on their own. Especially when a new system is introduced to replace an existing one it can be very difficult for the end user to adjust. That is when support requests start flowing in.

In our experience support emails can become rather difficult when the user does not provide adequate detail about what they are doing, or who they are. The lack of information means a lot of time is spent waiting on user clarification. The time spent identifying the problem often takes longer than providing the solution. This is where investing the time needed to create a custom support form comes in.

In a custom support form that we implemented for ICEF Online (1,500+ people use it almost daily), the form auto-embed hidden values identifying the user’s account, the page they were on before they loaded the support form, as well as browser information and screen size; all of which help us diagnose problems far quicker than if we just relied on plain email, or even an ‘off the shelf’ support ticket system.

For common cases where the reply just requires usage instructions, a custom support form can completely eliminate the need to wait for a user to reply with details of what they were trying to achieve. For more complex scenarios we are able to completely re-create the user experience for testing by reproducing user results with the same browser, operating system, and input values. The limits of how much information your support staff have access to diminishes to almost zero once the basic system is put in place, which is a very low cost given the customer satisfaction returns that can be achieved.

Hi, I’m Alan Attwater, the lead designer for Marvel Internet Group. I’ll be posting general information about the design and development of our online projects, as well tips and tricks on technologies like Typo3 and CSS.

I work on a variety of projects at any one time, designing both shop front websites and web applications. I recently completing the design and development of the new Marvel websites in the Typo3 CMS, only 4,000+ lines of CSS!

I’ve also started on the interface designs for a new in-house project called JustRosters.com, turning VERY VERY rough sketches into attractive, working interface mockups. The biggest challenge so far has been getting the main interface to fit dynamically on any screen size, whilst maintaining it’s main functionality and useability. Sounds easy, but calendars never seem easy to work with. I’ve made good use of the Javascript user interface library jQuery, to provide the main interface functionality, while maintaining fast page load times.

Anyway, better get back into it, after all, those interface sketches are very rough, and Paul is hanging out to start coding!