Skip to main content
LOCAL WORKS by Garcia Systems

How it works

Start with how the work actually gets done.

Local Works begins with the current workflow, not a predetermined technology solution. We look at what customers and staff are trying to accomplish, where unnecessary friction appears, and whether changing the process is actually worth it.

The basic idea

The problem comes before the solution.

A frustrating process does not automatically mean buying new software, automating everything, building something custom, or replacing existing systems.

We first clarify what someone is trying to do, what actually happens today, where effort, delay, or confusion appears, and whether the problem matters enough to justify intervention. Technology is considered later.

Local Works methodology overview

  1. Observe
  2. Understand
  3. Measure
  4. Choose
  5. Deliver

Observe

1. Observe

Where are customers or employees doing unnecessary work?

We look at the workflow from the perspective of the people who actually use it. Signals can include unnecessary calls, repeated emails, paper handoffs, waiting for callbacks, entering the same information twice, copying between systems, switching among several tools, avoidable in-person visits, or unclear status after a request.

Observation produces questions, not conclusions. Not every inconvenience is a serious business problem.

Understand

2. Understand

How does the process actually work today?

The visible customer experience may be only one part of a larger internal process. We map who starts it, what information is needed, which people and systems become involved, where handoffs happen, what happens when something goes wrong, what the customer sees, and what staff do behind the scenes.

Illustrative workflow A hypothetical example, not a Local Works customer
  1. Website inquiry
  2. Inbox
  3. Phone call
  4. Calendar
  5. Spreadsheet
  6. Payment link

Evidence discipline

Observation is not proof.

A visible inconvenience is a reason to investigate—not a reason to prescribe a solution.

  1. 1

    Observed fact

    A customer must call to cancel.

  2. 2

    Possible friction

    It may be inconvenient for customers and time-consuming for staff.

  3. 3

    Unknowns

    How often does it happen, and what constraints explain the current process?

  4. 4

    Questions

    How many calls occur, how much staff time is involved, and what do existing systems support?

  5. 5

    Evidence

    Usage, interviews, feedback, workflow data, and existing-system capabilities.

  6. 6

    Decision

    Determine whether anything should change.

Measure

3. Measure

Is the problem important enough to justify changing?

We consider operational burden and economic reality: how often it happens, how many people experience it, employee time, lost inquiries, mistakes, rework, customer impact, the cost of change, and how much burden could realistically be removed.

Not every problem can—or should—be reduced to a precise dollar value. The purpose is disciplined decision-making, not a promised return.

Choose

4. Choose

What is the simplest sensible response?

These five outcomes are alternatives, not levels of sophistication. The evidence—not the size of the project—determines the right response.

01

Configure

Use existing tools more effectively by enabling features, improving settings, or reorganizing a workflow.

02

Integrate

Connect systems that work individually but require unnecessary manual transfer between them.

03

Automate

Remove repetitive steps when the workflow is understood and stable enough to automate safely.

04

Custom Build

Create software only when the problem is real, existing options fall short, value justifies cost, and ongoing support makes sense.

05

Leave Alone

Keep the process when the issue is small or rare, the workaround is acceptable, constraints make change impractical, or likely benefit does not justify cost.

A simple solution hierarchy

Use what already exists before creating something new.

This is an evaluation direction, not a rigid rule. If a focused custom solution is genuinely the best answer, we should be comfortable recommending it.

  1. 1Can the current process simply be improved?
  2. 2Can an existing system be configured?
  3. 3Can existing systems be connected?
  4. 4Can repetitive work be automated?
  5. 5Is custom software actually justified?
  6. 6Is leaving the process alone the better decision?

Deliver

5. Deliver

If action is justified, how should the solution get implemented?

When implementation is justified, Local Works helps determine the right delivery approach and coordinate the technical work.

That may mean changes inside an existing system, vendor or SaaS configuration, integration, workflow automation, specialist contractors, an agency, focused custom development, or support for a customer’s internal technical team. The approach depends on the need; it does not imply formal partnerships with every possible resource.

Responsibility should stay tied to the business outcome—not merely to writing code.

What we don't assume.

  • Custom software is necessary.
  • Every inconvenience deserves a project.
  • The visible symptom is the real problem.
  • Replacing existing tools is better.
  • Automation is automatically an improvement.

Example scenario

A hypothetical appointment request

This example only illustrates the decision process. It is not a customer story or a claimed project outcome.

Current process A service business receives appointment requests through its website.
  1. Website form
  2. Email inbox
  3. Staff callback
  4. Calendar
  5. Confirmation email
  1. Observe

    Customers wait for callbacks.

  2. Understand

    Staff manually move information from the inquiry into the calendar.

  3. Measure

    Investigate volume, staff time, no-shows, existing software capabilities, and customer impact.

  4. Choose

    Options might be configuring scheduling features, connecting the website and calendar, automating confirmations, using an existing scheduling product, building only if justified, or leaving it alone if the burden is too small.

  5. Deliver

    If change is worthwhile, implement and coordinate the selected approach.

A structured starting point

The Digital Friction Audit is where this process begins.

The audit examines relevant parts of a customer or employee journey and identifies where deeper investigation may be worthwhile. It is not an automatic software recommendation engine.

Request a Digital Friction Audit

A typical customer journey

  1. Find
  2. Understand
  3. Contact
  4. Book / Join
  5. Pay
  6. Receive Service
  7. Manage
  8. Return

The relevant stages vary by business. The audit is a structured place to begin asking questions.

Have a workflow that feels harder than it should?

Describe the friction. Local Works can help investigate whether it is worth changing and what the simplest practical response might be.