Real stories

Maya Angelou, civil rights legend and author

People will forget what you said

People will forget what you did

But people will never forget how you made them feel.

The case for something else

• Old fashioned, paternalistic terminology.

• How would you like your story told?

• People’s stories aren’t just useful

collateral to be used.

What I’ll talk about

• What makes a good story • How we identify people’s real stories • How we use real stories • Storing the stories • Drivers for a change • How we found out what we all needed • What we realised we needed • What we learned • Where we are now • Next steps for the MSS

Six ingredients for a great story

• Change/consequence

• A powerful opening

• Direct quotes

• Show don't tell

• Verisimilitude

• Show your reader

• http://www.slideshare.net/CharityComms/six-ingredients-for-great-charity-case-studies

How we identify real stories

• We ask on all our channels

• Regional staff

• Local publications and press

• Personal connections

• Meeting people along the way

• Following up and building on relationships

How and why do we use great stories

• Many departments have the need for great stories

• To inform about our work – through a personal story

• To help people feel less alone

• To engage potential and current supporters

• To sell us in to press and PR

• To show not tell

• Use is dependent on where they are being placed

So, it’s clear we need them, how do we manage them?

Storing the stories

All storing by different methods

• Several departmental Excel spreadsheets

• Raiser’s Edge

• Survey Monkey

A slight improvement

Basic requirements

• NAME • AGE • CONTACT DETAILS • WHERE THEY LIVE • TYPE OF MS • WHEN DIAGNOSED • MORE DETAILS ABOUT STORY AND MS • WHY YOUR STORY? • ACHIEVEMENTS? • WHEN DID WE LAST CONTACT THEM AND WHAT ABOUT?

Drivers for change

• We were overusing some people

• And hardly using others

• No way to store photography with story

• No ‘handler’

• No cross organisational access

• Rubbish data protection

• Who used the story last? What for? When?

This is Shana

In just two weeks…

THREE of our departments asked Shana to :

• Do a TV interview

• Write a blog for the website

• Write a speech, and deliver it to politicians

• Volunteer at the Liberal Democrat conference

So…We

• Started a group of interested people and asked them:

• Why do you use these stories?

• What details do you need?

• What’s important to you?

• Who needs access, and how?

We also asked them

• How often do you use real stories?

• How much info about their MS do you need?

• How are you doing it now?

• What are your issues now?

• What do you think are the potential solutions?

What we realised we needed

A centrally accessible database of stories:

• that was easily searchable

• that could be accessed by designated staff

• Where we could leave notes on the account

• that was designed and supported by clear protocols agreed by everyone

• Where each story was assigned an owner

THE STORY OWNER OR HANDLER

All stories must have an owner or ‘handler’. This is the staff member who manages our relationship with the person. They ensure that:

• Information is accurate and up to date

• Information is used appropriately and in balanced with the needs of the organisation.

• Relevant permissions are sought

• If a user changes role or leaves - ensure they transfer their people to another handler.

We also needed

• To be able to record and maintain all stories

• Allow users to easily find appropriate stories

• Record how and when contact is made and stories are used

• Record - name, contact details, and their story

• Allow users to search, view and create records

• Allow only the ‘owner’ to change records

• Be able to change owner if staff leave

Make a wishlist

• The ability to place details 'on hold'

• The ability to set automatic review dates, which de-activate after set periods of inactivity

• Produce a report on frequency of use

• Authority and permission levels set to allow only certain users the ability to change details

It’s important to

• Identify the issues you have before you start

• Involve everyone

• Keep everyone involved throughout

• Build something intuitive and easy to use

• Make sure from the start that the database is either based on or ‘talks to’ your current database

The benefits

• One method to rule them all

• Every story will be entered in the same way, enabling the search function to work smoothly and quickly

• We can store a photo with the story

• With each story being assigned an ‘owner’ they will be properly managed, and not feel under or overused

• We can properly apply data protection

• Stories can feed into content management, ensuring we use them in a unified way for multiple audiences

Benefits…

• Keep an updated database that everyone can access.

• Ensure people are not being contacted by multiple staff

• Ensure we are not missing out on great stories.

• Ensure searches are easy and quick

• Everyone records when they spoke to person and what about – and everyone can see notes

• No case study will include inappropriate information

• Avoid duplication

Next steps for the MSS

• We now have a final version of the User Requirements document, that everyone contributed to

• We have engaged a developer to build the system. • We had a prototype built and we tested it for functionality • We will look at the architecture of the database and where

and how it will live within our current systems • We are in the process of building the live version

It’s a win-win situation

#CharityCreative

Upcoming events at

CharityComms: www.charitycomms.org.uk/events