JILEAR COMPLETE / v1.1
What I build

Tools that run inside the software your team already uses.

How other variants can help your business →

Jilear Complete is a script that runs right inside the browser, about 5,000 lines of code, that improves the ticketing system my team works in (ConnectWise). It adds nine features that make the day faster. There is nothing to install on a server and no separate login. It runs inside the same browser tab the technician already has open.

~5,000
lines of code
9
features added
7
scripts combined into one
0
servers or logins to set up
the ticketing system
The improved ticket board with a follow-up panel on the left and a color-coded, highlighted ticket list on the right
See it in action

A quick walkthrough of the real thing.

This is the tool running live in the ticketing system, recorded on the job.

⚠️ Note: portions of this video are intentionally blurred to protect confidential and security-sensitive client information.

◀ Left — the version I refined & updated Right ▶ — the original, brown & bare
The problem

Every ticket goes through the ticketing system. The standard screens hide the things that matter most: tickets going cold before a deadline, who actually owns what, and the handful of clicks it takes just to open a ticket. Across hundreds of tickets a week, that friction adds up to lost time, lost revenue, and missed deadlines. I couldn't change the ticketing system itself, so I changed what runs on top of it.

What's inside

Seven small scripts, combined into one reliable build.

Each feature is wrapped so that if one ever fails, it is logged and kept to itself. It never takes down the other eight.

The nine features, in the order they loadall 9 running
01Readable dark themeA dark, color-coded look that is easy to read at a glance.
02Cleaner ticket listClears clutter from the ticket list and keeps the column headers in view as you scroll.
03Stale ticket alertsHighlights tickets that are going cold before they miss a deadline.
04Quick note actionsTurns common note steps into single clicks instead of digging through menus.
05Better time reviewA cleaner layout for reviewing time, so hours get logged accurately and on time.
06Reworked top barRebuilds the top bar around the actions used most.
07Cleaner email screenReorders the email reply screen so it reads naturally from top to bottom.
08In-ticket triageAdds quick triage inside a ticket and clear status labels on the list.
09Key fields firstPuts the important fields first: summary, company, board, and owner.

On top of those, the build folds in a few more tools: a frozen header for the board, the single-screen new ticket form, an auto-complete action, a keyboard shortcut for internal notes, and the follow-up panel that powers the accountability feature below.

Workflow

Less friction on the actions techs repeat all day.

Each feature targets a step that happens hundreds of times a week. Save a few seconds on each one and the whole day changes shape.

Creating a ticket

A multi-step form, on one screen.

Normally, creating a ticket walks you through one step after another. This puts everything on a single screen: who it is for, the issue, which board, the priority, and where it came from, all visible at once.

It moves you forward automatically, captures your note as you type, and holds onto it so nothing gets lost between steps. Fewer clicks, fewer dropped tickets.

new ticket: before and after
Left: the single-screen ticket form. Right: the standard step-by-step version.

On the left, the single-screen form. On the right, the standard step-by-step version.

inside a ticket
The reorganized ticket view with the key fields first and color-coded note actions.

The reorganized ticket view. Client note text is blurred for privacy.

Inside a ticket

The important fields first.

The ticket view now leads with what you read first: the summary, company, board, and owner. The common note actions become color-coded single clicks for internal notes, customer replies, and sending.

Pressing Ctrl + Q opens an internal note in a single keystroke, with the extra handling needed to make it work inside a browser script.

Time and email

Cleaner time tracking, cleaner billing.

The time-review and email screens are laid out so time gets logged accurately and on time, and the email reply reads naturally from top to bottom.

That matters for the business. Time that is captured properly is time that actually gets billed.

time and email
The reorganized email and time screen.

The reorganized email and send-to screen. Recipient details are blurred.

Accountability

An accurate record of who closed what.

When a ticket assigned to me is marked Completed by someone else, the follow-up panel lets me know right away. It reads this from the ticket's own history log, so the record holds even if the status is changed back later.

It only reads information and never changes anything. The goal is a fair, accurate record of who did the work, which also gives team leads something solid to rely on.

  • Keeps completion credit with the person who actually did the work
  • Reads the full history, not just the current status, so a quiet change back cannot hide it
  • Gives team leads a clear, data-backed record
A ticket assigned to you was completed by someone else
Read from the ticket history
Ticket #48217, Mailbox migration
Marked Completed by a teammate
When: 2:41 PM, from the ticket history
Still caught if the status is changed backREAD ONLY
Under the hood

Built to be reliable on a live, busy system.

There is no test environment. This runs against the real system all day, so it is built to fail quietly, read the data honestly, and stay light on the network.

If one part fails

One feature can't break the others.

Seven scripts are combined into one. Every feature runs inside a safety wrapper, so if one throws an error it is logged and kept to itself instead of spreading.

function run(name, feature) { try { feature(); } catch (error) { console.warn( 'feature "' + name + '" failed', error); } }
Reading the system

I read how the system talks, instead of guessing.

The ticketing system's behind-the-scenes data connection is not documented. I found the sign-in details from the live session, located the right server out of five, and checked every request against real data before trusting it.

// find the right server, in order servers = ['api-2', 'api', 'api-3', 'api-4', 'api-5']; // read the ticket's history log history = '/tickets/' + id + '/history'; // durable
Light on the network

It stays light on the network.

Big checks run rarely, small checks run often, and the costly history lookups only happen when something has actually changed. Requests are capped, spaced out, and cached.

big check every 15 min small check every 4 min wait at least 45 sec between at most 6 requests at once
Why it matters

The business case, not just the build.

Every part of this exists to move a number the team is measured on.

More tickets per tech each day

Less friction on everyday actions means more work closed in the same shift.

Protected customer deadlines

Stale ticket alerts surface cold work before it slips past its deadline.

Cleaner billing

A clearer time-review screen helps log hours accurately and on time, so fewer hours go unbilled.

Fair credit

An automatic, accurate record of who completed each ticket.

Nothing to run or maintain

No servers and no separate login. It runs in the browser tab the tech already has open.

Reliable in daily use

Self-contained features and verified data keep it stable on a busy, live system.