Set up the process once. Use it for every request.

01

Show people what to do next

People should not have to leave a request to find the right SOP. machtask puts the instructions, checks and fields for that request in front of the worker.

• Important questions can be required, so the team has what it needs before work starts.
• Step instructions explain what to do. Field help explains what to enter. Conditional steps appear only when they apply.
• A request stays tied to the published process version it started on.

02

Move work between teams without email

When one team finishes its part, machtask opens the next stage in the responsible team’s queue. Nobody has to forward a message or create another task.

• Finishing one stage opens the next in the team queue automatically.
• Queues separate unclaimed, assigned and recently completed work.
• The next stage starts with its own team and deadline, plus any earlier information the workflow author chose to share.

The handoff is visible and ready to work as soon as the previous stage is complete.

03

Pass the right context on with the work

Requesters should not have to explain the same issue at every handoff. A workflow can carry the original answers and earlier teams’ work forward.

• Later teams can read information shared from earlier stages.
• Each contribution is labelled by stage and team, so its source is clear.
• Workflow authors choose whether a stage shares everything, selected fields or nothing.

04

Count deadlines in working time

A four-hour deadline is no use if it expires while the responsible team is asleep. machtask counts time using that team’s calendar.

• Set each team’s working hours, holidays and time zone.
• Business-time clocks pause outside those hours. Queues and Watch Tower show work that is at risk or overdue.
• Warnings and breaches are recorded in the request history. A breach can also email the person who created the request.

05

Update the process without changing open work

Updating an SOP is easy. Knowing who is still using the old one is harder. New requests use the version you publish; existing requests stay on the version they started with.

• Changes remain in draft until you publish them.
• New requests use the newly published version. Existing work remains unchanged.
• Before archiving a process, you can see which workflows still depend on it.

The request history always shows which process version applied.

06

Use one list across every form

Site names, system names and reason codes drift when each form has its own copy. Keep one managed list and reuse it across processes.

• Dropdowns can use a shared list managed by an administrator.
• Update the list once. Processes using it see the new values without being republished.
• A connected system can preview and apply changes through a narrowly scoped API.

07

See the whole workload

Work that arrives by phone or email is easy to leave out of the numbers. Record it alongside online requests, then see where work is arriving and where it is waiting.

• Workload and flowInsights shows open work, throughput, cycle time and queue wait by team, with a request-type breakdown.
• Work from other channelsWorkers can use Quick Log for requests that arrive by phone, walk-up or another inbox.
• APIs and webhooksService accounts, APIs and signed webhooks connect other systems without sharing a person’s login.

Managers can see where work is building up without asking the team for another status spreadsheet.