• Share
  • Email
  • Embed
  • Like
  • Private Content
Building a case study database

Building a case study database



Sarah Westlake, senior editor at MS Society talked about improving processes the MS Society used to have to identify case studies, and the brilliant new database being developed. She explained how ...

Sarah Westlake, senior editor at MS Society talked about improving processes the MS Society used to have to identify case studies, and the brilliant new database being developed. She explained how they got started, who they got involved, and what they have learned along the way so far.



Total Views
Views on SlideShare
Embed Views



1 Embed 199

http://www.charitycomms.org.uk 199



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Building a case study database Building a case study database Presentation Transcript

    • 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/sixingredients-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
    • 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
    • Upcoming events at CharityComms: www.charitycomms.org.uk/events #CharityCreative