Job management workflow: what should the software do?

Find the point where information gets lost

A customer asks when a job will be ready. Someone in the office checks a spreadsheet, calls the person doing the work and searches email for an attachment. Each tool contains part of the answer, but nobody is sure which information is current. The immediate problem may be the handover between people, rather than the absence of an advanced planning system.

Review a small selection of completed and open jobs. Record where someone had to wait, ask again or correct a misunderstanding. Separate missing information from unclear responsibility. Software can help with both, but these problems call for different features.

Before commissioning a new application, check whether your existing software already supports a shared job register, attachments, owners and views of incomplete records. A configuration change and clearer working rules may be enough for the first improvement.

Give each job a shared reference

Decide how everyone will recognise the same piece of work. A job reference should connect the agreed scope, customer decisions and documents needed to carry out the work. If one customer order creates several separate jobs, decide whether they will be line items within one record or linked records with their own progress.

For an initial version, consider:

• a job reference and a short description;
• the customer and the relevant contact;
• agreed scope, quantity and due date;
• the person responsible for the next action;
• current documents and their revision history;
• missing information and a deadline for obtaining it;
• a record of significant decisions, including who changed the scope and why.

Not every field needs to be mandatory when a record is created. A completion date may still be unknown at the enquiry stage. Define when that information becomes necessary and who supplies it. Stopping all progress whenever any field is empty can encourage people to keep working outside the application.

Make each status describe a specific situation

Labels such as “new”, “in progress” and “done” are ambiguous if different people interpret them differently. For each stage, write down its entry condition, owner and expected next action before adding more status options.

The following fictional example describes a job to manufacture a set of components. It illustrates how to document working rules; it is not a proposed workflow for every business.

Scroll the table sideways to read the conditions for each stage.

“Waiting for the customer” may work better as a visible blocker attached to a job, with an owner and a follow-up date. The main stage can then continue to show how far the work has progressed. Choose the distinction that helps your team make decisions.

Use exceptions to test the design

Suppose a customer supplies a revised drawing after work has started. Replacing the attachment does not tell the team what to do with work already completed. Someone needs to decide whether to pause, what to inspect and which scope applies from this point onwards.

Bring comparable situations to your discussion with the software developer:

1. A customer changes quantity or the agreed deadline after handover.
2. Part of an order is ready while the rest is waiting for material.
3. The job owner is absent and someone else takes responsibility.
4. A job is cancelled after some work has been completed.
5. A missing document is discovered while the work is under way.

For each situation, agree what the application records, who needs to act and what everyone else sees. A history should help reconstruct a decision. A notification should make a useful action clear. Sending every change to every employee can make meaningful updates harder to notice.

Give each role an appropriate view

Office staff need a reliable answer for the customer: progress, date, blocker and owner. The person carrying out the work needs their queue and current instructions. A manager may need overdue jobs and records without an owner. These views should use the same underlying information instead of maintaining separate copies of a job.

Ask people how they look up information during an ordinary working day. Include the devices they actually use: a large office monitor and a phone beside a workstation need different layouts. Watching someone complete a real task is a better check than asking whether a dashboard looks good.

Decide how to evaluate the first release

Start with a limited type of job and the people who actually handle it. Test the normal sequence and the exceptions already documented. Make it clear where the authoritative information lives during the trial, so a parallel spreadsheet and application do not drift into competing versions.

Before changing the workflow, record a baseline: how long a status lookup takes, how many jobs have missing information and how often the office has to ask for the same update. Repeat those observations on comparable work after the trial. This provides evidence of usefulness; a login count alone does not establish improvement.

What to bring to a planning discussion

A sample job record, a list of the people involved and two awkward cases are a useful start. Remove customer information that does not need to be shared. Add the questions you cannot currently answer easily and identify who needs those answers.

These materials can define a first scope for the business applications offered by brigdev. If some records remain in other software, also work through the system integration planning guide. Before launch, make a separate plan for moving open jobs and introducing the new application.