A company’s marketing blog is typically a team effort that includes members of the marketing team, designers, and technical writers who work on product development teams. These participants may be distributed across multiple offices and countries, and therefore rely on online collaboration tools for collaborative writing. Writing tools don’t usually have any task management support.
Form – a proposal for a new blog post that describes who will write it and what it will be about.
The process consists of two phases of approval and content creation tasks, followed by a result notification.
The process starts with a, followed by a if the proposal is rejected. Note that the Approve content approval is simplified to a single task, and doesn’t use an explicit decision and loop back to the Write article task. Instead, corrections at this stage are handled informally, via comments on the case view.
Note that Select stock photo is a sub-process, rather than a single task. This allows the design team to design and manage their own process for selecting photos and other illustrations for blog posts. This sub-process proceeds in parallel while the author writes the article, based on information in the article proposal.
The process ends with athat sends the published article’s title and URL to the whole company.
Each blog post involves four different people, in different roles, from the larger team.
- Author – Triggers the process by submitting an article proposal, writes the article content, and publishes the article using the blog’s content management system (CMS). For some blog posts the author is a technical writer from one of the product teams.
- Content Manager – Performs the two approvals – the initial article proposal and the finished article content.
- Copy Editor – A member of the marketing team, who is a native English speaker, who reviews and corrects the draft article.
- Designer – A member of the marketing website design team, who selects stock photography or other illustrations for the article.
The process defines a number of variables, which capture the data for each case (each blog post). All but one of the fields first appear on the trigger form, and make up the blog post proposal.
- Author – The role described above, selected here manually because it is a and might not be the same person as whoever submits the proposal and starts the case.
- Title – The article title, which identifies the case in Signavio Workflow’s .
- Category – Indicates whether the blog post is intended for the Corporate Blog or the Applied BPM & DMN blog.
- Description – Describes the article’s topic, so the design team can select a suitable photo without having to wait for the final article text.
- Planned publication date – Allows the Content Manager to position the blog post in the publication schedule.
- Draft blog post – The URL of the draft article in the online collaboration platform. The author may already set this on the trigger form, at the proposal stage, if there is already an article outline.
- Published URL – The URL of the published article on the Signavio website, used to share the published article. This is the only field that is not present on the trigger form, as it is only set at the end of the process in the publication task, and used in the final notification.
The process model shown above is a simplification of the complete process. For example, the model does not include the social media marketing tasks that the Social Media Manager performs.
There is currently no integration between the workflow and the two external systems: the online collaboration tool used for writing draft articles, and the CMS where they are published. In principle, it would be possible to automatically generate an empty draft article in the first system when the process starts, and automatically push the draft article to the CMS when it is complete. For now, at least, these tasks are not frequent or time-consuming enough to make this worthwhile.
A marketing content publication process, such as for a blog, perfectly exemplifies a business process that benefits from workflow automation for a number of reasons.
- Each case involves a number of people, who don’t sit in the same room.
- Each case requires management approval.
- The Content Manager needs an overview of open cases.
- Each case has required information and required steps.
- The exact process model is too company-specific for a generic task management system or CMS workflow to be suitable.
- The Content Manager needs to be able to regularly implement process improvements, without depending on external help.