--- title: "Content Production Workflow | Orangescrum" description: "Run an editorial calendar where the review stage has to be passed. The roles, the pipeline, the rules that keep it moving." canonical: https://www.orangescrum.com/use-cases/content-production --- # Content Production Workflow | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Use cases](/use-cases) / Content production Use case # Content Production Where _Review Is Not a Black Hole_ An editorial calendar is easy to draw and hard to keep. Almost all the slippage happens in one place, which is a piece sitting with a reviewer who does not know it is waiting. Available in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_content-production)[Book a Demo](https://calendly.com/orangescrum) Runs on Cloud and Self-Hosted · Unlimited users, so freelance writers cost nothing to add ## The scenario You publish eight pieces a month across a blog, a newsletter, and a couple of social channels. The calendar is a spreadsheet, the briefs are in a shared drive, the drafts are in a documents tool, and the review happens over email. Everything works until one reviewer goes on holiday, and then four pieces miss their dates and nobody noticed until the day. Putting the pipeline on a board where review is a visible stage fixes most of that, without anybody having to be chased. Runs Weekly, against a monthly calendar Typical volume 5 to 20 pieces a month Start from Content Management template Owner Content lead or managing editor Who is involved ## Who is _involved_ The reviewer is the role to get right. Everything else usually looks after itself. | Role | What they own | What they see in Orangescrum | | Content lead | The calendar, the commissioning, and the publication decision | The full board and what is stuck in review | | Writer | The draft, to the brief, by the deadline | Their assigned pieces and the briefs attached to them | | Editor | Structure, accuracy, and the editorial standard | Everything sitting in review, filtered to them | | Designer | Images, diagrams, and anything visual | Pieces approved in draft that need artwork | | Subject matter expert | Whether the technical content is actually correct | Only the pieces they were asked to check | | Freelancers | Commissioned pieces, to the same standard and the same board | Their own assigned work | The workflow ## Eight steps from _idea to published_ Step five is the whole thing. Everything else is scaffolding around it. 1. 1 ### Keep a commissioning list, not a wish list Ideas are cheap. A commissioned piece has an owner, a deadline, and a reason for existing. Keep them separate, because a calendar full of ideas tells you nothing about what is actually happening. Carried by[Task management](/task-management) 2. 2 ### Load two months, no more One task group per month, two months ahead. Teams who load six months of planned content spend more time reshuffling it than writing. Carried by[Project calendar](/project-calendar)[Kanban board](/kanban-board) 3. 3 ### Write the brief before you assign it Audience, angle, length, the point it must make, and the two things it must not say. A piece written from a one line title comes back wrong and takes two extra review cycles. - Put the brief in the task description, so the writer never has to ask - Content type, channel, and target date as fields you can filter on Carried by[Custom fields](/custom-fields) 4. 4 ### Set the pipeline stages to your real process The Content Management template starts you on Open, In Progress, Cancelled, Rejected, and Approved. There is no Published stage out of the box, so add one, and add a separate review column if you have more than one kind of reviewer. - Cancelled and Rejected both being present is the useful part, because it lets you close dead work honestly - Statuses can be added or renamed from the board itself Carried by[Custom status workflow](/custom-status-workflow) 5. 5 ### Make review a stage with a time limit This is the step that decides whether your calendar holds. A piece moves into review, the reviewer is mentioned on it, and there is an agreed maximum number of days it may sit there. Anything over that is visible to everyone on the board. - Two working days is a reasonable limit for most editorial review - Feedback goes on the task, so the next reviewer sees what the last one said Carried by[Mentions](/mention)[Collaboration](/project-collaboration-software) 6. 6 ### Put the pre publication checks on a checklist Links checked, images sized and credited, headline and meta description written, internal links added, author byline correct. The same list every time, so quality does not depend on who is publishing. Carried by[Checklists](/checklists) 7. 7 ### Publish, and record it on the card Orangescrum does not publish for you. Publication happens in your content management system, and the card moves to Published with the live link on it, so the board stays a true record of what went out. Carried by[Kanban board](/kanban-board) 8. 8 ### Review the pipeline monthly Not the performance of the content, which lives in your analytics tool, but the performance of the process. How long did pieces sit in review, how many were rejected, and how many were cancelled after work had started. Carried by[Reports and analytics](/project-reports-analytics) Set it up ## Build it _on Monday morning_ Half an hour, and then a month of real use before you change anything. 1. 1Create a project from the Content Management templateIt opens on a board with Open, In Progress, Cancelled, Rejected, and Approved already in place. 2. 2Add a Published statusApproved is the last stage as shipped. If publication is a separate step for you, and it usually is, add it before loading anything. 3. 3Create a task group per monthTwo months ahead. The board doubles as the calendar this way. 4. 4Set the content typesBlog, case study, newsletter, video, landing page, as task types so you can filter the board to one kind of work. 5. 5Agree the review time limitTwo working days is a good default. Write it down, because it only works if everyone knows the number. 6. 6Build the pre publication checklistMake it a reusable checklist group so every piece arrives with the same checks on it. 7. 7Invite the freelancersUnlimited users on every plan, so external writers work on the same board as everyone else. The result ## What good _looks like_ Nothing sits in review unnoticed The review column is visible, and the time limit means anything over it stands out. Writers stop asking what you wanted The brief is on the task, written before the piece was assigned. Dead ideas get closed Cancelled and Rejected are real statuses, so the pipeline reflects what is actually happening. Publication quality is consistent The same checklist runs every time, whoever is on shift that week. The calendar is believable Because it holds two months of commissioned work rather than six months of ideas. You can see where time goes The monthly process review shows whether your bottleneck is writing, review, or design. Watch out ## Where this _usually goes wrong_ Review with no deadline A piece sits with a reviewer for nine days and the publication date passes. ✓ An agreed maximum, and review as a visible column on the board. Briefs that are just titles The draft comes back wrong and costs two extra review cycles. ✓ Audience, angle, length, and the point it must make, written before assignment. Six months of calendar More time is spent reshuffling the plan than producing anything. ✓ Two months loaded, no more. Ideas and commitments mixed together Nobody can tell what is actually in production. ✓ Only commissioned work goes on the board, with an owner and a date. Feedback by email Three versions circulate and the wrong one gets published. ✓ Feedback on the task, so the history travels with the piece. No process review The same bottleneck delays every month and nobody names it. ✓ Twenty minutes a month on how long pieces sat, not on how they performed. Features used ## Everything this _runs on_ [Kanban boardThe pipeline, with review visible](/kanban-board)[Custom status workflowAdd Published and your review stages](/custom-status-workflow)[Project calendarThe month view of what is due](/project-calendar)[ChecklistsThe same pre publication checks every time](/checklists)[Custom fieldsChannel, content type, and target date](/custom-fields)[MentionsSend a piece to a reviewer, on the task](/mention)[Content Management templateThe project template this starts from](/project-templates/content-management)[Marketing teamsHow marketing teams use Orangescrum](/solutions/marketing) Frequently asked questions ## Content production _FAQ_ Which template should a content team start from? Content Management. It opens on a board with Open, In Progress, Cancelled, Rejected, and Approved, which already handles the two unsuccessful outcomes most content boards forget. Is there a Published status? Not out of the box. Approved is the last stage the template creates. Add a Published status from the board if publication is a separate step for you, which it is for most teams. How do I stop pieces getting stuck in review? Make review a column, mention the reviewer on the task, and agree a maximum number of days a piece may sit there. Two working days is a reasonable default. The visibility does most of the work on its own. Does Orangescrum publish content? No. It is not a content management system and it does not publish, schedule social posts, or do SEO analysis. It runs the production and approval process, and the card records the live link once the piece is out. Can freelance writers work in the same board? Yes, at no extra cost. Every plan includes unlimited users and pricing is flat, so external writers belong in the project. Roles control what they can see. How far ahead should the calendar go? Two months of commissioned work. Beyond that, plans change faster than you can maintain them, and the reshuffling becomes the job. What is the difference between Cancelled and Rejected? Cancelled means killed before it was finished, usually because the angle or the campaign changed. Rejected means it was completed, went to review, and did not pass. Separating them tells you whether your problem is commissioning or quality. Can I report on how the pipeline is performing? Yes. Reports show how long work sits in each status, so you can see whether the delay is in writing, review, or design. Content performance itself lives in your analytics tool. ## Put your editorial calendar on a board One pipeline, a review stage with a deadline, and unlimited users on every plan. [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_content-production_cta)[Book a Demo](https://calendly.com/orangescrum) ## Related use cases [Campaign launchThe campaign this content feeds](/use-cases/campaign-launch)[Client onboardingFor agencies producing client content](/use-cases/client-onboarding)[Product launchLaunch content, with engineering attached](/use-cases/product-launch)[Content Management templateThe project template this starts from](/project-templates/content-management) [See all use cases →](/use-cases)