From concept to handover, on one thread
An interior project is four teams in sequence — design, procurement, site, accounts — and almost everything that goes wrong happens in the gaps between them. TaskIt gives each stage an owner and moves the work between them on one task, with the context attached.
No card required. Every feature is unlocked for 30 days.
What usually goes wrong
Written from how this kind of business actually runs, not from a generic template.
How it goes today
The project lives in six WhatsApp groups
One with the client, one with the site team, one with the vendors, one internal. A decision taken in the client group never reaches the site group, and by the time anyone looks the thread has scrolled past a fortnight of messages.
Nobody can say which drawing the site is building from
The design changed after the client meeting. The revised layout went to the 3D team and to the carpenter, but not to the electrician, who is on the previous version and has already chased the conduits.
Approvals stall silently
A mood board sits with the client, a material sample sits with the principal designer, a quotation sits with accounts. None of the three is refused — they are simply not looked at, and nothing anywhere says how long they have been waiting.
Procurement is a chase, not a process
The veneer was ordered. Was it confirmed? Did it dispatch? Will it land before the carpenter is on site? The answer lives in one person’s call log, and when they are on leave the project stops.
Site issues are reported and then lost
The supervisor photographs a snag, sends it to the group, and someone says "will check". Three weeks later at handover the same snag is on the client’s list, and no one can say who was meant to close it.
The principal is the only person who knows everything
Every status question routes to one person because only they hold the whole picture across five live projects. Their week becomes reporting, and the design work happens after hours.
With TaskIt
Each stage owned by a name, not a group
A task has one assignee and a due date, or it is raised for a department and claimed. Concept, drawings, BOQ check, vendor follow-up, site measure — each is a task somebody accepted, so "who is doing this" is never a question that needs asking.
A handover that carries the context
When design signs off and the project moves to procurement, and again when procurement moves to site, the work is handed over on the SAME task — recording what was completed, what is still open and why it moved. The site supervisor inherits the reasoning, not just the job.
Design, procurement, site and accounts as separate queues
Departments let you raise work for a team rather than a person. Everyone eligible is notified and the first Accept takes it, as a single conditional write — so two people cannot both pick up the same vendor follow-up however close together they tap.
Site reports that arrive structured
Build a task form with the fields you always end up chasing: area, floor, trade, issue, severity, whether it blocks the next trade. The supervisor fills it on their phone, and the studio gets a comparable record instead of a paragraph.
Recurring site checks that do not depend on memory
A weekly site inspection, a fortnightly vendor follow-up, a monthly snag review — set a cadence of daily, weekly, monthly, yearly or a custom interval, and each occurrence is created as a real task with a real owner and its own execution history.
Blocked is a status, not a silence
When a task genuinely cannot proceed — material not delivered, client approval pending, another trade in the way — the owner marks it Unable to Complete with a reason. It moves to Blocked and reaches the manager immediately, instead of looking "in progress" for another week.
Nothing is closed by assertion
Submitted work goes to In review and is approved or rejected by the person who raised it or someone holding the review permission, and nobody can approve their own submission. For a snag list before client handover, that is the difference between a claim and a record.
Updates reach the site team where they already are
Notifications go out over your own paired WhatsApp number — to a person, a group, or both — carrying the task code, title, priority and a link. Supervisors and contractors who will never open a project tool still get the change.
A three-bedroom apartment, week six
Design is signed off, procurement is mid-flight and the site has two trades working. One studio, five people, four live projects.
- 1
Monday — design hands over
The final layout and the material schedule are approved by the client. The designer submits the design task; the principal approves it. A handover moves the project’s procurement task to the procurement lead on the same task ID, with the approved schedule and the client’s two late changes recorded on it.
- 2
Monday — the queue, not the person
Six vendor follow-ups are raised for the procurement department rather than named to one person. Two coordinators are notified; each claims three. Nothing is chased twice and nothing is assumed to be someone else’s.
- 3
Wednesday — the site inspection that runs itself
The weekly site inspection task was created by its schedule, owned by the supervisor. They complete the site form on their phone: area, trade, progress, three snags with severity. The studio sees it the same afternoon.
- 4
Wednesday — one snag blocks a trade
The false ceiling cannot close because the AC drain is not routed. The supervisor marks it Unable to Complete with that reason; it moves to Blocked and is on the project manager’s queue within the minute rather than at the next site visit.
- 5
Thursday — the veneer slips
The vendor confirms dispatch is four days late. The procurement coordinator updates progress and the note against the task. Because the carpentry task references the same project, the manager sees the collision before the carpenter arrives to an empty site.
- 6
Friday — the report nobody had to write
The scheduled daily report lands in the studio’s WhatsApp group: what was completed, what is in progress, what is blocked and by whom. The principal reads four projects in ninety seconds instead of making eleven calls.
- 7
At client handover — the snag list closes properly
Each snag was a task with an owner and a due date. Each was submitted and reviewed by someone other than the person who fixed it. The list the client is walked through is the list the system says is closed.
The result
The two things that usually derail a design project — a decision that never reached site, and a snag nobody owned — were both a task with a name and a timestamp on it. The principal spent the week designing rather than reconstructing status.
The result
No percentages, because nothing here has measured yours — these are the changes the mechanism produces.
The gap between studio and site closes
A handover that moves on the same task, carrying what was done and why, is the difference between the site team inheriting a decision and rediscovering it.
Follow-ups stop depending on one person’s memory
Vendor chases and site checks that run from a schedule survive leave, illness and a busy week. The execution history shows which occurrences actually happened.
The principal stops being the status desk
When every stage has an owner and Friday’s report writes itself, the question "where is project three" has an answer that does not require interrupting anyone.
Handover disputes have a record behind them
Every accept, progress update, comment, handover, review and status change is written to the activity timeline and the audit log with a timestamp. When a client asks when a change was agreed, the answer is a record rather than a recollection.
| The work | Where it belongs | Why |
|---|---|---|
| Design stages, revisions and approval chasing | TaskIt | Each needs a named owner, a due date and a review |
| Procurement follow-ups and delivery tracking | TaskIt | Repeating chases that must survive one person’s absence |
| Site visits, inspections and snag lists | TaskIt | Structured intake, an owner per snag, review before close |
| Handover from design to procurement to site | TaskIt | One task ID, with the reasoning carried across |
| Drawings, 3D renders and CAD files | Your existing file storage | TaskIt has no drawing store, viewer or revision control |
| BOQ, costing, quotations and invoicing | Your accounting or estimation tool | TaskIt tracks no money and produces no BOQ |
| Client-facing approval portal | Email or your client’s preferred channel | There is no external client login in TaskIt |
| Gantt charts and critical-path scheduling | A dedicated planning tool | TaskIt has no dependencies, baselines or critical path |
Frequently asked questions
General task management, described for how a design studio runs. There is no interior-design edition of TaskIt — no CAD integration, no material library, no BOQ module. What it does have is the part most studios are missing: an owner on every stage, handovers between design, procurement and site that carry the context, structured site reporting, scheduled follow-ups and a complete history.
No, and it would be wrong to imply otherwise. TaskIt has no drawing store, no file viewer and no revision control for design assets — those stay wherever you keep them today. What TaskIt holds is the task: who owes the revision, when it is due, who approved it and what changed at each step.
No. There are no task dependencies, no critical path, no baselines and no resource levelling. If your projects are planned on a Gantt chart, keep it — TaskIt is for the day-to-day execution underneath the plan, which is the layer a Gantt chart is usually too coarse to hold.
As an actual handover. The task moves to the next owner on the same task ID, recording what had been completed, what is still open and the reason it moved. The site supervisor sees the history rather than a fresh task with no background, which is what makes it different from reassigning.
It runs in a phone browser with nothing to install. For people who will not open a tool at all, notifications go out over your own paired WhatsApp number to a person, a group or both, carrying the task code, title, priority and a link — and scheduled reports can go to the same place.
Departments separate the teams — design, procurement, site, accounts — and each task carries its own owner, priority, due date and status. Reports and the dashboard read across all of them, so a principal can see what is blocked across every live project without opening each one.
Access comes from the permission list stored on a role rather than from a job title — an Admin base role grants nothing on its own. Employees see their own work and their department’s unclaimed queue unless a permission says otherwise, so a supervisor does not get the studio’s whole client list.
You define a schedule — daily, weekly, monthly, yearly or a custom interval — and each time it falls due it creates a real task with a real owner and a due date, keeping an execution history of every occurrence. That covers weekly site inspections, fortnightly vendor follow-ups and monthly snag reviews.
Where to go next
The capabilities behind this page, and the neighbouring situations they also cover.
Put one live project through it
Take the project you are chasing hardest, give each stage an owner, and let this week’s site inspection run from a schedule instead of a reminder.