A client sends a homepage revision in chat. The designer reads it, the developer assumes someone else owns it, and the project manager asks for an update two days later. Everyone has communicated. Nobody has made the next action unambiguous.
For a small digital agency, that is often the real task-management problem. Another messaging channel will not fix it. A useful workflow needs a named owner, a concrete deliverable, a deadline and a place where the team can see what is waiting for review.
This guide builds a Trello-style kanban workflow inside WordPress using Lumo Team Messenger. We will use a fictional website-launch project to connect those ideas to the actual controls: boards, members, task cards, checklists, comments and follow-up settings. “Trello-style” describes the board-and-card workflow; it does not mean feature parity, a Trello integration or an import tool.
What was actually checked
I inspected Team Messenger 2.214.0, installed it in our permanent local WordPress lab, created a fictional agency board and five tasks, and checked the real interface. Fifteen integration and timing checks passed. I also saved a task status and checklist item through the browser, then reopened the task; a weekly recurring rule displayed its next run and was disabled after the demonstration. Email delivery, Telegram delivery and large-team load were not tested. This is our own product, so the limitations below matter as much as the setup.
Is a WordPress task manager right for your agency?
It is worth evaluating when your team already works in WordPress and wants its internal conversations and project cards together. Designers, developers, content editors and the person checking the final site can share a project board without making the public website itself into a customer-facing project portal.
The trade-off is operational responsibility. Your hosting, backups, updates, access rules and scheduled jobs become part of the workspace. Self-hosted does not automatically mean encrypted end to end, maintenance-free or faster than a hosted project-management service.
Before switching an entire company, pilot one real project with a small team. If you need advanced resource planning, billing, enterprise reporting or strict read-only client seats, verify those requirements independently. This tutorial does not establish those capabilities.
The Team Messenger product page contains the current package, licensing information and additional interface demonstrations. Check the plan you intend to buy includes the task features you need; do not infer commercial entitlements from this local installation.
Design the workflow before adding tasks
Our example is Northstar Agency · Website Launch. Maya handles design, Alex handles development and Sam checks quality. These are fictional accounts, not customers or staff whose private work appears in screenshots.
Start with four columns. A column should answer “what happens next?”, not simply make the board look busy.
| Column | What belongs here | Condition for leaving |
|---|---|---|
| To Do | A defined deliverable that has not started | Someone accepts responsibility and has what they need |
| In Progress | Work actively being done | The output is ready for another person to inspect |
| Review | A deliverable waiting for a decision | The reviewer accepts it or explains the required revision |
| Done | Accepted work with evidence attached or linked | Reopen only if a new defect or revision needs action |
“Design website” is too broad for one useful card. “Approve homepage wireframe” has a visible outcome. “QA mobile navigation and contact form” tells the reviewer what to inspect. That difference is more valuable than adding ten custom columns.
A practical starting rule
Agree that each person normally has one active deliverable before starting another. This is a team policy, not an automatic limit demonstrated in the plugin. If Review keeps growing, help the reviewer clear the queue instead of starting more work. Atlassian’s explanation of work-in-progress limits is a useful background reference for this practice.
Step 1. Install the plugin and initialize its storage
Download the plugin ZIP from your account. In WordPress, open Plugins → Add Plugin → Upload Plugin, choose the ZIP, click Install Now, then Activate. Complete the license activation required by your package.
Open Messenger. A fresh installation may ask you to configure the database first. Choose Go to Setup. The settings page opens Connections → Database.
For this tutorial, select WordPress Database and click Install Tables. The actual setup created the plugin’s separate, prefixed tables inside the lab’s existing WordPress database. That avoids introducing another database connection just to learn the workflow.
Actual local setup: Messenger → Settings → Connections → Database. No external database credentials are required for internal mode.
The External Database option is a different deployment choice, not a performance switch you should enable blindly. A remote database adds credentials, connection reliability and backup coordination to the setup. File storage is configured separately, so choosing a database does not automatically move attachments to FTP.
After installation, confirm Messenger opens without a database warning. Keep a backup that includes both the plugin’s tables and the attachment storage you selected. A database-only backup is not a complete recovery plan for uploaded files.
For a fuller walkthrough of groups, messages and storage, use our WordPress team messenger setup guide. The remaining steps here focus on delivery and task management rather than repeating that article.
Step 2. Give colleagues access without making everyone an administrator
Create individual WordPress accounts for the people taking part. Use Users → Add User, then review Messenger → Settings → General, where messenger access is controlled by allowed roles.
Use the least-privileged role that meets the person’s actual work requirements. A developer who needs WordPress administration is different from a colleague who only needs to discuss work. Do not grant Administrator merely to make the task interface appear.
There are two separate questions: can this WordPress account enter the messenger, and does it belong to this project board? Test both. In our lab we used fictional subscriber accounts for project collaborators and a separate nonmember account to check board access.
Board membership is collaboration access
In the reviewed version, BoardService::can_manage_content() delegates to can_view(). An ordinary board member can therefore manage board content; membership is not a read-only viewing seat. Our test confirmed a member could manage content and a nonmember could not view the board or move its card. Test a real client-access requirement separately before inviting customers into internal boards. This was a focused service check, not a complete security audit.
Step 3. Create one board for one delivery stream
Open Messenger → Tasks → New Board. Give it a recognizable name, such as the client and deliverable, rather than “General tasks.” Add a short description stating the scope and what completion means. Select only the colleagues who need to collaborate, then save.
Our board contains five example cards: wireframe approval, a responsive service page, mobile navigation and form QA, content inventory, and launch redirects. The default board columns are To Do, In Progress and Done. Use Add another column to add Review. The column edit controls let you adjust the title and appearance.
Actual lab board with fictional tasks and colleagues. The cropped interface is unchanged.
Do not create a new board for every small task. A useful boundary might be one website launch, one ongoing maintenance stream, or a content-production pipeline. Separate boards when membership, confidentiality or the review process really differs.
If you rename the final column, check its completion setting too. In the inspected code, moving a card to a column marked as done sets its completion timestamp; moving it out clears that timestamp. A decorative column name and the completion flag are not the same thing.
Step 4. Write a task another person can finish without guessing
Inside the intended column, click Add a card, or use New Task while working in the project board. Give the task an outcome-based title. Select an Assignee, choose an appropriate Priority, and set a Due Date if the work has a real delivery deadline.
Use Notes for the brief and decisions. Use Checklist for acceptance conditions, and Comments for the conversation about the work. The task also provides an attachment area for the relevant files. Avoid putting passwords, API keys or unrelated customer information into the brief.
Here is a practical brief for the wireframe card:
Deliverable: homepage wireframe ready for internal approval
Owner: Maya
Reviewer: Sam
Scope: desktop and mobile layout, navigation and primary CTA
Evidence: attach or link the two wireframes
Done when: reviewer feedback is resolved and approval is recorded
If blocked: explain what is missing and who can supply it
“Reviewer” here is a convention in the note, not a separate approval engine demonstrated in the plugin. The visible Assignee field identifies one responsible person. A checklist makes review repeatable, but ticking it does not prove the work is correct.
Actual task editor. The checklist and status were saved and reopened during the browser check.
In the browser test, I checked Primary CTA and navigation are clear, changed the task status to In Progress, saved and reopened it. Both changes persisted. That is a useful minimum test before asking the team to rely on the workspace.
Keep board position and personal status straight
The source distinguishes board-column placement from per-user task status. A delegated task can show Delegated to its creator and Referred to its assignee. Do not assume that the personal status dropdown and the shared kanban column are the same field.
For the agency’s daily meeting, use the shared board as the agreed workflow view. When someone says a task is finished, check the actual card, its review evidence and its column. In our integration check, moving a card changed its stored board-column ID; that is different from merely changing a personal status.
Step 5. Move the work through review, not just across a screen
Drag the card to the next appropriate column. When work enters Review, add a concise comment explaining what changed and where the reviewer can inspect it. If it fails review, return it to In Progress with a specific reason.
For example, “Mobile menu does not close after following an anchor link; tested at the small-screen layout” is actionable. “Mobile broken” is not. Record the relevant page URL and reproduction steps so the developer can work without another meeting.
Use History on the board and Activity inside the task when you need to understand changes. Do not treat an activity log as proof that a deliverable was approved; record the approval explicitly.
For a team that already discusses revisions in Messenger, the product also offers message-to-task conversion from the message context menu. After converting, still review the title, assignee, deadline and checklist. A copied chat message is a starting brief, not automatically a complete task specification.
Step 6. Configure follow-up without turning it into noise
Open the card and find Deadline & Follow-up. Enable Give this task a time limit and send follow-up reminders. Choose the time allowance and begin with Normal — once per stage intensity.
The reviewed defaults use elapsed-time thresholds such as 25%, 50%, 75% and 100%. Strong and Aggressive add repeat reminders. They do not make the assignee work faster; they change how frequently the system asks for an update.
Actual interface: the elapsed-time percentage is a timer, not a completion score. Click the image to inspect the full-size controls.
Three controls are easy to confuse:
| Control | What it represents | What it does not prove |
|---|---|---|
| Due Date | A date/time used for deadline and overdue behavior | That someone has accepted the brief |
| Time allowed to complete | A duration for the follow-up cycle | Working days or billable hours |
| Time elapsed percentage | How much of that duration has passed | Percentage of the deliverable completed |
The source converts one day to 24 hours. A two-day allowance is 48 elapsed hours, not two agency working days with weekends excluded. Our timing check used a four-hour allowance with a start two hours earlier and returned 50% elapsed. It did not inspect any completed checklist items to calculate that number.
Report status and the optional second follow-up cycle can separate an initial response from later follow-through. Only enable Treat a status change as a status report if that matches how your team works. Otherwise, a casual status change may be interpreted as the update you were waiting for.
Begin with one test task and verify the intended notification channel. We did not send real email or Telegram notifications in this lab, so the screenshots are not evidence of mail deliverability.
Step 7. Use recurring tasks for maintenance with a clear schedule
Recurring work makes sense for repeated deliverables: review backup results, check a client’s contact form, or prepare the weekly project update. It is a poor fit for an unfinished one-off task that simply needs someone to finish it.
Inside a task, find Recurring and enable it. The reviewed interface offers Daily and Weekly, an interval, a time, a start date and an optional end date. Weekly also exposes day selection. Set the schedule, click Save Rule, and inspect Next run.
In the browser demonstration, selecting Monday with a 09:00 time showed the next Monday run. The rule was then disabled so the tutorial would not keep producing cards. This verifies configuration and the displayed next-run value, not an unattended multi-week execution history.
Check WordPress’s time zone before relying on that schedule. An agency serving overseas clients should agree on one operational time zone and write the client’s deadline clearly in the brief when necessary.
WordPress scheduled work also depends on execution, not just a saved date. The WordPress cron documentation explains that normal WP-Cron is triggered by page loads. A quiet private workspace may need a properly configured server scheduler. Follow the official system-scheduler integration guide with your host, and verify execution before disabling the normal trigger.
A short acceptance test before your first real project
Do not judge the installation only while logged in as Administrator. Run this checklist with the accounts and hosting configuration your team will actually use.
- Open the workspace as an intended colleague and confirm the right board is visible.
- Open it as a nonmember and confirm the internal project is not exposed.
- Save a task with an owner, deadline and a short checklist; reload it and inspect the saved values.
- Move one card between columns and confirm another team member sees the result.
- Check a permitted attachment download and an unauthorized access attempt separately.
- Send one agreed test reminder and confirm delivery and time zone, rather than only looking for a success message.
- Restore a backup in a safe environment and confirm both task data and files are recoverable.
These are deployment acceptance checks. They are not all claimed as completed in this article’s lab. The focused checks we did complete are summarized below.
| Check performed here | Observed result |
|---|---|
| Board member vs. nonmember service checks | Member allowed; nonmember board read and card move denied |
| Card move and subsequent read | Destination board-column ID persisted |
| Browser task save | Status and checklist change remained after reopening |
| Follow-up normalization and elapsed time | Zero duration rejected; invalid intensity fell back to Normal; half the allowance returned 50% |
| Weekly rule configuration | Next-run value displayed; rule disabled after the test |
Keep the workspace reliable after launch
A task board is a logged-in, changing application. Do not place its authenticated HTML or AJAX responses behind a shared full-page cache. Ordinary public marketing pages and the private workspace have different caching needs. If your site becomes slow specifically after login, investigate the actual request path instead of assuming a cache switch will solve it.
Keep attachments purposeful. A final PDF and the source link are often more useful than ten near-identical exports with unclear names. Decide who archives completed projects, who removes former employees’ access, and how long the agency retains project material.
For a new team, I would review the pilot after one completed delivery. Ask where work stalled: unclear brief, too much active work, missing review, or unreliable notifications. Change the process that caused the delay. Adding more alerts or columns is not always the answer.
What this setup gives you—and where to draw the line
The useful result is a shared delivery process inside WordPress: one project board, visible ownership, explicit review, task context and controlled follow-up. Team Messenger supplies the interface; your agency still needs to define responsibility and acceptance.
Start with a single project and the four-column workflow above. Keep the brief small enough to understand, keep the next action visible, and close the card only when the deliverable is accepted. That is a much stronger foundation than buying a tool and hoping the team will become organized around it.
References and verification notes
- Lumo Team Messenger 2.214.0 source reviewed: BoardService, BoardRepository, TaskService, TaskFollowupService, TaskRecurringService and TaskAjax. Local screenshots use fictional data. The product page may describe a different release; check your installed version.
- Atlassian: Working with WIP limits for kanban — background for the suggested team policy; automatic WIP enforcement was not demonstrated here.
- WordPress: Roles and capabilities — distinguish WordPress privileges from plugin-specific board membership.
- WordPress: WP-Cron — scheduled execution and traffic-triggered behavior.
Originally published on LumoWP. The original tutorial is credited to Mansour Jabinpour. I work on LumoWP, which makes the plugin used in this walkthrough. The test scope and limitations above are retained from the original.
Top comments (0)