A well-created task answers six questions before the assigned agent has to ask any of them: What needs to be done? Who is doing it? For which client? How long should it take? When must it be done? Why does it matter? A task that answers all six creates a self-contained brief that requires zero follow-up. A task that answers only two or three generates Slack messages, delays, and context lost to memory.

This guide covers every aspect of task creation in RankOps: opening the New Task modal, filling in each field correctly, writing task titles that work, using the description field effectively, creating subtask checklists, logging time, adding comments, attaching Google Drive files, and the task naming conventions that make your board readable at a glance. By the end, every task your team creates will be a complete brief that any agent can pick up and execute without additional context.

Why Task Quality Matters More Than Task Quantity

SEO agencies often measure sprint productivity by task volume: how many tasks were created, how many were completed. But task volume is a vanity metric when the tasks themselves are low quality. A sprint with 30 tasks that are vague, misattributed, missing estimates, and unlinked to goals produces very little useful data. A sprint with 18 precisely defined tasks, accurate estimates, correct goal links, and clear descriptions produces health scores, workload calculations, velocity data, and KPI movement that management can act on with confidence.

The investment in task quality pays compound returns. Every well-created task reduces the manager's time spent answering status questions (because the task itself carries the context). Every accurately estimated task improves workload calculations (because the estimate is real). Every goal-linked task shows up in goal progress (because the system can attribute the work). Quality tasks make every other feature in RankOps work correctly.

The New Task modal can be opened from three locations: the + New Task button in the Task Board toolbar (blank modal, all fields empty), the + New Task button on any Project card in the Projects view (client pre-filled), or the N keyboard shortcut when the Task Board is in focus. Each opening method pre-fills different fields to reduce repetitive entry.

Task Title: The Most-Read Field in RankOps

The task title appears in more places than any other field in RankOps: the Kanban card, the List view, the Calendar, the Dashboard Activity Feed, the Workload view, the Reports table, the RankReport client PDF, and every CSV export. A title that makes sense only to the person who created it is a recurring cost: every other person who reads it in any of these views has to either open the task to understand it or make a wrong assumption about what it means.

The recommended format is: Action + Deliverable + Client identifier. "Audit redirect chains TechNova" tells you in four words what is being done, what the output is, and which client it belongs to. "Fix LCP score mobile pages GreenLeaf" tells you in six words what to fix, where, and for whom. These titles are self-explanatory in any view without additional context.

Poor title formats to avoid: "SEO work" (no specificity), "Fix issues" (which issues?), "TechNova tasks" (tasks is not a deliverable), "Content" (what content?), "Follow up" (follow up on what?). Each of these titles requires the reader to open the task before they can understand anything about it. In a busy sprint with 20+ tasks, this friction adds up to significant time waste every day.

Client / Project Field

The Client field assigns this task to a client project. This is the most important attribution field in the system: it determines which client's health score this task affects, which client this task appears in when filtering the board, and which client this task is attributed to in all reports. Always set this field accurately. A task created without a client attribution or with the wrong client assigned corrupts the health score of both the intended client (task not counted) and the accidentally assigned client (task counted where it should not be).

Assign To Field

The Assign To field can contain one or more agents. All assigned agents see the task in their personal My Tasks filter and receive notification badges for comments that @mention them. When multiple agents are assigned, the task's estimated hours count against each agent's workload percentage in the Workload view. This is intentional: if two agents are assigned to a 4-hour task, both agents carry a 4-hour load commitment in the system, because the actual time division between them is unknown until they log their hours.

Assign tasks to the agent who will actually do the work, not to the manager who requested it. A manager who assigns tasks to themselves because they are the one requesting the work creates misleading workload data: their load bar shows them as overloaded with work they are not actually doing, while the agent actually doing the work shows as underloaded.

Category Field

