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.
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:
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.
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 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
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.
See content marketing guidelines.
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:
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.
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.
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.
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:
The short testimonial length should be four lines in the portfolio listing (approximately 280-350 characters).
More on asking favors of clients here.
When you publish a new case study, consider what other content needs to be updated. Examples include but are not limited to:
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.