WO2014146189A1

WO2014146189A1 - Contextual social content creation and optimized push-broadcast scheduling

Info

Publication number: WO2014146189A1
Application number: PCT/CA2013/050234
Authority: WO
Inventors: Gary MACGREGOR
Original assignee: Macgregor Gary
Priority date: 2013-03-21
Filing date: 2013-03-21
Publication date: 2014-09-25

Abstract

The invention provides a system and methods for teams to create contextually relevant versions of social content, in series, for multiple social networks at dates/times based on dynamically built schedules patterned on communication type. User selects team, communication type, social channel(s), posting type; chooses start date/time, and sets variables upon which the system determines a proposed schedule. Various team content resources, categorized by context (team, brand, channel, topic, etc) and pre-packaged content in series, with content input fields and suggested date/time are presented for the first message in a series. After edits, the user saves content for 'review' or 'publishing'. This process is repeated for all anticipated messages and, pending posting type selected, all selected channels. The user can cancel anytime. The user populates a plurality of third-party polling applications that post to social networks with urls (created during setup). The invention accomodates contraints of these applications.

Description

CONTEXTUAL SOCIAL CONTENT CREATION AND OPTIMIZED PUSH-BROADCAST SCHEDULING

Background of the Invention

Conventionally, users of social networks create their messages one at a time in the social network's interface or use a similar interface provided by a social network posting applications (dlv.rt, Buffer , etc.) or administation applications (Hootsuite, Gremln, SproutSocial, etc.). There is also a new class of posting application, represented by ifTHISthenThat and Zapier, that allows users to create functional triggers .e.g 'If new item in an RSS feed then send the message to FaceBook'. Social networks, themselves, can be considered posting apps.

There are some existing mechanisms that allow a user to publish to a schedule. Most systems will poll RSS feeds and publish new content as it is found. Some allow users to place messages on a schedule one at a time and some allow users to manually import a series of messages with publishing date and time into a schedule. Some accept email submission. A very few actually publish to a schedule but these do not provide functionality to assist in creating that schedule (e.g Wordpress).

With the exception of Wordpress , polling intervals are typically system wide. For example, Buffer polls every 6 hours, Hootsuite every hour, Zapier is either every 15 minutes or every 5 minutes. With exception (e.g.Zapier, Wordpress), these applications have arbitrary constraints on the number of messages that they will accept at one time. None facilitate the creation of messages (content) in a series. None provide a means to categorize series of messages.

While all declare support of the current RSS specification or provide a naming convention for input, few support all RSS content tags when creating posts from polled content.

