Projects with status, dates and members. Tasks, task lists, priorities, and a board or list layout. Assignments, due dates, and recurring follow-ups — all linked to the customer, the opportunity, and the invoice that will eventually follow.
Delivery work is usually late for reasons that have nothing to do with effort. The scope exists as a proposal, the dates exist in one person’s calendar, the actual steps exist as a checklist in a channel only the person who wrote it can read, and progress gets reported verbally. The result is a team working genuinely hard and a business that cannot answer three basic questions: how far along is each piece of work, who is actually blocked, and what can be invoiced now? A follow-up that was supposed to repeat monthly exists once, in a chat message, and is never seen again.
Works with: Customer → Opportunity → Quote → Project → Work → Invoice → Payment
A won opportunity, or a standing client with recurring work, becomes a project with its own status, dates, and members. The client, the scope, and the commercial history arrive with it rather than being re-explained in a kick-off call. Nothing about this project starts life as an orphan.
Scope becomes task lists, each item carrying a priority and a place in the sequence. The board or list layout is a matter of personal and team preference — the underlying tasks are the same either way, so nobody is locked into a view that does not suit how they think.
Every task has an owner and, where it matters, a due date. Shared ownership feels fair and hides slippage, because a task assigned to a team is a task that nobody is personally behind. The assignment is the thing that makes a commitment visible to the rest of the business.
A client check-in, a renewal reminder, a site visit, a post-delivery call — these recur, so they are modelled as recurring follow-ups rather than as calendar notes that die. When the follow-up is an item with an owner and a date instead of a reminder, it can be assigned, dated, and worked like anything else.
Project status is the honest answer to "where are we" — assembled from the tasks that are actually done rather than from the most optimistic person in the room. Because delivery and billing read the same work, finished work becomes an invoice without a second person re-deriving what was delivered.
"How far along is this project?" gets answered from the tasks, not from the last status meeting.
A blocked task is visible as an assignment with a person attached, rather than as a silence in a channel.
Recurring follow-ups stop depending on the memory of whoever originally noticed the pattern.
Finished work reaches billing because delivery and finance read the same work instead of exchanging summaries.
Client work inherits its context, so a new team member can read the project without a briefing call.
Real captures, not marketing mockups. Configuration and availability are confirmed during setup rather than promised on a page.
These are illustrative workflows, not customer results. We do not publish outcome claims without approved customer material.
An opportunity is marked won in the sales process. The project is created from it, carrying the client, the contacts, and the agreed scope. The first task list is written once, with dates, and the work begins against a project that already knows whose work it is — so nobody has to reconstruct the brief from an email thread.
A client expects a monthly check-in. It is created as a recurring follow-up rather than a one-off reminder, so the next occurrence is generated by the schedule instead of by someone remembering. When the responsible person is on leave, the item is still there, still dated, and still assigned to the role that covers it.
The person running a delivery leaves while tasks are still open. Because each task carries an assignment and a due date rather than living in a personal list, the remaining team can see exactly what is outstanding, what is late, and for which client. This is the failure mode that project tools are usually bought to prevent.
Every part of NoxOrigin has awkward edges. Naming them now is cheaper than discovering them in month two.
No. A project can be created from the won opportunity or from an existing customer, so the relationship, contacts, and commercial history travel with it. That continuity is the reason the delivery area is part of the same system rather than a separate tool.
Yes. Projects carry members, and tasks are assigned individually. The point of the assignment is that one person is accountable for a task, so shared ownership stays a deliberate exception rather than the default.
They are two views of the same tasks, so neither can drift from the other. Choose the layout that suits how the team reviews work; the underlying status and dates are identical.
A follow-up repeats on a schedule instead of being a one-time reminder, so the next one comes round on its own rather than depending on somebody remembering. They are assignable and dated like any other item, which is what lets them be handed over.
Yes. Delivery access is scoped to delivery actions — reading client and project context, creating and updating tasks, changing status. Pipeline and money actions stay gated separately.