When I'm designing a system for a client, I want to understand more than which tasks they need automated.
I want to know what happens when a client submits incomplete information, who is responsible for moving a project forward, and how the team knows when something needs attention.
These details tell me how a business actually operates.
Two businesses can offer similar services, use the same software, and still need completely different systems because their processes, responsibilities, and client experiences aren't identical.
That's why I design systems around how a business works rather than expecting the business to adapt to a generic setup.
At Virtually by Elle, I use a human-centered approach to design custom workflows, Airtable systems, and automations. My focus is on making information easier to manage, responsibilities clearer, and recurring work more consistent.
Here's what that process looks like and how I apply it to real client operations.
What Human-Centered Systems Design Means
Human-centered systems design means considering the people using a system throughout the design and implementation process.
For a service business, that includes the owner, team members, and sometimes the clients interacting with the workflow.
I consider three things:
- The workflow: What needs to happen, in what order, and under which conditions?
- The information: What does everyone need to know, and where should they find it?
- The people: Who completes the work, makes decisions, and handles exceptions?
These considerations influence how I structure databases, connect applications, and decide which activities should be automated.
For example, a client onboarding workflow might involve a CRM, an intake form, and a project management platform.
Connecting those tools is only one part of the solution.
The system also needs to recognize when the client has completed the necessary requirements, when someone should review the information, and when the project is ready to begin.
A system is only useful when it supports the responsibilities and decisions involved in the work.
Step 1: Understand How the Work Actually Happens
Before building anything, I review the existing process.
I want to understand what starts the workflow, what information is required, who handles each stage, and what determines when the work is complete.
Take client onboarding.
A business owner might describe their process as sending a welcome email, collecting an intake form, and creating a project.
That's a useful overview, but it doesn't tell me everything I need to design the system.
I would also want to know:
- Does onboarding begin after contract signature, payment, or both?
- Can the project begin before the intake form is complete?
- Who reviews the client's information?
- What happens when required details are missing?
- Which activities require a personal conversation?
The answers affect how the workflow should be structured.
For example, an incomplete intake form shouldn't necessarily trigger the same actions as a completed submission.
The system might need to flag missing information and notify the responsible person before the project moves forward.
I also look for decisions that aren't documented.
An owner may know exactly when to follow up or how to handle an unusual client request because they've managed the process for years.
But if that knowledge isn't documented, another team member may not know what to do.
My job at this stage is to identify the actual process, including the decisions that usually happen without anyone thinking about them.
Step 2: Design the Information Structure and Handoffs
Once I understand the workflow, I determine how the system should support it.
This includes deciding where information belongs, how records should connect, and which actions should trigger the next step.
One important decision is establishing the authoritative source of information.
Imagine a client's renewal date appears in Airtable, a project management platform, and a spreadsheet.
If someone updates one date but not the others, the team could end up working with conflicting information.
I would first determine where that renewal date should be maintained.
Other parts of the workflow can then reference that information as needed.
This reduces the need for people to repeatedly check which version is correct.
I also design the handoffs between people and tools.
For example, when a client submits an onboarding form, the system might create a record, organize the information, and notify the team member responsible for reviewing it.
The review remains a human responsibility, but the administrative steps leading up to it can happen consistently.
I want the system to make the next responsibility clear without creating unnecessary work for the person receiving it.
That doesn't always require additional software.
Sometimes the existing tools need a better connection. Other times, the information needs to be reorganized or a responsibility needs to be defined more clearly.
The solution depends on what the workflow requires.
Step 3: Build and Test the Workflow
After the structure is defined, I move into implementation.
Depending on the project, that might involve building an Airtable base, configuring linked records, setting up automations, or connecting existing applications through Zapier.
But I don't consider a system complete simply because an automation runs successfully once.
It needs to work under the conditions it's designed to handle.
For example, if an intake form creates a project record, I would test whether the correct information appears in the intended fields.
I would also check whether the workflow handles missing information appropriately and whether an existing client could accidentally receive duplicate records.
Testing is particularly important when several actions depend on one another.
A successful first step doesn't guarantee that every subsequent action produces the intended result.
I also want the team to recognize when something requires manual attention.
A reliable system should make it easier to identify what happened, what needs attention, and who is responsible for responding.
The exact tests depend on the agreed project scope, but testing is always part of my implementation process.
Step 4: Document the System and Hand It Over
Documentation matters because clients need to understand the systems they're receiving.
They shouldn't have to know how to rebuild an automation, but they should understand how to use the workflow and recognize when something needs attention.
For example, documentation might explain where a client record is created, what triggers a reporting reminder, and which actions still require someone on the team.
I also explain relevant dependencies.
If a particular field controls an automation, changing that field could affect how the workflow operates.
Understanding those relationships helps the client make informed decisions when their processes change.
The handover should leave the client with a system they can use and understand, not just a collection of technical configurations.
A Client Example: Connecting Onboarding, Reporting, Renewals, and Offboarding
One project that reflects my approach involved designing a connected client-delivery system for an agency.
The system brought together four stages of the client relationship: onboarding, reporting, renewals, and offboarding.
Each stage had different responsibilities, but they needed to work together throughout the engagement.
Making reporting responsibilities visible
One part of the implementation involved monthly reporting.
The agency needed a way to identify upcoming report deadlines without manually reviewing every client's schedule.
I structured the workflow around individual client reporting dates, with an internal reminder generated two days before a report was due.
The reminder didn't prepare or send the report.
The team remained responsible for reviewing the information, preparing the report, and communicating with the client.
The system handled the timing and notification so that responsibility was easier to manage.
Supporting renewals and offboarding
Renewals and offboarding also needed defined processes.
Instead of depending entirely on someone remembering when an engagement was approaching its next stage, the workflow used relevant client dates to support the team's planning.
The actual client communication and decisions remained with the appropriate people.
This allowed the administrative structure to support the relationship without attempting to automate every interaction.
Why I kept the kickoff manual
One intentional decision was leaving the client kickoff as a manual relationship touchpoint.
A kickoff is an opportunity to clarify expectations, discuss project details, and establish how the working relationship will operate.
That interaction served a purpose beyond completing an administrative task.
So rather than removing it, I designed the system to support the surrounding activities.
The goal was to make client delivery more organized while keeping meaningful interactions in the hands of the people responsible for them.
I haven't measured a specific number of hours saved through this implementation, so I won't attach an unverified time-saving claim to it.
What the project demonstrates is how connected workflows can support different responsibilities throughout a client engagement.
How I Decide What Should Remain Manual
Not every activity benefits from automation.
When deciding how a workflow should operate, I consider whether an action follows predictable rules or requires human judgment.
Generating a reminder based on a known reporting date is predictable.
Reviewing the report before sending it requires professional attention.
A system can notify someone that a renewal is approaching, but the conversation about continuing the engagement may depend on the client's needs and relationship with the business.
I don't see those manual activities as weaknesses in the system.
They're responsibilities that deserve intentional consideration.
The purpose of automation is to support the work, not remove human involvement simply because technology makes it possible.
Choosing the Right Scope for a Systems Project
The size of the implementation depends on how much of the business needs to be connected.
A single workflow improvement, such as connecting an intake form to an existing project management system, may be suitable for a Systems VIP Day.
My Systems VIP Day is a $1,000 service focused on one clearly defined project completed in one business day, including testing, documentation, and handover.
A project involving several connected workflows, a custom Airtable database, or a more extensive operational structure may require a Custom Backend Build.
For larger projects, I define the scope and deliverables before implementation.
This makes it possible to design the system around the actual requirements rather than adding features that don't serve a clear purpose.
Both services follow the same approach, but the scope and complexity determine which is appropriate.
Your Systems Should Support the People Using Them
A system can have advanced automations and still be difficult for a team to operate.
That's why I consider how information is organized, how responsibilities are assigned, and what happens when a process requires someone to make a decision.
I want business owners to know where important information belongs and team members to understand what they're responsible for.
I also want the system to remain manageable when the business changes.
The measure of a useful system isn't how many automations it contains. It's whether the people using it can complete their work clearly and consistently.
That's what human-centered systems design means in my work.
Need a Custom Backend Built Around Your Business?
If your onboarding, client delivery, reporting, renewals, or other recurring workflows need to work together, my Custom Backend Build service may be the right fit.
I design and implement systems around your actual operations, including the information structure, responsibilities, and automations needed to support the work.
Each project is scoped and priced according to its requirements.
