You document a business against resignation by capturing what only one person knows, before they announce they are leaving, focusing on the accounts, passwords, supplier contacts, customer relationships, and small judgment calls that live in someone's head. Philippine labor law gives you a 30-day notice period in an ordinary resignation, which sounds like enough time and is not, because a proper handover of years of accumulated knowledge cannot be compressed into four weeks alongside their normal work.

The moment you find out is always the same. Someone asks to talk, and before they say anything you already know. And in the next few seconds, while you are trying to react like a decent person, part of your brain is quietly listing everything they know that nobody else does. Reducing that exposure is core to our systems work with professional services and local teams.

The 30-day window, and why it isn't enough

Under Article 300 of the Labor Code (formerly Article 285), an employee resigning voluntarily is generally required to give written notice at least 30 days before their intended last day. The period exists so employers can find a replacement and arrange an orderly turnover. Thirty days is genuinely useful. It is also not enough on its own, for a simple reason: during those thirty days, the person is still doing their normal job. The handover happens in the gaps. And nobody can transfer three years of accumulated context in gaps.

The businesses that come through a resignation well are not the ones with a great handover process. They are the ones who had already written things down before anyone gave notice.

Step 1: Find out what only one person knows

Ask yourself, honestly, for each person on your team: if they did not come in tomorrow, what would stop? Then get more specific. The dangerous knowledge is rarely the obvious job description. It is:

  • Access. Which accounts, systems, and passwords are only in their name or on their phone
  • Relationships. Which supplier gives you the good price because they know this specific person, and which regular customer only deals with them
  • Exceptions. Which customers have arrangements that are not written anywhere
  • Judgment. The small decisions they make dozens of times a week that nobody has ever articulated as a rule
  • Fixes. How to handle the machine that does the thing, the system that needs the workaround

Write this list for each person. It is uncomfortable reading, and it is the most useful hour you will spend on this.

Step 2: Deal with access first

This is the fastest fix and the one with the worst consequences if skipped. Every business account, from your Facebook page to your Google Business Profile to your online banking to your booking tool, should be owned by the business, with the owner holding access, and staff added as users rather than owners.

The single most common and most damaging version of this: a Facebook page or Google Business Profile where the only admin is a former employee. Recovering it is possible but slow and painful, and in the meantime you cannot post, reply to reviews, or update your hours. Do an access audit now. List every account, who owns it, and who has access. Fix anything where a staff member is the sole owner.

Step 3: Capture the relationships

For every supplier, contractor, and significant customer, record somewhere shared: who they are, what the arrangement is, what was agreed verbally that is not in any contract, and any history that matters. Verbal arrangements are the risk here. "Manong gives us the Tuesday delivery at the old price" is not written anywhere and disappears entirely with the person who arranged it.

Step 4: Write down the judgment calls

This is the hardest category and the most valuable. Ask your experienced staff a direct question: "What do you decide during the day that you never ask me about?" The answers surprise most owners. Which customers get a small discount without asking. When to accept a late booking. When a return gets processed without escalating. These are real operating rules that exist only as habit. Once articulated, they can be reviewed, agreed, and passed on. Left unarticulated, they leave with the person and the replacement makes different calls, which customers notice.

Step 5: Have people document their own work, gradually

Rather than one enormous documentation project, ask each person to write one short SOP for one task, once a month. In a year, a team of four has produced nearly fifty documented processes without anyone ever running a documentation project. Doing it gradually also produces better documents, because they get written while the work is fresh rather than under handover pressure.

When someone does give notice

If you already did the work above, this becomes manageable. If you have not, prioritize ruthlessly in this order:

  1. Transfer all access immediately, in the first few days, not the last week
  2. Introduce them personally to the suppliers and key customers they own, face to face or on a call, not by email
  3. Have them document their five most important recurring tasks, and specifically the judgment calls
  4. Schedule shadowing if a replacement is already in place, since watching beats reading

Deliberately do not spend the thirty days having them write a comprehensive manual. It will not get finished and the parts that do get finished are usually the easy parts you did not need.

Handle the exit well, for reasons beyond kindness

Final pay and clearance have their own rules and timelines under DOLE guidance. Handling an exit properly matters legally, and it matters practically too. In a market where people move between employers regularly, the person leaving today talks to your future applicants, and sometimes comes back themselves.

The uncomfortable underlying question

If one person leaving would seriously damage your business, that is worth sitting with. It is common, it is not a personal failing, and it is also a real vulnerability that grows quietly as your team gets more experienced and more indispensable. The businesses that handle turnover well are not lucky. They built the documentation before they needed it, usually because someone leaving once taught them the hard way. It's the same reason to fix your owner bottleneck before it fixes itself the painful way.