2 registered users
in last 24 hours
How to write a Success Story
"Success stories" are an important marketing tool for ]project-open[. Success stories are usually directed towards potential customers who seriously consider using ]project-open[ for their organization. The success stories provide these readers with real-world examples, and help them to set expectations in terms of implementation time, budget etc. The readers are usually the managers or owners of service organizations.
This HowTo provides some hints to ]po[ partners and customers on how to write a good success story that may be included in the Customers section.
Success Story Formats
There are several formats suitable for publishing successful ]po[ implementations at [www.project-open.com/en/customers]:
- 2-Page Format:
This is the "standard". It will take several days to write such a story. In exchange there will be several hundred qualified leads reading the story every month.
Examples: EconoMedic and VAW-arvato
- 1-Page Format:
This short format requires less then a day to write and approve.
- Press Release:
This format describes the rollout in a format suitable for publishing in industry magazines etc.
- CEO Sound Bite:
A one or two paragraph text from a customer summarizing the project.
In the following sections, we will describe the full "2-Page Format". However, the same principles hold for the shorter format.
In ]po[ we encourage success stories that take on different "themes" - talking about the specifics of a customer rollout. Otherwise all success stories would similar.
The "theme" of a success story is a particular aspect of a rollout that is emphasized. Themes frequently correspond to a ]po[ process that is particularly important for the customer. Alternatives for themes are particular difficulties in a rollout that have been successfully overcome.
The theme is important for Search Engine Optimization (SEO): A document that consistently talks about one area will be recognized by Google as belonging to that area and receive a "usefullness" extra score. To optimize this recognition please research the theme, please create a mind-map of concepts around the theme (looking up the term in Wikipedia), use these concepts throughout the success story and explain these concepts in terms of the actual implementation.
If possible, try to include the theme in the name of the success story and in links pointing to the success story for SEO reasons.
Example of themes in past ]po[ success stories:
- Resource Management in Healthcare Consulting (Economedic)
- Seamless collaboration between external and internal workers (VAW arvato)
- Profit Center Financial Management (Lexcelera)
- Professional Services Management (Cambridge Technology Partners)
Customer Quotes and "Sound Bites"
Another important input for the success story are quotes and sound bites from your customers. Ideal quotes express the application's benefit for the customer using simple and authentic language.
It is a good practice to collect quotes already during the rollout, because quotes can't easily brainstormed afterwards. These quotes can provide an important guide, some success stories are written around these quotes.
A success story is actually composed similar to a Hollywood plot:
- The Hero:
The hero corresponds to the customer organization who is the protagonist of the project
- The Initial Situation:
The initial situation is usually unsatisfying for the hero.
- "Pain points":
The pain points of the initial situation are the reasons why the hero has started his quest - the real reasons behind selecting and purchasing ]project-open[. The pain points are worth telling because this pain must exceed the cost and and psychological stress associated with implementing a new ERP system...
- The Quest:
The quest corresponds to the rollout project. During the quest, the hero will face a number of challenges or "adventures" that he will finally overcome. Surprises may occur.
- Happy End:
At the end, the hero has managed to create a new stable environment that is better then the initial situation.
Success Story Sections
Usually, a success stories usually consist of the following section, and roughly in the following order:
- The Customer:
Describing the customer's organization and the past success for the customer
- The Challenge:
What are the pain points in the initial situation?
- The Solution:
How was the Challenge resolved?
- The Theme:
Present the theme in detail. You may provide an example, layout a bit of general business theory about the theme, explain design considerations and alternative approaches, and why these alternatives where not chosen.
- The Implementation:
Explain the "adventures" that the hero experienced when leaving the initial situation. How did the hero overcome the difficulties?
Explain the planned and surprising/unplanned advantages of the new final.
- The Implementation Provider: (optional)
Describe yourself (the ]po[ partner's organization) and why you were the right people to help the customer to successfully complete the quest.
The process of releasing a success story can be a surprisingly long and painful. Basically, you will have to ping-pong the story between your customer, yourself and your copy editor (see below) until it is OK for everybody.
This process can take surprisingly long, because it usually involves the highest level managers in the participating organizations. Here are a few hints:
- Start Early:
Start to mention the plan to write the success story to your customer already before and during the rollout. At this moment, the customer will promise you to do everything... After the successful rollout the customer will be busy again with his own business and will be very reluctant to invest time in seemingly 2nd priority activities like writing success stories.
- Quotes and Sound Bites:
Start collecting quotes, sound bites and general ideas for the success story during the rollout. It's very difficult to invent quotes after the project.
- Bullet Points:
Start writing bullet points at first. Concentrate on what you want to tell, instead of looking for elegant formulation.
- Send Draft Early:
Check your bullet point draft with your customer (including the customer's marketing department!) to get an informal OK.
Involving the customer in this early stage will greatly simplify the approval process later.
Use a copy-editor to produce professional language if you feel clumsy with language or if you are a non-English native like myself. You can hire a copy editor for USD 15-25 per hour to fix your text or even to convert your bullet points into fluid language.
- Customer Contact:
Make sure to collaborate with a language-savvy consultant-level employee from your customer's organization for the first and second iterations of ping-pong. Senior managers won't have enough patience for the process.
- Approval Plan:
Try to get approval from parties with more slack time/patience before going for the approval from more stressed managers. Try to lay out an approval plan during the last days of the rollout.
General Comments and Hints
- Be authentic and use authentic language. You obviously have to avoid negative terms to describe the initial situation, but it is OK to mention the difficulties that occurred during the rollout. Everything else wouldn't be credible.
- Start laying out the success story with a list of bullet points. Concentrate on what you want to tell, instead of looking for elegant formulation.
- Please use the standard ]po[ Success Story template (contact email@example.com). It's a PowerPoint document in DIN A4 format. We have chosen PPT because it allows for DTP-like layout, while being commonly available.
- Please use a high-resolution logo of the customer. Low resolution logos will be perceived as unprofessional by professional readers.
- Remember to collect customer quotes during the project. Ask during a dinner towards the end of the rollout: "What do you think are the main advantages for you from using ]po[?"
- Reserve sufficient time for the approval process and track the approval process like a sales pitch. Getting approval may easily take several months because of the slow reaction times of the involved managers.