There are some mechanisms that provide minor scheduling assistance. The two most prevalent are drip scheduling that sets a threshold for the amount of time that must elapse between one post and a subsequent post and systems that attempt to determine the best times of day to post and then schedule post during those periods. There are some systems that take 'days off' into consideration (i.e they won't post during given periods) and some systems that let you select days to post. These functionalities can be combined. Only a few enable recurring messages but still require that the user retrieve the message from the schedule in order to edit it. (e.g. Change 'the event is a week away' to 'the event is a day away'.) None facilitate the selection of dates for a series of messages (content).

Analytical functionality is considered relatively strong and may include integration of google analytics, Facebook insights, custom reports etc. While the data collected includes much detail and data export is typically available, and while these systems advise the use of detail information in message creation, little or no assistance is provided to facilitate the ongoing use of details. That is, if you see a detail you are interested in using in content, it is relatively easy to create a single message, immediately, that includes the detail, but there are no mechanisms to store details in a list (with annotation) for future use by the user or others.

For example, while social network applications track mentions, they do not provide a mechanism that stores annotated links in list form in order to facilitate the inclusion of such links in messages. ( e.g. Thanks to @myname... ; Our contest winners are @hisname, @hername ...). Systems also do not provide a list of personal or authorized corporate links that would be used frequently. And, while, for example, integration of tools such as trendspottr help identify effective hashtags to include in messages, no mechanism exists to make it easy to store and retrieve identified hashtags at a later date. Existing systems seem to expect that use of details is required only at the moment in time when the detail is recognized as valuable.

While social media analytics are important, existing systems do not implement fields that allow users to import actionable material from other corporate resources. For example, a sales database is likely to contain the names and links for influentials in the company's marketplace. There is no structured storage of often used types of content elements.

Similarly, social networks and administrative systems have strong real-time collaboration functionality and robust organizational and team permission management, but are lacking in mechanisms that communicate requirements over time. For example, it is easy to send a request to a team member to respond to a post but there are no data fields to house ongoing direction (guidelines) and so communication of this sort is relegated to sending a message or having a meeting. There are no mechanisms to facilitate the use of brand language

With regard to content creation, these applications are primarily real-time focussed, and single message centric. What is missing is a tool that facilitates the creation of contextually relevant content in advance of its publishing date.

Use Case

A busy 3 person marketing team, and their Manager, manages 8 accounts on 5 social networks (e.g. Twitter, FaceBook, LinkedIn, Instagram and delicious) for 2 brands. As well, they ghost write for the social accounts of the CEO and several corporately sponsored accounts (e.g for Chefs, Technologists, Consultants). The team believes that content needs to be 'new', interesting, relevant and formatted in the language of the channel (e.g. Re-Tweet this vs share this). They must write in a manner that maintains brand identity and, as well, in ways that reflect the tone (voice) of each individual.

They use a Social Network Adminstration System effectively for monitoring, creating ad-hoc content and for real-time collaboration , but still they face pressure to do more. They're not sure that they have enough time to do so. They are busy. They know the strategies but don't seem to have the right tools to help them execute.

These include:

Expanding the number of social channels and corporately sponsored accounts they employ.

The challenge is simply time.

A reasonable, minimum volume of content elements that the team should create each day is 3 * 8 (for managed accounts) plus 1 * 4 (for corporate sponsored accounts) = 28 pieces of content per day. In addition to this, there is a prevailing 'tit for tat' attitude that requires them to share partners content in order for partners to share their content. Ideally, for the channels and accounts they currently support, this volume would be marginally higher, perhaps 36 content items per day. (Because of the volume of messages and follower habits, many messages are not seen, however, there is a also a volume threshold above which followers percieve that messages have become spam.). The problem is that, in order to avoid a situation where there is more harm than good when adding social networks or accounts, the team needs to commit to generating a minimum volume of content and/or commit the time needed to liase with new stakeholders.

Support field efforts.

The challenge is functionality.

While the team knows that field staff (sales people, service personell, department heads) are a tremendous market information resource and also the best way to identify clients and potential clients that should be acknowledged socially, they find that, for the most part, communication between the team and field staff flows one way. The team finds it easy to task field staff (e.g. 'Please respond to this message') but, unless the team is able to act on staff input immediately, the input often gets side aside and forgotten. They just don't have a tool to organize input so that it is readily accessible when they need it.

Build partnerships.

The challenge is actionable communication.

Even though the company has quite a few marketing promotion partnerships with suppliers, franchisees, complimentary services, etc. , the team works closely with only a few. They have productive meetings, converse online and seem to make effective plans. But execution seems to be wanting. One partner eats up a lot of time trying to make the partnership content exactly right for their specific audience, they all issue uncommented Re-Tweets more often that they know they should and, worst of all, the partners seem to forget the brand standards. It seems they spend more time talking than doing.

Recruit influentials, acknowledge followers.

The challenge is repetition.

In their marketplace, there are a number of established influentials (e.g. bloggers, senior executives), and an ever changing number of interested parties (e.g. followers, mentioners., etc.). The team does a great job acknowledging positive posts or clarifying negative ones; announcing winners and, in general, dealing with anything in real time. The problem is, that once the team has mentioned someone, they're not likely to mention them again until that person does something else to put them self on the team's radar.

Repetition of key messages in different and compelling ways.

The challenge is to find a way to avoid the inordinate amount of time scrolling through old messages to recover links and content threads. )

Use hashtags more effectively

The challenge is functionality to organize input so that it is readily accessible when needed.

Integrate social media into the larger marking plan

The challenge is to stop planning on the fly and find a tool that easily builds content on a campaign-like schedule.

The team finds itself in a position where its efforts are, for the most part, reactive. They need a tool that helps streamline and increase the quality of interactions with partners, facilitates customization of 3'rd party content and enables them create more 'good' content, in less time.

Field of the Invention

The invention relates generally to media presentation, and more particularly to systems and methods for producing volume content for a number of social network environments using dynamically selected media content resources.

Brief Description Of The Drawings

FIG. 1 is a Flow Chart of the primary interface

The embodiments of the invention in which an exclusive property or privilege is claimed are defined in the following Claims section.

Claims

