Start with one workflow and one reviewer
Choose a workflow with a stable source, a visible output, and a review step that already exists. Quote normalization, drawing log maintenance, and quantity worksheet preparation are good candidates. Avoid starting with scope interpretation or bid release, because those tasks depend on judgment that takes longer to calibrate.
Name one reviewer who will answer questions and check the first outputs. A shared inbox or a rotating reviewer creates ambiguity.
The assistant should know exactly who to ask when a source is missing or a rule does not fit the case. That single relationship is the core of the onboarding.
Prepare access and a source map
Set up named accounts with the minimum access the workflow needs. Confirm that the assistant can open the drawing set, the estimate workbook, the quote folder, and the project communication channel. Test the access before the first assignment so the first day is not spent waiting on permissions.
Build a source map that names the approved systems and the fields the assistant may use. Include the naming rules, the version conventions, and the location of the current drawing set.
If the team uses a shared drive with several copies of the same file, resolve that before onboarding. A source map that points to the wrong folder teaches the wrong habit.
Train on the estimate record, not just the software
Software training is necessary but not sufficient. The assistant needs to understand what a complete estimate record looks like: the source reference, the quantity basis, the pricing date, the assumption, and the approval. Walk through two or three real lines and point out the evidence that makes each one reviewable.
Use a completed example and a corrected example. The corrected example is more instructive because it shows what a gap looks like and how it was resolved. Keep both in the onboarding folder so the standard is visible after the training session ends.
| Stage | Deliverable | Exit check |
|---|---|---|
| Access | Named accounts and tested permissions | Assistant can open every approved source |
| Source map | Approved systems, folders, and naming rules | No duplicate or stale source in the map |
| Training | Two worked examples and one corrected example | Assistant can explain the evidence standard |
| First workflow | One bounded task with a reviewer | Every output has a source and a stop point |
| Exception script | Common cases and routing rules | Reviewer agrees with the default path |
| Expansion | A related second workflow | First workflow meets the review standard |
Write the exception script before volume arrives
List the ten most common exceptions in the workflow and write the expected response for each. Include a missing dimension, a conflicting quote, an expired document, a duplicate request, and a question that requires a commercial decision. For each, state what the assistant should check and where the item should stop.
The script should use plain language and fit on one page. If an exception is not on the list, the default is to route it to the reviewer with a short note. That default is safer than an improvised decision, and it gives the team a way to improve the script over time.
Review the first outputs closely
For the first two weeks, review every output rather than a sample. Check the source reference, the arithmetic, the status, and the stop rule. Record the errors by type so the pattern is visible.
If the same error appears twice, correct the checklist or the source map before adding more work. As the output stabilizes, move to a sample that includes a high value item, a recent revision, and a previously corrected item.
Keep the review record. The role boundary is easier to defend when the review history shows how the work was checked.
Add a second workflow only when the first is stable
Stability means the assistant can complete the workflow without asking the same question twice, the reviewer can check it in a predictable time, and the exceptions have a documented path. Once that is true, add a related workflow that uses the same sources and review habits. Do not add a workflow that requires a different judgment boundary at the same time.
For example, add quote normalization before adding alternate recommendations. Sequencing keeps the learning curve manageable and prevents a new task from weakening the controls on the first one.
Write the operating brief and keep it current
The operating brief should state the scope, the sources, the outputs, the stop rules, the reviewer, and the review cadence. Keep it beside the work, not in a policy folder that no one opens. Update it when a system, a template, or a responsibility changes.
Review the brief at the end of the first month and then quarterly. Ask the assistant which instructions were unclear and which exceptions were missing. The best onboarding documents are improved by the person doing the work, because they reveal the gap between the written process and the real one.
The first month review
At the end of the first month, review the workflow with the assistant and the named reviewer. Ask three questions: which instructions were unclear, which exceptions were missing from the script, and which checks took longer than they should. Turn the answers into specific changes to the brief or the template.
Do not use the review to add scope. Use it to make the current workflow more reliable. The ASPE professional estimator resources library is a useful reference for the professional standards the team is trying to protect.
The evidence index shows whether the assistant's output is leaving a trace that a reviewer can follow. Write the changes down and set a date to check them. An onboarding that improves only in conversation will drift back to the old habits.
A short revision log for the brief is enough. It shows the assistant that the process is being maintained and gives the reviewer a record of what was learned. Keep the revision log with the brief so a new reviewer can see how the process evolved.
