Case study guidelines

Prospects will associate professionalism of case studies with our project communication skills. If our case studies are well-written, prospects will assume our project communication will be great too.

Communication is often prospects’ main concern when outsourcing, so case studies are a great opportunity for us to convert hesitant high-value leads.

Prioritize case studies for projects that: have a good logo/website/interface design, are complex, where we can get a testimonial, has many co-workers worked on it so that we can use it in many developer profiles. The design is important and gives the first impression.

Our development agreements state that we can show a client’s project information including screenshots to other prospective clients. However, we should ask if it’s ok before we publish any non-anonymous project details publicly.

Time cycle of content pertaining to projects

A project kick-off blog post can be posted as soon after a new client agreement is signed as possible. You could include a casual picture of the team behind the project or something like this. With PHP or Laravel t-shirts if possible.

Add a few lines about a new technology that we have decided to use and why. What challenges do you foresee? What features will you work on? Who is the client and why do they launch their project?

The time cycle of content pertaining to a project would be:

Client signs contract: prepare kick-off blog post
After one month of development: add AA to DPs
After three to six months: publish anonymous case study. Preferably around the same time that the project is launched, but can be done before too
As soon as possible: add testimonial and change to public case study (not anonymous)

The abstract

The case study intro is called the abstract and should take up four lines on our LPs and front pages. In developer profiles (DPs), it will take up around five lines. Aim for around 280 – 350 characters (Gdoc->Tools->Word count).

Most prospects will just read the abstract. So make sure that the abstract explains the project well using concise sentences. A prospect who browses through our portfolio won’t read more than the 350 characters anyway. The abstract is automatically copied to the top of the full version case study.

Anonymized abstracts

Prepare an anonymized abstract (AA) early on. An AA can be added to DPs long before the project is successfully launched. Developer profiles are frequently sent to prospects and we win better projects if we are able to demonstrate what complex projects our developers have worked on, and are working on, even if they are anonymous.

Ask the website team to use this staff panel report (limited permissions) to see whose DP we need to assign the AA to. The client’s logo can be blurred.

The case study title

The title you add for the case study in the EMS will be shown in the H1 headline tag as well as the URL. Both of these are high-value factors in terms of SEO. Think hard about an optimal title.

Typically capitalize the first letter only for consistency across our website. Limit the case study title to around 70 characters including spaces (maximum two lines in the full case study).

This fits well with the max title length Google shows in search results as well. Omit the client’s company and project name as well as standard phrases like “we used PHP and MySQL”. The aim is to attract long-tail search traffic, and the client’s brand is not an important keyword.

Example for FunCruises: Custom CRM and booking system for event planner and travel agency

Anonymized case studies and first drafts

Publish an anonymized case study (ACS) on our public portfolio early on. If you can flesh out your AA with another two paragraphs, you have a first ACS. Add it through the EMS but list it quite far down as it will likely be of lower quality than our top projects.

The first draft can be fleshed out over time. Aptum was (historic screenshot) an example of a short, concise and clear text. Z*** too.

Before publishing the case, let our content writers scrutinize your text. Once published, email PD, content writers and David. Update the same group whenever you make significant changes.

Headlines, page titles and URLs

See content marketing guidelines.

Case study outline

Being a senior, you don’t have to perfect the case study yourself. In terms of avoiding costly underdelegation, it makes sense that content writers perfect the language and generate keywords.

Write a rough outline and let your colleagues take it up from there. To get you started, answer these questions:

If the client doesn’t have a website that explains this, then explain what the client’s business is. Who are their customers, how do they make money, what industries are their customers in, what employees/roles does the client and their customers typically have. The case must give the reader a high-level perspective and not just list features. This adds context for prospective clients.
What are the core features?
How does the features provide value? What are the benefits from client users’ perspective and client’s customers’ perspective?
What technologies (APIs, libraries, third party solutions etc) were used and for what?
What have you learnt?
What are the challenges ahead?
What features have you suggested/do you plan to implement ahead?
How could similar clients benefit from similar custom systems?
How many hours have been spent? We can hint at approximate hours/cost while qualifying leads.

As a content writer, you can push forward project content. Ask a project team member for a rough outline, ask them to share the LMS thread, work plan, specification and spend an hour browsing through that material as well as the client’s website.

Thereafter again ask specific questions and probe staff who has been involved in the project.

Perfecting your case study

Apply audience funnel and brief paragraphs: Content should be easy to grasp for anyone. Save very technical information for the end of the case, like in the @spire case. A non-technical person should be able to understand the first sections.

Focus on the business aspects and the benefits first. Technical clients can delve deeper if they wish, by reading the bottom sections. As the quality of your case study improves, we can move it higher in the listing.

SEO aspects

Aim to flesh out the content from time to time. Search engines and “deep users” will appreciate the quantity. Chances of editorial backlinks increase.

Never copy sales texts from the client’s website. Search engines punish our ranking if you duplicate content. Rewrite such content and include development challenges and keywords. You can check against this list of keywords.

Include keywords not only for long-tail SEO purposes, but because clients often ask for a specific technology, say implementation of the Klarna payment gateway. It’ll be easier to convince such a prospect if we can actually prove that we’ve used the technology in a live project and for a happy client.

Use the most important and unique keywords in the URL. It’s ok if the URL becomes slightly lengthy (exact suggested URL length for ideal SEO is yet to be updated here). If you change the URL of an existing case add 301 from the old URL.

You can squeeze in relevant keywords and valuable information in case studies by explaining what we would have done differently if rebuilding the system from scratch. An example for delafee:

When we started working with deLafée back in 2009, the client had a functioning e-commerce solution up and running. It was based on osCommerce, which today is considered an outdated platform. Our job was to customize the application further.
If rebuilding a webshop from scratch today, our first suggestion would be WooCommerce. Alternatively, we would use Opencart or Magento. Read more about our e-commerce services.

Asking clients for an ideal public case study

We can show an anonymized case study (ACS) publicly without asking for permission.

At a suitable time, typically after launch, inform the client of the ACS and ask if we can show a full case study publicly.

An ideal public case study would include: company and project name, a non-blurred logo, testimonial, a profile picture and screenshots/demo. If they are reluctant we can ask if we can publish it if we hide some of the content for example:

show testimonial, profile picture but without screenshots/demo
show testimonial but without profile pic and screenshots/demo
show the project name publicly, but show testimonial/profile pic/screenshots/demo to select prospective clients

The short testimonial length should be four lines in the portfolio listing (approximately 280-350 characters).

Screenshots

You can spend some unbilled hours to perfect layouts before saving screenshots; prospects love to see real evidence of what we’ve done and most would have a detailed look at the screenshots even if they don’t read the whole case. This is another reason why getting a top-end design implemented from the start is so important.

The screenshots that you use for cases can be used during your appraisal to demonstrate what smart functionality that you’ve implemented. Screenshots will as of now only be shown in the password protected case study (EMS).

Through the EMS we will soon be able to hide screenshots and/or testimonial profile picture publicly while keeping them visible in private EMS links. The EMS is yet to be fully developed and will change while we migrate our websites to WordPress.