1-I claim a method, comprising:functionality to generate a date/time schedule based on a chosen communication type.

2-A method of claim 1, comprising:user selection of team; user selection of a communication type; user choice of one or more target channels; user setting of the number of messages in a series to be created ; user selection of posting type; user setting start date and time for the schedule ; in somes cases, user setting an end date or, alternatively, day(s)/times(s) (Fig 1 Steps 4 & 5).

3-A method of claim 1, comprising, functions to calculate a schedule (Fig. 1, Steps 6 & 15) based on communication type, start date, number of messages (calculated or entered by the user) , duration (calculated from start and end date or entered by the user) and/or day(s) of the week selected.

4-A method of claim 1, comprising: for promotional communications, a function to calculate a schedule that increases message frequency naturally (for example logarithmically), as a milestone date gets closer, in order to mirror typical, real-world campaign planning.(Fig 1, Steps 6 & 15).

5-A method of claim 1, comprising: storing in a database a plurality of identifiers of posting applications, with attributes and 'intervals' that designate the options that a posting application offers to set polling frequency (for example, polling an RSS feed) and/or the time/volume constraints of automated, programmatic data input (e.g. The maximum number of emails that update or edit records per period of time) (Fig 1, Step 29)

6-A method of claim 1, comprising: for conversation communications, a function to calculate a schedule that adjusts the interval between messages in a pseudo random manner (Fig 1, Steps 6, 15 & 14) or adjusts a schedule sets the interval between scheduled items relative to a posting applications 'intervals' (Fig 1, Steps 29 & 19), in order to mirror typical, online or system behaviour.

7-A method of claim 1, comprising: for conversation communications, a function to set the author of each message based on user input. (Fig 1, Steps 25,26 ,27 & 28).

8-A method of claim 1, comprising: for periodical communications, a function to calculate a schedule that schedules messages on one or more days of the week over a given period (number of weeks) (Fig 1, Steps 6 & 15).

9-A method of claim 1, comprising: storing in a database a plurality of identifiers that designate a user or brand as a member of a team(s) (Fig 1, Step 21).

10-A method of claim 1, comprising: storing in a database a plurality of identifiers that designate a user as team leader of a particular team (Fig 1, Step 21).

11-A method of claim 1, comprising: functionality that enables team leaders to invite a user to join a team and enables users to accept or reject the invitation (Fig 1, Step 22).

12-I claim a method, comprising:functionality to iteratively present to a user, for each message in a series based on selected posting type, such that, upon selection of posting type 'rePost' (Fig 1, Steps 7 & 12) (defined as identical content to all channels selected), the user will be presented with a single opportunity to create content for each 'message in a series', thereby providing saved content in the form of Message1-Channel1, Message1-Channel2 and Message2-Channel1, Message2-Channel2 (Fig 1, Steps 11 & 17) ; while upon selection of posting type 'postMix' (defined as modified content to each channel selected) (Fig 1, Steps 7 & 12), the user will be presented with opportunities to create versions of the content for 'each channel', for each 'message in a series'; thereby providing saved content in the form Message1a-Channel1, Message1b-Channel2 and Message2c-Channel1, Message2d-Channel2 (Fig 1, Steps 11, 13, 14 &15).

13-I claim a method, comprising:functionality that presents contextually relevant content resources (as described in Lines 15 through 23, below and now referred to as systemContent) to users when creating content (Fig 1, Step 10).

14-A method of claim 3, comprising, functionality that allows users to review attributes of systemContent entries (e.g text, notes, links, etc.) and choose attributes, such as 'link' or 'name and link' or 'text content', etc., to be automatically pasted into content input fields, and at selected points within a content input field, as a user creates content (Fig 1,Step 10).

15-A method of claim 3, comprising, functionality to associate data entries for various categories of systemContent with a user, brand or team in order to establish team and user context (Fig 1 Step 9).

16-A method of claim 3, comprising : storing in a database an identification of a plurality of links (urls) with attributes and notes that may provide guidelines for their contextual use. (Fig 1, Step 9)

17-A method of claim 3, comprising: storing in a database an identification of a plurality of feed links (now referred to as feeds) with attributes and notes that may provide guidelines for theircontextual use. (Fig 1, Step 9)

18-A method of claim 3, comprising : storing in a database an identification of a plurality of notes that may provide guidelines for contextual use of content developed in a 'brand' context. (Fig 1, Step 9)

