Tester round call file and correction log template

Before the call goes out

• Freeze the graded size rangeDecide the exact sizes shipping in this release and stop drafting. A range that changes mid round invalidates the makes already finished, and testers in a size you later cut will not come back.
• Stamp the file with a version and a datePut the version on the cover and in the footer of every page. Testers must be able to tell you which file they printed, and the correction log has nothing to attach to without it.
• Write the yardage or fabric requirement per sizeTesters buy materials before they start, so a low estimate in the top sizes costs them money and costs you a tester. Round up and say what the sample used.
• Set the coverage target per sizeTwo finished makes per size is the working standard. Write the target down before applications open so you accept against gaps rather than against enthusiasm.
• Fix the three dates and do not move themApplications close, early notes due, final report due. Testers plan their own weeks around these, and a moved deadline is the fastest way to lose the ones who were on schedule.

The call file itself

• State the garment, the skill level and the techniquesName the constructions involved, such as a set in sleeve, a welt pocket, short row shaping or steeking. Testers self select accurately when the techniques are listed plainly.
• List the sizes you still need coveredPublish the range and mark which sizes are the priority. Applications skew to the middle unless you say clearly where the gaps are.
• Say what you supply and what the tester buysThe pattern file and a comp copy of the final version are yours. Fabric, yarn, notions and printing are usually theirs, and saying so upfront prevents a difficult conversation in week two.
• Define what a complete report containsGauge or test square measurement, size made, measurements taken on the finished garment, photos front and back, and any line where the instruction did not match the result.
• Set the terms for photos and creditSay whether you may use tester photos, where they will appear, and how the tester is credited. Get it agreed at application rather than at the end.

The correction log during the round

• Log every note the day it arrivesOne row per note, no matter how small or how likely it is to be tester error. Notes triaged in your head are the ones that go missing in the rebuild.
• Scope each item to a page and a size rangeRecord the page or chart, the affected sizes and the source tester. A dart intake fix that touches only the top four sizes must never be written as a whole pattern change.
• Mark each item accepted, declined or already correctDeclined items still get a reason in the row. When the same note comes back from a buyer a year later, the reasoning is on file and the reply takes a minute.
• Rebuild the file once, not five timesHold all accepted corrections until the log is closed, then make one pass through the source files. Rolling rebuilds are how page order and layer settings get broken.
• Recheck the test square, layers and page order after the rebuildPrint the test square from the exported PDF, not from the source. Layer toggles and page order are the two things most often broken by an otherwise clean correction pass.

After the pattern goes on sale

• Publish a versioned errata sheetOne page listing each correction with the pages and sizes affected and the version that fixed it. Buyers who already cut fabric need the change, not a whole new file to re-read.
• Replace the file in every place it is soldYour own store, any marketplace listing and any bundle. Note the date each channel was updated, because they never all happen in the same hour.
• Notify every buyer of the earlier versionSay what changed, which sizes it touches and whether a reprint is needed. Buyers in unaffected sizes should be told they need do nothing.
• Record who was notified and whenKeep the send list against the version. It answers the support email that starts with a question about which file the buyer has.
• Feed the correction back into your grading rulesIf the same class of error appears in the top sizes twice, the problem is in your grading approach and not in that pattern. Fix it in the block before the next release.