How to Receive Job Requests From Multiple Clients in One Queue

A contractor working across several clients has a problem no single-site operation has: every
client believes their way of contacting you is the way, and every one of them is right, because
you agreed to it when you won the work.

So requests arrive by message from one site manager, by email from a client's head office,
through a client's own portal for a third, and by phone from the caretaker who has had your
number for nine years.

You cannot consolidate the channels. You can consolidate the queue.

Accept the channels, control the queue

The distinction is the whole design. Clients keep using whatever they use. Every request,
however it arrives, gets copied into one internal list before anything else happens.

That copying step is the only new discipline, and it has to be small enough to survive a busy
morning. If it takes more than about thirty seconds, it will be skipped exactly when volume is
highest — which is when missing something matters most.

Six fields, filled at intake

Client, site, what, who asked, when it arrived, and how it arrived.

The last one earns its place for a reason that is not obvious: when a client later asks why
something was not done, the answer is frequently that it was mentioned verbally to a technician
on site and never became a request at all. Recording the channel makes that visible as a pattern
rather than an accusation.

Make one person responsible for the copying

Where several people receive requests, decide who transfers them into the queue. Usually it is
whoever received it — but it has to be stated, because the default assumption is that somebody
else is doing it.

For requests that arrive to a technician on site, the realistic mechanism is that they forward
or photograph it. Anything requiring them to open an application and type is unlikely to happen
consistently across a wet afternoon.

Where crews already send messages, structuring what they send is far more reliable than adding
a step. That is the design principle behind tools like Laksana, and it applies whatever you end
up using.

Give every request a reference and tell the client

A reference costs nothing and does two things: it stops a client and a technician discussing
different jobs in the belief they are discussing the same one, and it lets a client chase
without re-describing.

Send it back through the channel the request arrived on. A client who emailed expects an email.
Replying through a different route is a small friction that accumulates into a reputation for
being hard to deal with.

Separate what was asked from what you agreed

Requests and commitments are different things and conflating them causes most contractor disputes.

Record the request as it was made. Separately, record what you agreed to do about it and by
when. A client asking for something does not make it a commitment, and a commitment made on the
phone is one nobody else in your business knows about.

This distinction becomes important at contract review, when clients present a list of requests
and ask why they were not all completed.

Watch for the same job arriving twice

Multi-site work produces duplicates constantly: the caretaker reports it, the site manager
reports it, then head office reports it because the first two are unresolved.

Because everything lands in one queue, duplicates end up adjacent and visible. Link them rather
than deleting — three reports of the same fault is itself information about how much it is
affecting the client.

Review the queue by client, not just by date

Once a week, sort by client rather than chronologically. It reveals two things a date-ordered
list hides: the client whose requests are ageing faster than everyone else's, and the client
generating volume disproportionate to what they pay.

Both are commercial facts. The second in particular tends to be felt long before it is
demonstrated, and a contract renewal is far easier to discuss with the figures in front of you.

The minimum that works

A spreadsheet with those six columns plus a status. It will run a small contractor across a
dozen sites.

It strains when several people need it open at once, when technicians in the field need to update
it, and when clients start asking for their own view of their own jobs. Those are the signals to
move to something shared — but the six fields do not change.