How to Document Processes for Filipino VA Teams

You hired someone great in the Philippines.

Now what?

Most people skip straight to Slack messages and scattered Google Docs. That works for a week. Maybe two.

Then things break down.

The real challenge isn’t finding good remote workers in the Philippines.

It’s building systems that let them succeed without you micromanaging every hour of the day.

Here’s what most people get wrong: they think documentation is about control. It’s not.

Let me show you how to do this properly.

The Three Documents Every Role Needs

Forget hundred-page handbooks. You need three specific documents for each person on your team, and you can create all three in an afternoon.

Create a Role Card First

Start with a single Google Doc titled “[Name]’s Role Card.”

Include exactly six things:

Core responsibilities. List 3-5 main outcomes this person owns. “Manage customer support inbox and maintain under 4-hour response time” not “answer emails.”

Weekly hours. Approximate, not exact. “20-25 hours per week” gives flexibility while setting expectations.

Time zone alignment. “Available for questions between 9am-12pm Eastern” or “Works Manila daytime, submits recap by 6pm Manila time for morning review.”

Key tools and access. List what they need. Gmail, Asana, Slack, whatever. Include who grants access.

Primary contact. Who approves their work? Who do they ask when stuck? Make this crystal clear.

Definition of success. What does good performance look like? “All tickets resolved within SLA” or “Zero missed deadlines in a month.”

That’s it. One page. Update it when responsibilities change, which they will.

Save it in a shared folder everyone can access. This becomes your single source of truth when there’s confusion about scope.

Write Task-Level SOPs for Recurring Work

Pick the five tasks this person does most often. Create a separate Google Doc for each.

Title format: “SOP: [Task Name]”

Every SOP needs the same structure:

What and Why. Two sentences maximum. “This process triages new support tickets so urgent issues get handled first. It runs every morning before the inbox piles up.”

Prerequisites. What access, tools, or information does someone need before starting? “Gmail access, Asana project access, customer priority list.”

Step-by-Step Instructions. Number each step. Be specific without being condescending. Include screenshots of any interface that might confuse someone.

For example:

1. Open Gmail and go to the Support inbox
2. Sort by unread messages from the last 24 hours
3. Read the subject line and first paragraph of each message
4. Identify priority based on these keywords: “urgent,” “broken,” “can’t access,” “billing issue”
5. Create an Asana task for each email using this format: [Screenshot of task template]
6. Add priority tags: P1 for urgent (red), P2 for important (orange), P3 for standard (no tag)
7. Reply to the customer with our acknowledgment template [link to template]
8. Move the email to “Triaged” folder

Quality Check. What does “done” look like? “All emails from the last 24 hours have corresponding Asana tasks, all customers received acknowledgment replies within 1 hour of submission.”

Where to Ask Questions. Specific channel or person. “Post in #support-questions if stuck” or “DM Sarah for edge cases.”

Examples. Show a good example. Show a bad example. Call out the differences.

Don’t write SOPs for every possible task. Start with the recurring ones. Add more as patterns emerge.

Store all SOPs in one folder. Name them consistently so people can find them.

Map Multi-Person Workflows

Some processes involve handoffs between people. Those need visual maps.

Use Lucidchart, Miro, or even Google Slides. Keep it simple.

Show the trigger (what starts this process), each step, who owns it, and what happens next.

Example: Client Onboarding Workflow

• Trigger: New client signs contract (Sales team)
• Step 1: Sales creates client folder and fills intake form (Sales, 1 day)
• Step 2: VA receives Slack notification, reviews intake form (VA, same day)
• Step 3: VA sets up client accounts in tools X, Y, Z (VA, 2 days)
• Step 4: VA sends welcome email with login details using template (VA, same day)
• Step 5: VA creates first project kickoff meeting invite (VA, within 3 days)
• Step 6: VA notifies Account Manager that onboarding is complete (VA, same day)

Add decision points if they exist. “If client needs custom API access, escalate to Tech Lead before Step 3.”

The point isn’t to make it pretty. The point is so everyone knows where their piece fits and who picks up the work next.

How to Write Documentation That Actually Gets Used

