A Shopify seller delegates a task verbally. The VA produces work that is wrong in specific, preventable ways. The founder corrects it, explains the standard, and the VA does it better the next time. This happens four more times over six weeks. By the end, the VA is doing the task correctly, and the founder has spent more time on the task delegated than they would have if they had done it themselves.
Ecommerce delegation documentation is the set of materials that allows a VA or new hire to complete a task correctly the first time, without multiple correction cycles. A verbal briefing is not documentation. A Slack message summarizing the task is not documentation. Documentation is a written artifact the person can return to when they are uncertain, make their own judgment calls from, and use to answer their own questions without interrupting the founder.
The difference between a delegation that works on day one and one that requires six weeks of correction is almost never about the VA’s competence. It is about whether the delegating founder gave the VA what they needed to do the job correctly. Most founders do not. Giving someone what they need to do a job correctly requires documenting standards that have never been written down.
This article is for the Shopify seller who has tried delegating and been disappointed. The Delegation Documentation Stack identifies what needs to exist before any task gets handed off.
Why Verbal Delegation Fails Consistently
The obvious reason: the founder knows the standard in their head and assumes the VA will figure it out. The founder has been doing the task for two years. They have internalized every nuance. What feels like common sense to the founder is specific institutional knowledge that the VA has no way to access.
The less visible cost is the correction tax. Each correction cycle requires the founder to: (1) notice the error, (2) understand exactly what went wrong, (3) communicate the standard, and (4) verify the correction. For complex tasks, this takes longer than doing the task once. For repetitive tasks, it happens repeatedly before the standard is fully transmitted.
The deepest problem is invisible to most sellers: they have never articulated the standard even to themselves. When a founder delegates a task and the VA does it wrong, the founder often cannot immediately explain what was wrong. They know it was wrong, they can feel it, but the standard is tacit knowledge. Writing it down requires extracting it, which is exactly what never happened because the task was always done intuitively.
The Delegation Documentation Stack
The Delegation Documentation Stack is the four-layer set of materials that any task needs before it can be delegated successfully. Each layer serves a different function.
Layer 1 is the task specification
The task specification answers: what exactly needs to happen, when, and how will success be measured? Not a vague description of the work category but the specific output, the specific trigger that starts the task, and the specific criteria that distinguish a correctly completed task from an incorrect one.
“Respond to all customer service tickets within four business hours using the approved templates. Tickets that include the words ‘chargeback,’ ‘fraud,’ or ‘legal’ must be escalated immediately to [founder contact]. Success is measured by: response within four hours, correct template used, and zero escalation-eligible tickets handled without escalation.”
That is a task specification. “Handle customer service” is not.
Layer 2 is the brand and voice reference
Any task that involves customer-facing communication requires a brand voice reference: the writing standards, the vocabulary to use and avoid, and three to five approved examples the VA can reference when their draft does not feel right.
The brand voice documentation from How to Document Your Product Catalog So Anyone on Your Team Can Manage It (Article 09) is the foundation for this layer. A seller who has documented their voice has the material for Layer 2 without additional work.
Layer 3 is the decision rules for exceptions
What happens when the situation does not fit the standard? Every task has edge cases: situations the specification does not cover. Undocumented edge cases become escalations. Documented edge cases become VA decisions.
Layer 3 is a list of the most common exceptions and the decision rule that applies to each. “A customer who orders the wrong size should receive a prepaid return label and a replacement shipped at no cost if the order is under 30 days old. If over 30 days, escalate to founder.” That is a documented exception. Without it, the VA either escalates (adding to founder workload) or improvises (producing inconsistent outcomes).
Layer 4 is the approved output examples
For any task that produces a deliverable (a customer email, a product listing, a social post), the delegation documentation should include two to three examples of the output done correctly. Not descriptions of what a good output looks like. Examples.
Examples do more work than descriptions because they demonstrate the standard at the level of actual sentences and formatting rather than abstract principles. A VA who can compare their draft to an approved example can self-correct in a way they cannot from a description alone.
How the Conductor Assembles Your Delegation Brief
Name the task you want to hand off and let the Conductor assemble the brief from what already exists. The SOP, the brand voice notes, the approved examples. Most of it is already written; it has just never been gathered in one place.
The Conductor is Kiluma’s context-aware AI, and it builds from your own material rather than a blank template. It reads the SOP documents, brand voice notes, and exception records in the Living Library. The Living Library is where the raw material for a brief has been sitting all along.
What comes back is a draft documentation stack, not a blank form. The task specification comes from the SOP and the voice reference from existing notes. The exception rules come from past decisions and the examples from the content archive. The founder edits a draft instead of writing context from scratch.
Write Layer 1 for the Next Task You Plan to Delegate
Before the next delegation, write the task specification: the output, the trigger, and the success criteria. Nothing else yet. Just Layer 1.
Read it back. If you could hand this to a competent stranger and they would know exactly what “done correctly” means, Layer 1 is adequate. If it requires you to explain anything additional to make the standard clear, write down what you would have explained. That is the gap that turns into a correction cycle.
The Delegation That Provides the Full Stack Gets Done Right the First Time
A VA who receives all four layers of the Delegation Documentation Stack can complete the task correctly without a correction cycle. The Conductor assembles the brief from documentation the Library already contains. Try Kiluma free for 14 days at kiluma.ai.