JVMeet Justine

AI Automation Specialist

Internal systems, automation and AI voice for teams that can’t afford a missed step.

I’m Justine. I design, build and run staff portals, workflow automation and AI voice agents for organisations that handle sensitive records. Two clients in two countries rely on them in their daily work.

See the work

In production today

clients, in two countries
2clients, in two countries
active workflows on one server
86active workflows on one server
AI voice agents on one phone line
5AI voice agents on one phone line
modules in one staff portal
20modules in one staff portal

Selected work

Five systems, two clients, all still running.

Both clients handle sensitive records, so neither is named. Every diagram is redrawn and contains no client data.

AI voice that fills open shifts and chases missed clock-ins

The problem

When a support worker can’t make a shift, someone in the office has to ring around until a replacement says yes. And when a worker doesn’t clock in, nobody knows whether a client is waiting alone until someone happens to notice.

What I built

One phone number with five AI voice agents, and the automation behind them.

To fill a shift, an operator screen lists the workers who have supported that client before, shows who is free, and gives a reason for every worker it rules out. The operator sets the order. The system then calls each worker in turn, texts an offer to anyone who misses the call, and books the first spoken yes.

The same number looks after attendance. A worker who hasn’t clocked in gets an AI call, then a text. If there is still nothing, it is raised to the office as a possible no-show, and after hours it rings management’s phones.

Filling an open shift

  1. Operator screen

    Previous workers, who is free, and why anyone is ruled out. The operator sets the order.

  2. AI call

    The first worker is called and the call is graded.

  3. No answer

    A text offer goes out and the next worker is called.

  4. Spoken yes

    The first yes books the shift.

  5. Office told

    An outcome email, with every call and text on record.

Chasing a missed clock-in

  1. Shift starts

    Checked every 5 minutes.

  2. +15 min, no clock-in

    An AI call, then a text.

  3. +30 min, still nothing

    Raised as a possible no-show.

  4. Office alerted

    After hours, management’s phones ring.

  5. Worker clocks in

    The case closes itself.

Fig. 1. One phone number, two jobs. Redrawn for this page; no client data.

What that means day to day

  • The operator stays in charge. The system suggests; a person decides who gets called.
  • Shift checks run every five minutes across two states.
  • Every call, skip and text is logged with its wording.
  • It spots phones that answer with a screening robot, so a robot’s words are never recorded as a worker’s answer.

One staff portal in place of a project-management tool

The problem

Hiring, onboarding, IT requests, shared logins and grant tracking were spread across project-management boards, spreadsheets and chat. There was no single record of who a staff member was, what they could reach, or where a request stood.

What I built

One internal app with 20 modules behind a single sign-in: a 13-stage hiring pipeline, onboarding and offboarding, request queues, a credentials vault, licence-fee payments and a grants board.

Access is set by department and enforced in the database, so a confidential queue stays confidential even if a screen is misconfigured.

People

  • Employees
  • Hiring
  • Offboarding
  • Annual reviews

Operations

  • Request queues
  • Licence fees
  • Credentialing
  • Memberships

Shared

  • Credentials vault
  • Report a concern
  • Work log
  • Grants

Programs

  • Client outreach
  • Partner referrals
  • Access program

Administration

  • Departments
  • Access
  • One sign-in
  • Access by department
  • Enforced in the database
  • Audit log
Fig. 2. The portal’s module map. Redrawn for this page; no client data.

What changed

  • One permission model, used by both the screens and the database.
  • One hire action creates the staff record and the work account.
  • The organisation moved its boards into the portal and retired its project-management subscription.

Payrun checks that stop a bad pay run before it starts

The problem

A pay run depends on timesheets, billing and payroll records that live in three different systems. A mismatch between them is easy to miss until after people have been paid or invoiced.

What I built

Thirteen automatic checks run before every pay run. Anything wrong stops the run and says where to fix it, down to the shift and the worker.

After the run, a three-way comparison lines up what was paid against what was billed and breaks every difference down shift by shift.

  1. Pre-check

    Thirteen checks. Anything wrong stops the run here.

  2. Approve timesheets

    One press, with a log of what was approved.

  3. Invoice file

    Built for the accounting import, error tab first.

  4. Payroll file

    Allowances worked out and added.

  5. Compare

    Paid against billed, three ways.

Fig. 3. The pay run, left to right. Redrawn for this page; no client data.

What that means day to day

  • A check that could not run is never counted as a pass.
  • A stop names the client, the shift and the worker, so the fix is quick.
  • A government report that took about 25 manual spreadsheet steps now runs as one tool.

From application to first login, and back out again

An application on the careers page lands in a 13-stage pipeline. One hire action creates the staff record and the work account and stores the password in a vault. When someone leaves, offboarding suspends the account.

  1. Application

    From the careers page.

  2. Pipeline

    Thirteen stages.

  3. Hire

    One action.

  4. Account created

    Work email made, password vaulted.

  5. Offboarding

    Account suspended.

Fig. 4. One record from application to exit. Redrawn for this page; no client data.

A public application that staff can trust

A public form feeds a pipeline that validates each application, stops duplicates, routes it for staff review and applies written rules to reach a decision, with a periodic reassessment. Every step leaves an audit trail.

  1. Public form

    No sign-in needed.

  2. Validate

    Fields checked, duplicates stopped.

  3. Staff review

    Routed to the right team.

  4. Decision

    Reached by written rules.

  5. Reassessment

    Checked again on a schedule.

Fig. 5. An application’s path. Redrawn for this page; no client data.

How it’s kept running

Building it is half the job.

This is how the Australian estate is run. It is the part clients rarely see and always depend on.

  • 86 active workflows

    All on one self-hosted automation server.

  • Data stays onshore

    The server sits in the client’s own country.

  • Backed up nightly

    A database dump and server snapshots every night, and an alert if the server stops answering.

  • Errors explain themselves

    One error workflow emails who is affected, what went wrong and what to do.

  • No secrets in the browser

    Keys are held server-side and every request is checked against the sign-in.

Approach

How I work

  1. 1.

    Map the process

    Before any tool: who does what, in what order, and where it breaks. Most automation fails because the logic was never written down.

  2. 2.

    Build it in the open

    Each workflow ships with a plain-language note on what it does, when it runs and what it touches.

  3. 3.

    Prove it on real data

    Nothing is called done until it has run on a real case and the result has been checked.

  4. 4.

    Hand it over, or keep it running

    You get the documentation either way. If I run it, I get the alert before you do.

Rules I build to

Taken from the systems above.

  • A failed data read stops the send and says why. It never falls back to an older copy.
  • “Could not check” never counts as a pass.
  • The AI suggests. A person decides.
  • Every result says what it did not check.
  • A scheduled report is sent even when it finds nothing, so silence never means broken.

Reference builds

Open-source examples

These three are demos, not client work. They run on made-up data, and each ships with the importable workflow, an architecture note and a process map.

About

Meet Justine

Justine Valenzuela

I’m Justine Valenzuela, an AI automation specialist based in Bacolod, Philippines. I came to automation from site reliability engineering and Kubernetes, and I hold the CKA certification. That background is why I care more about what happens when something fails than about how the demo looks.

I work with teams in the United States and Australia as their automation and internal-tools person. I design the system, build it, document it and keep it running.

Contact

Book a 30-minute discovery call

Tell me what you need built or fixed. In 30 minutes we work out whether I’m the right person for the job and what the first step would be.

Other ways to reach me

Or send a message

You’ll get an automatic reply within a minute. I follow up personally within one business day.