You can have perfect SOPs that no one reads. Here’s how to avoid that.

Use Simple English Without Idioms

Your team in the Philippines speaks excellent English. But idioms, sarcasm, and cultural references can still cause confusion.

Be direct. Be specific. Skip the corporate speak.

Add Screenshots for Every Interface Step

If your SOP mentions clicking something in a tool, take a screenshot. Circle or arrow the exact button.

This seems obvious. Most people skip it. Don’t skip it.

Screenshots eliminate 90% of “where do I click?” questions. They’re especially helpful across time zones when you can’t screenshare in real time.

Update screenshots when interfaces change. Set a reminder to review SOPs every quarter.

Include Actual Templates and Examples

Don’t just describe what good output looks like. Show it.

If you want status reports in a certain format, paste an example status report in the SOP.

If emails should follow a template, write the full template with [bracketed placeholders] for the custom parts.

If Asana tasks need specific naming conventions, show three real examples of correctly-formatted tasks.

Examples eliminate guessing. They make expectations concrete.

Document Your Working Hours and Response Times

Add a section to every role card about communication expectations.

When are you available for questions? “Mondays through Fridays, 9am-5pm US Eastern. I usually respond within 2 hours during these times.”

This prevents the awkward dance where nobody knows if it’s okay to message or not.

It also respects boundaries. Your team in the Philippines shouldn’t feel obligated to respond at midnight Manila time because you sent a message during your afternoon.

Create a Simple Holiday Calendar

List Philippine public holidays and note whether you expect work on those days.

List your home country holidays and clarify if those are work days for your Filipino team.

This takes five minutes and prevents weird assumptions about availability.

Put it in a shared calendar everyone can see. Update it annually.

Write Your Time Tracking Policy Before Choosing Tools

Create a document called “How We Track Time and Protect Your Privacy.”

Include:

What we track. “Clock in/out times, task descriptions, total hours per day, which project you’re working on.”

What we don’t track. “We don’t take random screenshots. We don’t monitor your webcam. We don’t track activity on your personal devices or personal accounts. We don’t monitor your mouse movements or keystrokes.”

Why we track. “We track time to process accurate payment, forecast project capacity, and understand if workloads are balanced. We use this data for payroll and planning only, not to micromanage your day.”

Who sees the data. “Only [your name] and [finance person’s name] can see time tracking data. We don’t share it with clients or other team members.”

Your rights. “You can request to see all time data we have for you. You can submit corrections if something’s wrong. We delete data after [X years] per our retention policy.”

Share this document during onboarding. Get written confirmation (even just an email reply) that the person read and understands it.

Configure Your Tools for Light-Touch Tracking

If you use time tracking software, turn off invasive features.

No keystroke logging. No mouse movement tracking. No random webcam captures.

Set screenshot intervals to “manual only” or “once per hour maximum” if you absolutely need visual proof of work for client billing.

Better yet: rely on task completion and daily recaps for proof of work instead of screenshots.

Maintaining Documentation Over Time

Documentation dies when it gets stale.

Set a recurring reminder every quarter to review your SOPs. Which ones are outdated? Which processes changed?

When you update an SOP, add a “Changelog” section at the bottom:

Last updated: January 10, 2026 Changes: Updated screenshot of new Asana interface, added step 4b for priority customer escalation

This shows your team that documentation stays current. It builds trust that following the SOP will actually work.

When someone asks a question that should be in an SOP but isn’t, that’s your signal to write it down.

What This Actually Looks Like in Practice

You’re managing three people in the Philippines doing customer support, social media, and administrative work.

Each person has:

• One role card (1 page)
• Five task SOPs (2-3 pages each)
• Access to two workflow maps that involve handoffs

They fill out a daily standup recap at the end of their day. Takes five minutes.

They track time with simple clock in/clock out. No screenshots. No surveillance.

You review recaps each morning over coffee. Ten minutes total. You see what got done, what’s blocked, what’s coming up.

When something’s unclear, you update the relevant SOP and share the update in Slack.

That’s it.

No micromanagement. No constant check-ins. No surveillance anxiety.

Just clear expectations and documentation that actually helps people do their jobs.