Building an Internal Operations Platform From the Ground Up

The Starting Point

When I joined Sustainable Staffing, much of the company's operational knowledge lived in shared Google Drive folders. Client folders accumulated documents containing everything from orientation instructions and workplace requirements to information recruiters needed when describing a position.

The information existed. The problem was finding it, knowing which source was current, and assembling the pieces needed to complete a task.

File formats complicated that further. The company primarily used Macs, and many shared files had been created in Pages or Numbers. Because we already used Google Workspace, I began standardizing new shared material around Docs and Sheets and gradually converting existing information as I encountered it.

Client information became the clearest opportunity for something better.

Rather than treating each client as a collection of documents, I approached the problem much as I had approached ecommerce product information: identify the attributes, organize them consistently, and establish a source of truth.

Locations. Contacts. Workplace descriptions. Shifts. Dress requirements. PPE. Parking. Break policies. Orientation information. Benefits. Screening requirements. Supporting documents.

The first goal wasn't automation.

It was simply to make the answer easy to find.

Creating a Source of Truth

I initially proposed Confluence as a centralized knowledge system. Technically, it could solve the problem. Organizationally, adoption was limited.

That taught me an important lesson: the technically ideal solution isn't useful if the people who need it won't use it.

A website presented a much lower barrier. Everyone already understood how to navigate one.

The first Internal Information Portal was therefore intentionally simple: a structured, read-only collection of internal pages where client information, work instructions, and company documentation could be presented consistently.

There was no relational database or sophisticated application behind it.

But people used it.

Employees no longer needed to know where a particular document had been stored. They could navigate to a client and find information in a predictable place.

And once people began relying on the portal to find information, the requests changed.

They began asking it to do things.

When the Portal Started Doing Work

Google Workspace became the first automation layer.

Interview scheduling eventually grew into one of the most extensive examples. Information originated from several workflows, including standard scheduling, job fairs, and talent-acquisition activity. Forms collected it, spreadsheets aggregated it, and recruiters worked from additional sheets.

Using formulas and Apps Script, I connected those pieces. The system created Calendar events, tracked interview activity and no-shows, separated results by originating workflow, and generated metrics around scheduled interviews, completed interviews, attendance, and hires.

It worked—and eventually operated without my daily intervention.

It also demonstrated the architectural limit we were reaching.

Every new requirement meant another formula, script, workbook, or dependency that had to remain synchronized.

Spreadsheets had helped prove what the workflows needed to do. They were also showing why those workflows eventually belonged in a relational system.

The Relational Turning Point

As the portal grew, we began moving its underlying information into MySQL.

Previously, a client page contained information about a client. In the relational model, the client became structured data. Locations, contacts, requirements, documents, schedules, and other attributes could exist independently of whatever page or workflow needed them.

As development accelerated, I was able to bring in a summer intern, Nathan, who was learning IT and contributed meaningfully across the portal while I continued leading the operational model, requirements, automation, integrations, and implementation.

Orientation became one of the clearest demonstrations of what the new architecture made possible.

The system already knew the job's position and shift. It already knew the client's location, dress requirements, PPE, parking instructions, facilities, policies, breaks, and orientation requirements.

Instead of finding that information again and retyping it into another document, the orientation workflow could use the existing client and job records to populate its output.

If the business already knows something, an employee shouldn't have to enter it again because another process needs it.

The same underlying information could now support Client Profiles, orientation preparation, document generation, scheduling, contacts, finance, and other workflows.

The value wasn't just automation.

It was reuse.

Integration Changed the Platform

The next major shift came from better access to information already stored in our applicant tracking system.

An XML/RSS Job Feed allowed job information to become another reusable data source. Scheduled reports expanded that further.

Direct API access wasn't available within our environment, but reports could be scheduled for email delivery. I used Gmail rules, Apps Script, authenticated handoffs, import processing, and database storage to turn those reports into a controlled integration path.

The portal increasingly gained access to information already being recorded elsewhere: assignments, hires, terminations, comments, billing activity, task states, and other operational records.

That allowed it to do something more valuable than simply collect additional data.

It could compare records across systems.

Did an expected hire actually appear in the source data?

Did a termination have a matching assignment?

Did an ATS comment contain enough structured information to create the expected internal action?

Did the employee, job, date, wage, client, and assignment agree with the record we already had?

When the answer was clear, routine processing could continue.

When it wasn't, the system surfaced the exception for review.

Automation handled the predictable cases. People handled the exceptions.

That approach grew into validation states, matching logic, review queues, import histories, finance reconciliation, and operational reporting.

The portal was no longer simply recording work.

It was helping determine where human attention was actually needed.

When the Process Changed

Not every migration reached completion.

The mature Google Workspace interview system was an obvious candidate for the relational platform. We designed the database structure and began ingesting its historical information.

Then the business process changed.

Scheduled interviews were eliminated in favor of interviewing candidates at first contact. The workflow we were preparing to migrate had effectively ceased to exist.

So the migration stopped.

The existing system represented substantial work, and completing its relational replacement would have produced cleaner architecture. Neither justified continuing to build software for a process the business no longer intended to use.

The purpose of the system is to support the business process—not preserve the system.

Sometimes the correct product decision is to stop.

What It Became

The portal wasn't created through one clean rewrite. It evolved while the business continued using it.

Static pages coexisted with database-backed applications. Google Workspace automation continued operating while newer workflows moved into MySQL. Older PHP existed alongside newer shared services. Some migrations were completed, others remained transitional, and occasionally the business changed before a migration could be finished.

Over time, the platform came to support work across client operations, recruiting, orientation and onboarding, employee actions, finance, reporting, document generation, reconciliation, and administration.

The progression wasn't driven by a predetermined technology roadmap:

Each architectural step addressed a limitation exposed by the one before it.

What began as a better way to find client information had become shared operational infrastructure.

The Principle That Carried Through

The most important thing I built wasn't a particular PHP page, spreadsheet, database table, or automation.

It was the model underneath them.

A client wasn't a folder.

A job wasn't a row that needed to be copied into another spreadsheet.

An orientation wasn't a document someone needed to reconstruct from several sources.

A hire or termination wasn't simply an entry in one system.

They were related pieces of operational information that could be structured, reused, compared, and acted upon.

That continues to shape how I approach systems work:

• What does the business need to know?
• Where does that information come from?
• Who needs to use it next?
• Why are we asking someone to enter something we already know?
• Which cases actually require a person to make a decision?

Answer those questions first, and the technology becomes much easier to choose.

A Shared Platform Across Operations

At a Glance / Summary

Problem

Operational information was fragmented across shared files, spreadsheets, and business systems, requiring employees to repeatedly find, interpret, transfer, and reconcile the same information.

Approach

Progressively structured that information into reusable entities, automated repetitive workflows, integrated available system data, and moved mature processes toward relational applications.

Result

A cross-department internal operations platform supporting client information, recruiting, orientation, employee actions, finance, reporting, document generation, reconciliation, and administrative workflows.

My contribution

Information architecture, workflow design, data modeling, automation, integration strategy, application development, reporting, and operational analysis, with collaborative development as the platform grew.