How we sent finished job paperwork to the right client portal
Finished service sheets and certificates went to the right client portal, with failed or uncertain transfers returned to the office.
- AWS
AWS
- Client
- UK M&E maintenance contractor
- Documents
- Completed service sheets and authorised certificates
- What we built
- Job-to-portal transfers with recorded outcomes and an exception list
- Where it runs
- AWS, connecting job records to client portals
- Who checks
- Job reviewer before release; office administrator for problems
- Job 2041Brantwell EstatesService sheet, certificateReleased
- Job 2042Brantwell EstatesService sheet, certificateReleased
- Job 2043Wexcombe HomesService sheetReleased
- Job 2044Ashmoor FacilitiesService sheet, certificateReleased
Transfers run on AWS and are recorded against each job
Office listFor the administrator
- Job 2044, Ashmoor FacilitiesCheck the portal before trying again, so nothing is sent twice
- Job 2042, Brantwell EstatesRejected by the client: correct it and send it again
The paperwork was finished before the uploading began.
Each client had its own portal and its own place for the same kinds of records.
Only checked paperwork was released for upload.
We kept the job review ahead of the transfer.
An uncertain upload needed checking before another attempt.
The portal might have received the file even if no confirmation came back.
The office works through the transfers that need attention.
Finished jobs go to the right portal after review.
Read the full story
Finishing a maintenance visit left another job for the office: logging into the client’s portal and uploading the service sheet and certificate. We built the transfers for an M&E contractor, with a list of anything that needed attention.
The paperwork was finished before the uploading began.
Each client had its own portal and its own place for the same kinds of records.
An administrator opened the finished job, found the service sheet and certificate, then logged into the appropriate portal to upload them. The office had to repeat that work across clients.
A job could be finished on site while its paperwork was still waiting to reach the client. We connected the released records to the portal they belonged in.
Only checked paperwork was released for upload.
We kept the job review ahead of the transfer.
The job reviewer checked that the service sheet was complete and any certificate had been authorised by the responsible person. The software then matched the released files to the client and job reference before sending them to the right portal.
We ran the transfers on AWS and recorded their outcomes against the job. Missing files or a portal that would not accept the transfer went onto the office list.
An uncertain upload needed checking before another attempt.
The portal might have received the file even if no confirmation came back.
We separated confirmed uploads from failed or uncertain transfers. The administrator checked the portal before retrying an uncertain transfer, so the same service sheet was not sent again blindly.
We also kept uploaded and accepted as separate states. A receipt showed that a file had arrived. Client acceptance still had to be confirmed, and a rejection came back to the office for correction.
The office works through the transfers that need attention.
Finished jobs go to the right portal after review.
The administrator sees which transfers succeeded and which need a check. They deal with missing information, portal problems and client rejections, then confirm the next action against the job.
The record distinguishes paperwork ready to send, uploaded files and client acceptance. Nobody has to treat the absence of an error message as proof that the client accepted the pack.
How many client portals does your office upload to?
Send us a finished job and the portals it goes to. We’ll show you the uploads running, and what comes back to your office.