19-A method of claim 3, comprising: storing in a database an identification of a plurality of user's phrases and/or brand taglines (now referred to as voiceBites.) (Fig 1, Step 9)

20-A method of claim 3, comprising: storing in a database an identification of a plurality of identifiers of people, with attributes and notes that may provide guidelines for their contextual use (now referred to as payForwards) and who the user or brand is interested in cultivating as a supporter. (Fig 1, Step 9)

21-A method of claim 3, comprising: storing in a database an identification of a plurality of identifiers of people, with attributes and notes that may provide guidelines for their contextual use (now referred to as payBacks) who have done something for the user or brand (mentioned the company or is a friend, etc.). (Fig 1, Step 9)

22-A method of claim 3, comprising: storing in a database an identification of a plurality of hashtags with attributes and notes that may provide guidelines for their contextual use. (Fig 1, Step 9)

23-A method of claim 3, comprising: storing in a database an identification of a plurality of category labels (now referred to as hallMarks) with attributes and notes that may provide guidelines for their contextual use. (Fig 1, Step 9)

24-A method of claim 3, comprising: functionality to manually enter, using a web interface or mobile app, and bulk import from a common format (e.g. csv) each type of systemContent as described in Lines 15 through 23, above. (Fig 1, Steps 21 & 24) .

25-A method of claim 3 comprising: functionality to control access and editing permission of systemContent by user and by team (Fig 1, Step 22).

26-I claim a method, comprising:functionality to create and share pre-packaged 'content in series' and associated content resources for the purpose of creating new content.

27-A method of claim 4, comprising: storing in a database a plurality of identifiers that assign to a user (recieving user), pending their acceptance, access to a series of content (now referred to as a smartCollection) that has been created by an 'orginating' user, and includes the content that would be posted to a social network and publication date/time and including brand notes, links and voiceBites as designated by the 'originating' user. (Fig 1, Step 22).

28-A method of claim 4, comprising: functionality to associate a hallMark with a content record during content creation or subsequently and programmatically (Fig 1, Step 22.

29-A method of claim 4, comprising: User interface functionality that allows a user to accept access to a smartCollection (Fig 1, Step 22) and assign it to a team (Fig 1, Step 21).

30-A method of claim 4, comprising: User interface functionality that allows a user to select a communication type of smartCollection and then choose a smartCollection that has been assigned to the team ; wherein; from a presentation of the smartCollections messages (including associated dates and times) and brand notes, links and voiceBites, the user may review and select contextual content to be included in the content they create for themself. (Fig 1, Step 10).

31-A method of claim 4 comprising: functionality to export a smartCollection to a common file format (e.g. csv, etc.) in order to send it to external partners, who are not users, for editing or review (Fig 1, Step 23).

32-A method of claim 4 comprising: functionality to import an edited smartCollection from a common file format (Fig 1, Step 23) .

33-I claim a method, comprising:functionality to generate a plurality of RSS feeds (push-broadcasting )that contain the appropriate scheduled content for all channels, individually, adjusted to accomodate channel constraints (Fig 1, Step 19).

34-A method of claim 1, comprising: storing in a database a plurality of attributes of posting applications, that designate the content schema used by a posting application when polling or when data is programmatically input (Line 34 & 35), and/or designates particular functionality of the posting application ( Line 36) .(Fig 1, Step 29)

35-A method of claim 5: wherein, posting applications vary in their support of publication date and the number of new messages accepted each time they poll and as each application may poll at different intervals ranging (currently, from 5 minutes to 6 hours), functionality comprising: the ability to process the message database in manner that provides, a feed , at time of polling, that is optimized for quantity of new content and the stored publication date/time for each content record (Fig 1, Step 19A).

36-A method of claim 5, comprising: functionality to merge content fields or include or exclude fields and adjust other RSS format options for a particular channel when generating a feed (Fig 1, Step 19B).

37-A method of claim 5: wherein, specific channels have settings that govern their polling schedule (drip functionality, number of messages that can be concurrently posted and whether date/time is considered when posting); functionality that accomodates these constraints (Fig 1, Step 19B).

38-I claim a method, comprising:functionality to generate a csv for download containing the appropriate scheduled messages for the each channel selected Step (Fig 1, Steps 23 & 19).

39-A method of claim 6 comprising: functionality to merge content fields or include or exclude fields and adjust other format options for a particular channel when generating an export file (Fig 1, Step 19B).