The Category field classifies the task by SEO discipline: Technical SEO, Content, Link Building, On-Page SEO, Local SEO, or Analytics. This field is used in the Reports category breakdown (showing how your team's hours split across different types of work), in RankAgent's contextual tips (agents working on Link Building tasks get link-specific advice), and in template organisation (templates are categorised by the type of work they contain). Choose the category that best describes the primary SEO discipline required by this task.

Priority Field

Priority (High, Medium, Low) affects two downstream calculations: the overdue penalty weighting in client health scores (High-priority overdue tasks cost more health points than Low-priority ones), and the ordering in agent task lists (High-priority tasks appear first when sorted by priority). Reserve High priority for tasks that directly affect client KPIs or have a client-facing deadline commitment. Medium for important sprint work that is not critically time-sensitive. Low for nice-to-have tasks that can slip without consequence.

The Estimated Hours and Due Date fields are the two fields that most commonly get left blank or filled in inaccurately. Both omissions have significant downstream consequences on the features that matter most for sprint management. This section explains exactly how each field is used, why accuracy matters more than speed, and how to estimate task hours reliably even for work with inherently variable completion times.

Why Estimated Hours Cannot Be Skipped

Estimated hours are the input to the Workload view's load percentage calculation. When you assign a task to an agent with no estimated hours, the task contributes zero to that agent's load bar. The agent appears to have available capacity when they may in fact be fully committed. This creates the exact scenario that the Workload view exists to prevent: an agent takes on new tasks because they appear available, when in reality they are already at full capacity. The first overdue tasks of the sprint appear, and the manager is confused because the Workload view looked fine when the sprint started.

Estimated hours are also shown on the task card as the denominator of the time bar. A card with no estimate shows no time bar at all, which means there is no visual indicator of how much time has been spent relative to a budget. Agents who log hours to an unestimated task are logging into a void: the data is captured but carries no actionable meaning without a baseline to compare against.

How to Estimate Task Hours Accurately

The most reliable approach to task hour estimation is a combination of historical data and task decomposition. Historical data: how long did similar tasks take in previous sprints? If your agency has completed ten Technical SEO Audit tasks and they consistently took 4-6 hours, estimate new audit tasks at 5 hours as a baseline. Adjust up for clients with large, complex sites; adjust down for smaller sites or simpler audits. The velocity chart in the Dashboard Sprint Ring panel provides sprint-level historical data; the time bar on completed task cards provides task-level historical data.

Task decomposition: break the task into its component subtasks and estimate each subtask independently, then sum. A content brief task that involves keyword research (1 hour), competitor analysis (1.5 hours), outline creation (0.5 hours), and brief writing (1 hour) has a more reliable estimate of 4 hours than a single "content brief: 4 hours" estimate made without decomposition. The subtask-based estimation also produces a usable subtask checklist as a by-product, which improves task card readability.

Due Date: The Contract Between You and the Calendar

The Due Date field is where many sprint planning disciplines break down. The most common failure modes: assigning all tasks the same end-of-sprint due date (creating a Friday fire drill), setting due dates without considering task dependencies (impossible sequences where Task B is due before Task A, which Task B depends on), and setting artificially late due dates as buffer (which removes the early-warning value of the Deadline panel).

Set the actual date by which this specific task needs to be complete - not a comfortable buffer date, not a default end-of-sprint date, but the real deadline that reflects both the task's dependencies and any client-facing commitments. If the client expects a technical audit delivered by March 15, and the audit task takes 5 hours, the task's due date should be March 13 or 14 to allow time for In Review approval before the client delivery date. The two-day buffer between task completion and client delivery is not a comfortable estimate buffer - it is a real dependency that the calendar needs to reflect.

The Description field and the Subtasks tab in the expanded task view are where a task transforms from a label into a complete, actionable brief. Most agencies treat these fields as optional extras and skip them under time pressure. This is one of the most expensive shortcuts in SEO agency management, because the cost of a poor description is paid every time the assigned agent needs to ask a clarifying question, every time a manager needs to add context after creation, and every time a task is picked up by a different agent who has zero prior context about what it involves.

Writing an Effective Task Description

A good task description answers four questions: What exactly needs to be produced? What context does the agent need to do the work? What client preferences or constraints apply? Where are the relevant resources? A description that answers all four questions is a complete brief. A description that says "See Slack" or "you know what to do" is a liability that creates dependency on informal knowledge transfer.

Structure your descriptions consistently. Start with the objective in one sentence: "Fix all redirect chains on the /services subdirectory to eliminate the redirect crawl errors flagged in the Screaming Frog audit." Then add context: "The audit found 23 redirect chains averaging 3 hops. The client's web team will implement the redirects on our instruction - do not attempt to implement directly. The site is on WordPress/Yoast." Then add client preferences: "Client has requested all redirects go to the /services parent page, not to individual subpages, for simplicity." Then add resources: "Screaming Frog export is in the Google Drive folder linked in the Files tab. Previous technical audit PDF is also there for context."

This structured description takes three to four minutes to write and saves ten to fifteen minutes of back-and-forth clarification for every agent who works on it. For a task that is later picked up by a different agent because the original was reassigned, it may save an hour of reconstruction work.

Creating the Subtask Checklist

Subtasks are step-by-step checkboxes within the task that break the deliverable into discrete, independently trackable steps. They serve two distinct purposes: operational guidance (they tell the agent exactly what steps to complete, in sequence) and progress visibility (the 3/5 subtask ratio on the collapsed task card tells any observer how far through the task the agent is without opening it).

Add subtasks to any task with more than two distinct steps. A content brief task might have subtasks: (1) Research primary and secondary keywords, (2) Analyse top 3 SERP competitors for this keyword, (3) Create content outline with heading structure, (4) Write the brief document with all sections, (5) Share brief link in task Comments. A redirect audit task might have: (1) Export Screaming Frog crawl, (2) Filter for 301/302 chains, (3) Document each chain with from-URL, current destination, and correct destination, (4) Share documented redirect map with client web team, (5) Log client confirmation receipt in Comments.

The level of subtask detail should match the task's complexity and the agent's experience with this type of work. For a highly experienced agent doing a routine task type they have done twenty times, detailed subtasks may be unnecessary overhead. For a newer agent doing a task type for the first time, granular subtasks are a training tool as much as a progress tracker.

The three tabs inside the expanded task view, opened by clicking any task card, provide the complete task lifecycle management interface: Subtasks (task steps + time logging + status controls), Comments (team communication and @mention notifications), and Files (Google Drive attachments). Each tab serves a distinct function in the task workflow. Understanding all three and using them correctly keeps all task-related context in one place, accessible to anyone on the team at any time.

The Subtasks Tab: Progress, Time Logging, and Status Control

The Subtasks tab is the primary working interface inside a task. The top section shows the subtask checklist with checkbox controls. Checking off a subtask updates the progress ratio (e.g. 2/5 to 3/5) immediately, which is reflected on the collapsed task card in the Kanban board visible to all team members. The agent does not need to communicate "I finished step 3" to the manager - the updated ratio on the card communicates it automatically.

The time logging section appears below the subtask checklist. Five quick-log buttons (+0.5h, +1h, +2h, +3h, +4h) allow single-click time entry for the most common logged durations. A custom hours input field handles any other duration. Clicking Log adds the hours to the task's total immediately and updates the task card's time bar. Log time as you complete each work session rather than accumulating and logging at the end of the week. End-of-week time logging consistently produces inaccurate data because of memory compression: half-hour tasks get logged as one-hour tasks, two-hour sessions get forgotten entirely.

The Move To row shows all statuses except the current one as buttons. This is the most efficient way to change task status when working within the expanded view: click the target status and the task moves immediately. No need to return to the Kanban board and move the card to a different column.

The Comments Tab: Task-Specific Communication

The Comments tab is a threaded discussion attached to this specific task. Every comment is timestamped and attributed to the commenter. Use @mention syntax to notify a specific agent: @AgentName highlights in violet and triggers a notification badge on their notification bell icon. Use @here to notify all agents assigned to this task. All task-specific communication should happen in the Comments tab, not in Slack, not in email, not in a shared document margin. When communication happens in Comments, anyone who opens the task six weeks later sees the complete conversation in context.

The Files Tab: Google Drive Integration

The Files tab stores Google Drive links attached to this task. Each link shows the file name and its type icon. Clicking the link opens the file directly in Google Drive. Files are not uploaded to RankOps - they remain in Google Drive with access controlled by Google Drive permissions. Share the Drive file with the appropriate team members before linking it to the task.

Use the Files tab to attach: the client brief document for content tasks, the Screaming Frog export for technical tasks, the outreach tracking spreadsheet for link building tasks, the keyword research document for on-page tasks. When all relevant files are linked from the task, every agent who works on it has immediate access to everything they need from a single location.

Time logging in RankOps is one of the most underutilised and highest-value habits in the platform. Most agencies track time loosely, if at all - a rough estimate in a spreadsheet, a Harvest or Toggl entry that may or may not correspond accurately to a specific task. RankOps makes time logging part of the task workflow rather than a separate administrative step, which dramatically improves both adoption and accuracy.

Why Accurate Time Logging Matters

Time data in RankOps flows into three places: the task card time bar (showing hours logged vs estimated), the Workload view's utilisation calculation, and the Reports view's "Hours Logged vs Estimated" column. Each of these downstream features is only as useful as the accuracy of the time data that feeds them. Inaccurate time logs produce misleading workload data, incorrect utilisation rates, and a Reports view that cannot reliably answer the question every agency owner asks: are we delivering efficiently relative to the retainer value?

The Time Log Quality Habits

Log time immediately after each work session, not at the end of the day and definitely not at the end of the week. Research on time tracking accuracy consistently shows that same-session logging is significantly more accurate than retrospective logging. The error in retrospective logging is not random; it is systematically biased toward under-reporting short sessions and over-reporting longer ones. A 25-minute session logged immediately produces a log of 0.5 hours. The same session logged at end of day may produce 1 hour because the memory of the session has expanded.

Log time to the specific task where the work happened, not to a generic client task. If you spend 45 minutes answering client questions about their backlink profile, log that time to the specific backlink-related task or create a "Client communication" task for the client and log it there. Time logged to the wrong task (or not logged at all) degrades the reporting data that management uses to understand service delivery costs and margins.

Using Time Data for Retainer Profitability Review

The Reports view's Hours Logged vs Estimated column, combined with the client's MRR value, enables a retainer profitability analysis that most agencies cannot perform without significant manual data work. When hours logged consistently exceed hours estimated for a client, either the estimates are wrong (fix the estimating process), the scope is expanding without a retainer adjustment (have a scope conversation with the client), or the work is taking longer than expected (investigate root causes). All three situations benefit from data-driven conversations rather than impressionistic ones.

The most important task management principle in RankOps is simple but requires consistent discipline to maintain: every task should be a complete brief, every brief should be in the task, and every piece of communication about the task should be in the Comments tab. This principle, applied consistently across the entire team, transforms the Task Board from a tracking tool into a knowledge management system where all institutional knowledge about client deliverables is searchable, attributable, and permanent.

Building a Task Template Library for Consistent Quality

While RankOps Templates handle task creation at the sprint level (generating multiple tasks from a predefined set), you can create personal or team-level task description templates for commonly repeated individual tasks. A text document with standard descriptions for your ten most common task types - technical audit, content brief, backlink prospect research, on-page title tag audit, etc. - allows any team member to paste a complete, structured description into the description field in seconds rather than writing one from scratch each time.

Standardised descriptions for common task types also enforce quality consistency across the team: every content brief task created by any team member includes the same required sections (keyword data, competitor analysis, outline, client preferences, file links). This consistency makes the In Review step significantly faster, because the reviewer knows exactly what a complete content brief looks like and can verify completeness against the standard rather than against their own judgment about what "complete" means.

Task Communication Etiquette: Comments vs Slack

One of the most common workflow breakdowns in agencies using project management tools is the split between tool-internal communication and Slack communication. An agent who has a question about a task sends a Slack message. The manager responds in Slack. The answer is now in Slack, not in the task, and is invisible to anyone who opens the task later. Two weeks later, a different agent picks up the task, has the same question, and sends another Slack message. This cycle repeats indefinitely because the answers are never recorded in the canonical location: the task's Comments tab.

The rule to enforce: any communication about a specific task belongs in that task's Comments tab. Slack is for urgent, real-time communication that needs a faster response than a task comment notification. "Are you available for a quick call in 10 minutes?" is a Slack message. "I had a question about the redirect audit task - should the redirect map include 404s as well as redirect chains?" is a task comment.

The Task Quality Audit: A Monthly Practice

Once a month, spend fifteen minutes on a Task Quality Audit: open the Task Board in List view, sort by Created Date, and review the ten most recently created tasks. For each one, check: does the title follow the Action + Deliverable + Client format? Does the estimated hours field have an accurate value? Does the task have a due date? Does the description answer all four questions (what to do, context needed, client preferences, resource links)? Does the task have a goal link?

Any task failing more than two of these five checks is a low-quality task. Identify who created it and make it a coaching point in the next 1:1: not a disciplinary issue, but a specific, data-based conversation about the business cost of low-quality task briefs. After two or three months of consistent audits, task quality across the team improves to the point where the audit rarely finds failures, and the coaching conversations shift to refining and maintaining an already-high standard rather than correcting basic omissions.