# Reference Materials Forms, How Tos, SOPs, Security Documents, and anything NOT related directly to Survox or Non-Survox systems can be found in this book. # Nightly QC Guidelines - Namefile Checks ## Overview The QC team at MAXimum Research plays a critical behind-the-scenes role in ensuring that accurate, clean data reaches our clients. Every night that a survey project is running, QC team members are responsible for reviewing completed interviews, identifying miscoded responses, correcting them before data is sent, and reporting their findings via email. The QC process is broken into five parts: 1. **Setup/Preparation** -- Done once when a new job starts 2. **Running the QC Process** -- Generating the data listings for review 3. **Checking and Flagging Corrections** -- Reviewing each completed interview 4. **Applying the Corrections** -- Adding flagged case IDs to the cleaning script 5. **Wrapping Up / End of Shift** -- Final pass, cleaning, and QC email > **Note:** All QC processing is performed via PuTTY or Termius (terminal/SSH), unless otherwise specified in the project instructions. --- ## What Is "Namefile" QC? As of 2022, the primary focus of the QC process is verifying the **namefile** question on political poll surveys. "Namefile" refers to how the responding person is classified: - **Listed Name** -- The person the sample record belongs to answered the phone and completed the survey. - **Someone Else** -- A different person in the household answered the phone and took the survey. Ideally, the more "Listed Name" completions, the better. Most clients permit a percentage of "Someone Else" completions, though rare projects require 100% Listed Name responses. QC's job is to verify that interviewers coded this correctly for every completed interview. --- ## Part 1: Setup and Preparation > **As of 2024, this section is handled by the Programmer as part of loading a project into Live Mode. QC team members are not expected to perform these steps. This section is provided for reference only.** Before a job begins, the Programmer will need the **CfMC Info Sheet** for the project, which is emailed prior to the job starting. From it, they need: - **Jobname** -- Listed at the top of the Info Sheet - **QC Variables** -- Listed approximately two-thirds of the way down the sheet. There may be a few or many, depending on the client's requirements. ### What the Programmer Does **1. Log into the Survox Phone Server** Connect via SSH using PuTTY or Termius:

``` sv10.maxresinc.com ``` **2. Navigate to the data directory**

``` data ``` This places them in `/cfmc/data/` **3. Copy the QC template for the project**

``` cp jobname_qc.spx xxx_qc.spx ``` Replace `xxx` with the actual project name (example: `ny1_qc.spx`) **4. Open the new file for editing**

``` edit xxx_qc.spx ``` Inside this file, several `>Define` codes appear near the top. The first two are **required**; the rest are optional based on PD instructions:

Define Code	What to Do
`@jobname !!!!`	Replace `!!!!` with the jobname (example: `ny1`)
`@askname !!!!,!!!!`	Replace the first `!!!!` with the SAMPLE name from the Info Sheet, and the second `!!!!` with the DATA name (example: `orig_name,namex`)
`@vars2`	If the PD wants additional variables checked (example: email address), list them here separated by commas. Remove the two apostrophes in front of the `>define` line to activate it.
`@namefile`	If this is NOT a namefile job but still requires cleaning, add two apostrophes in front of this `>define` line to disable it.
`@showOE`	If the PD requests open-ended responses be listed in the output, activate this define.

Save and close when done (`Ctrl+X`, `Y`, `Enter`). **5. Add the job to the QC queue**

``` edit runqc ``` Scroll to the last line and add the job, mirroring the format of the lines above it:

``` m2 xxx_qc.spx ``` Save and close (`Ctrl+X`, `Y`, `Enter`). --- ## Part 2: Running the QC Process > QC must be checked **every day**, for **every job** that requires it. When you check during your shift varies, but each job must be checked **at least once during the shift** and **again after the job ends for the night**. Use the following schedule as a guide: ### Weekday Check Schedule

Job End Time	Initial Check	2nd Check	Final Check
10:00 PM or earlier	7:00 PM	--	At close
11:00 PM	7:00 PM	9:00 PM	11:00 PM
12:00 AM or later	8:00 PM	10:00 PM	12:00 AM

### Weekend Check Schedule

Job End Time	Initial Check	2nd Check	Final Check
6:00 PM or earlier	3:00 PM	--	At close
8:00 PM	4:00 PM	6:00 PM	8:00 PM
9:00 PM or later	4:00 PM	7:00 PM	Close time

### Steps to Run QC Listings **1. Log in to Survox10** Connect via PuTTY/Termius to `sv10.maxresinc.com` **2. Navigate to the data directory**

``` data ``` **3. Run the QC batch**

``` runqc ``` This will open a file where you must update the date: - Find the date field: `[date#mmddyy]` - Change `mmddyy` to today's date (example: `090922` for September 9, 2022) - **If cleaning data after 12:00 AM EST**, enter both today's and the previous day's date:

``` [date#091222-091322] ``` - Save and close (`Ctrl+X`, `Y`, `Enter`) The system will then process each job in the queue file automatically. When it finishes scrolling through, you are ready to check the data. --- ## Part 3: Checking for Corrections > This is the most important part of the QC process. High attention to detail is required. A missed case means bad data reaches the client. **Recommended:** Have scrap paper handy for notes, and have your email open and ready. You will need **one email per job** you are responsible for cleaning. ### Prioritizing Jobs When multiple jobs are running simultaneously, start with the jobs **ending soonest**. Data is sent to clients no later than 1 hour after dialing finishes for the night -- the sooner you clean, the better. ### Opening a Job's List File Each job generates a list file named `jobname.lst` (example: `ny1.lst`). To open it from your terminal:

``` edit jobname.lst ``` When done reviewing, press `Ctrl+X` to close. If prompted to save changes, press `N` -- you are only reading this file, not editing it. ### What to Look For Each completed interview entry will show the namefile code, the original sample name, and the name collected during the survey. It will look like this:

``` Namefile: AnswerFrom(name)/Listed Name -- or -- Someone Else Orig_name: Brian Carson Name/Namex: Jennifer ``` **The rule is simple:** - If the two names **match** -- Namefile should be coded as **Listed Name** - If the two names **do not match** -- Namefile should be coded as **Someone Else** - If the codes do not line up with the names, this is a **flagged case** > **When in doubt, leave it as the interviewer coded it.** Some name variations are obvious (Bob vs. Robert, Patty vs. Patricia), but others are not. If you cannot be certain, do not flag it. ### Recording Flagged Cases As you find flagged cases, copy and paste the case block from the list file directly into your QC email. Then note what was wrong and what correction will be made. Example:

``` ******************** Case ID: 111155 ******************** Statcode: COMPLETE Interviewer: 1281 Richard Kuo Survey Length: 15.65 Date Stamp: MON SEP 12 2022 12:37PM Recording (if App): cm_220912_123741_caseid111155_6088505681_intv1281 Assigned Quotas: Region 4, Landline, Name_On, 65 and over, White, Male **Changed to Someone Else ``` Continue through the entire file. When you reach the end, **note the last Case ID shown**. On your next scheduled check, use `Ctrl+W` in the editor to search for that ID and pick up right where you left off. --- ## Part 4: Applying the Corrections Once you have finished checking a job, it is time to add the flagged case IDs to the cleaning script. ### Opening the Cleaning Script **1.** From your terminal:

``` stu jobname ``` (Example: `stu ny1`) **2.** Navigate to the dp directory:

``` cd dp ``` **3.** Open the cleaning script:

``` edit qc.spx ``` ### Adding Case IDs Inside `qc.spx`, scroll down until you find three sections labeled with `>rep $A=` at the start of the line. Each section contains placeholder IDs (`000001,000002,000003`) that you will replace with the actual flagged case IDs. The three sections are clearly labeled:

Section	Purpose
Part 1	IDs to change FROM Someone Else INTO Listed Name
Part 2	IDs to change INTO Someone Else (from Listed Name)
Part 3	IDs to DELETE entirely (rare -- use with caution)

Replace the placeholder IDs with your flagged IDs, separated by commas. ### If Your ID List Gets Long If the list of IDs is too long to fit on one line, end the line with `,&` and continue on the next line:

``` >rep $a=000001,000003,234567,436547,623468,& 658324,574834,134677,673472 ``` > **IMPORTANT:** Do NOT place a comma after the last ID in the list. A trailing comma will prevent the script from running correctly. Save and close the file (`Ctrl+X`, `Y`, `Enter`), then move on to the next job on your list. Once all assigned jobs have been checked and corrected, you are free to work on other tasks until your next scheduled check time. --- ## Part 5: Wrapping Up / End of Shift When a job has closed for the night, perform **one final pass** through its list file and add any remaining flagged cases to the cleaning script. > You have approximately **1 hour** from the time dialing stops to complete cleaning before the data is automatically sent to the client. If you believe you cannot finish in time, contact the Project Director (PD) immediately so they can pause the automatic send until cleaning is complete. ### Sending the QC Email After a job is fully cleaned for the night, send your QC email. **Do not wait for all jobs to be finished** -- send each email as you complete that project. - **To:** Quality *(email group)* - **Subject:** `Quality Report -- Jobname` - **Body:** - If there were no issues: write `Clean, No Issues` - If there were corrections: paste in all the flagged case blocks you collected during Part 3, along with the correction notes for each When all emails are sent, you are done for the night. --- ## Quick Reference: Key Commands

Command	What It Does
`data`	Navigate to `/cfmc/data/`
`runqc`	Run the nightly QC batch for all queued jobs
`edit filename`	Open a file for editing in the terminal
`stu jobname`	Enter a job's Survox environment
`cd dp`	Navigate to the dp directory within a job
`Ctrl+X`	Exit the editor
`Ctrl+W`	Search within the editor (find a Case ID)
`Y` + `Enter`	Confirm save when prompted
`N`	Discard changes (use when closing .lst files)

# Manual - Survey Response Coding Guidelines ## Overview This document outlines the standard process used by MAXimum Research's Data Processing team for coding open end and Other Specify survey responses. It is intended for use by both coders and programmers, and covers everything from initial information gathering through final file delivery. The process is broken into four sections: - **Section I – Gather Information:** What to collect from the client and PD before work begins. - **Section II – Coding Preparation:** How to set up your workspace, codebook, and data files. - **Section III – Building the Lists:** How to read responses and develop approved code lists. - **Section IV – Coding the Responses:** How to assign codes, verify your work, and deliver a finished file. Following this process consistently ensures coded data is accurate, well-documented, and easy for others to pick up if needed. --- ## Section I – Gather Information Before coding can begin, several key pieces of information must be gathered from the client and/or Project Director. Each item is detailed below, along with why it matters. ### 1. Coding Percentage Method Most clients specify a percentage threshold for coding. This can be presented in one of two ways: #### a. Percent to Code This method is most commonly used for Other Specify questions. The client specifies a threshold — for example, 5% — meaning a code should be created for any response that accounts for 5% or more of the total respondents **answering that question**. This is **not** 5% of the "Other" responses — it is 5% of everyone who answered the question. - If the question was asked of all respondents, use the total quota as the base. - If only a portion of respondents were asked the question, use that sub-group as the base. A project marginal will show you this. You do not need to wait until the job is complete to begin coding with this method. If a response is already at or above 5% in a partial file, it will very likely remain there. You will simply need to re-check uncoded responses in later files to see if any have crossed the threshold. #### b. Percent of Other Code This method sets a target for how small the remaining "Other Mentions" bucket should be when coding is complete. For example, a client may require that the Other code represents no more than 10% of respondents when finished. The smaller the allowed percentage, the more thorough the coding must be. - Like the Percent to Code method, the base is either the total quota or the sub-group answering, depending on the question. - Unlike Percent to Code, this method typically requires **multiple passes** through the data as you work toward bringing the remaining Other responses below the target threshold. ### 2. Check for Existing Codes and Lists Open End questions typically do not have a pre-built response list. However, some clients may provide a starter list to build from, and new codes can be added to it. Other Specify questions will always have an existing code list attached to the driving question. **Always refer to the QPX file in Textpad — not the hard copy of the survey** — when reviewing code lists. The hard copy may be outdated or may show different code/response combinations than what is actually in use. #### a. Open End Questions In most cases, the programmer will anticipate coding is needed and will build a hidden coding question into the QPX. A standard 3-digit code structure is used: - 997 = Other Mentions - 998 = Don't Know - 999 = Refused - 000 = No Answer / None / Blank #### b. Other Specify Questions Review the existing list in the QPX to identify where the codes left off, and confirm what values are assigned to Other, Don't Know, Refused, and None. When the programmer knows coding will be needed, they will typically follow the same 3-digit structure above — but when coding is unexpected or the client requests specific codes, verify what was actually used before proceeding. #### c. Client Codebooks and Special Instructions This is also the time to ask the PD whether the client has provided a codebook to follow, or has any specific requirements for the coded responses. An example would be a client requesting that a Positive / Neutral / Negative net be added to an open end asking why something was rated a particular way. ### 3. Timeline Timeline is the most critical factor in planning the coding process. You need to know when coded data is due so you can schedule accordingly. As a general rule of thumb: - Allow **1 hour per 100 cases, per question** to complete coding. - Add **1 additional hour per question** when you also need to build the code list from scratch. If coded data is due the day after a job completes, coding work should begin as soon as data starts coming in — do not wait until the job is finished. Bid sheets and job alerts should have deadline information listed, provided the salesperson and/or PD were informed prior to the job start. --- ## Section II – Coding Preparation Once you have gathered the necessary information, it is time to set up your workspace before coding begins. There are five steps involved in preparing to code. ### 1. Create Your Coding Folder Inside the project's job folder, create a new folder called **Coding**. All coding work must be saved here so that anyone else who needs to step in can find and continue the work without confusion. ### 2. Create Your Codebook in Word Start with a blank Word document. At the same time, open the survey QPX file in Textpad. The QPX can be found at: ``` Phone Studies: t:\studies\phone\jobname\jobname.qpx Online Studies: w:\studies\client\jobname\jobname.qpx ``` In the QPX, search for the text "**!TEX"** (without quotes). This tag is used for 99% of open end and Other Specify questions. For each instance you find: - Look one or two lines above it for the question label, which will appear in the format **{Q##:** — this is the label you will see in the open end Excel files during coding. - Most Other Specify labels end in **\_os**. Most Open End labels end in **\_oe**, or have no suffix. - Other Specify questions will also typically have an **!if** condition line below the label, identifying the base — meaning which respondents are routed to this question. For example: **{q12\_os:** with **!if q12(21)** means question Q12 is the list question and code 21 is the "Other Specify" code. Copy and paste each question from the QPX into your Word codebook. You may clean up the formatting to make it more readable. When finished, cross-reference your list against the hard copy of the survey to confirm no questions were missed. **Always follow the code numbering from the QPX**, including the number of digits used: - If a question uses codes 01–10, new codes must be in the range 11–99. - If a question uses codes 001–015, new codes must be in the range 016–999. - If a question uses single-digit codes (1–5), new codes can use 6–9, then A–Z. - If more codes are needed beyond what the field allows, the programmer must create a new question. They will provide the updated list when ready. For all Open End response questions, always include the four standard codes listed in Section I, Item 1a (997, 998, 999, 000). ### 3. Note Single vs. Multiple Response Questions As you build your codebook, note whether each question is **single response** (only one code can be assigned) or **multiple response** (more than one code can apply). This will affect how you code the data later. Typically this can be garnered from the question text, by words like "Select ALL" or "Which ONE", etc. If unsure, DP can confirm. ### 4. Obtain Sample Data You will need sample data to begin building code lists. If you know how to set up and run the **oe\_edit.spx** file located in each job's DP folder, do so now. If not, ask the PD or Programmer to pull a file for you. **Best Practice:** Do not run the file on data collected the same day you are running it. Always run it from the first day of the job through yesterday's date. This avoids having to strip out already-coded records when you run subsequent files later. Save the output file in your Coding folder using the naming convention: ``` openends_mmddyy.xlsx ``` This prevents it from being accidentally overwritten by later runs. When you run the file again, run it from the day after your last file through yesterday's date, and repeat this process until the job is complete. ### 5. Begin Building Code Lists At this point you are ready to start developing your code lists. This step requires uninterrupted concentration — similar to programming a survey. Do not hesitate to send an email to your team letting them know you will be unavailable for the next several hours. Use Excel filters to view one question at a time and sort responses alphabetically. This helps group identical answers together (such as "None" or "Don't Know"), but it is only a starting point. You must read all responses carefully to truly understand what the data is saying. The full process for building code lists is covered in Section III. --- ## Section III – Building the Lists This section covers the process of building code lists for Open End and Other Specify questions in detail. ### 1. Set Up Excel Filters Filtering your data is the first step, and makes the response review process much more manageable by letting you focus on one question at a time. 1. With your coding file open, click on the first row (the header row containing Case, Question, and Response labels). 2. Click the **Data** tab, then click the **Filter** button. Small dropdown arrows will appear next to each column header. 3. Click the arrow on the Question column. Uncheck **Select All**, then select only the question or questions you want to work on. In cases where multiple questions share the same list (such as stores or hospitals), select all relevant questions together. 4. Once your question filter is applied, sort the Response column A to Z. This groups similar answers together and makes it easier to identify Don't Know, None, Refused, and other common responses at a glance. ### 2. Start Building Codes **Do not actually code the data at this stage.** The goal right now is to build the list only. Making changes to codes after data has already been assigned is significantly more time-consuming than getting the list right first. 1. Open your codebook (see Section II, Item 2) and navigate to the question you are working on. 2. Keep scrap paper nearby. As you read through responses, jot down potential codes and tally how many times you see each one. Once a response meets the coding percentage threshold discussed in Section I, add the response text to your Word codebook — but do not assign a code number yet. 3. Watch for responses that use different words but carry the same meaning. For example: "They are close to my home," "Convenient locations," and "There are lots of branches in my area" all describe the same concept and should be grouped under one code. 4. Also watch for responses that sound similar but have opposite meanings. For example, when asked why something was rated positively or negatively: "There are a lot of locations" and "There are too many locations" both reference quantity, but mean very different things in context. 5. Read the full response before assigning any code. Respondents often ramble. A lengthy response may ultimately be saying just one simple thing. For example: "I am really not sure what the brand was called, all I know is that the store always has it in stock and it has their logo on it" — this is a roundabout way of saying "Store Brand" and should not be coded as Don't Know. 6. After your first full pass through the file, assign code numbers to the list items that met the threshold and add them to the codebook. Mark them off your scrap paper so you know they made the cut. Hold onto the scrap paper — you will reference it again during subsequent passes. 7. Submit the completed list to the PD and/or client for approval. **Do not begin coding responses until approval is received.** --- ## Section IV – Coding the Responses Once your code list has been built and approved by the PD and/or client, you are ready to begin assigning codes to the actual response data. ### 1. Filter and Sort Before You Begin Just as when building the lists, apply your Excel filter and work one question at a time — or group questions that share the same list together. Sort the response column again if it is not already sorted. ### 2. Assign Standard Codes First Before coding open responses, assign your Don't Know, Refused, and No Answer codes first. Then apply a filter to the code column and hide those already-coded rows, leaving only the blanks visible to work through. ### 3. Code the Responses Work through the remaining responses following your approved codebook. A few important rules to follow: - **Do not code Other Mentions yet.** Leave responses that do not meet any code as blank for now. After additional data files are added, you may be able to create new codes from what remains. - If you are coding Other Specify responses and a respondent's answer actually matches an existing code on the driving question's list, you may correct it here. - As when building the lists, stay alert for responses that look different but share the same meaning, and for responses that look similar but mean something different in context. - **You do not need to zero-fill code numbers.** The programmer will handle that before adding the data. If the list uses 001 for a code, entering just 1 in the cell is fine. ### 4. Run a Pivot Table to Check Your Work After completing your first pass on a question, run a pivot table to verify your coding before moving on. To do this: 1. Highlight the QLabel and Code columns together. 2. Click the **Insert** tab and select **Pivot Table**. When the dialog box appears, click **OK**. 3. A new sheet will open with the pivot layout and field boxes on the right side. Configure it as follows: - Drag the **QLabel** field into the **Filters** box. - Drag the **first Code column** into the **Rows** box. - Drag the **first Code column** into the **Values** box. - If the Values box shows **Sum of** instead of **Count of**, click the field, select **Value Field Settings**, and change it to Count. 4. Use the filter at the top of the pivot table to select the question you just coded. 5. Review the counts against your codebook to confirm nothing was mistyped or miscoded. 6. Repeat this process for each additional code column by swapping out the Code field in both the Rows and Values areas, again ensuring each is set to Count rather than Sum. Once you are satisfied the coding is accurate, move on to the next question and repeat the process from Step 1 of this section. ### 5. Finishing a Complete Pass When you have worked through all questions in the file: 1. Remove all filters so the full dataset is visible again. 2. Save the file. ### 6. Adding Additional Data Files If more data files will be coming in as the job continues: 1. Open both the master coding file and the new data file. 2. Copy all data rows from the new file and paste them at the bottom of the master file. 3. Return to Step 1 of this section and work through the new data. 4. After adding a second file — or once no further files are expected — go back and re-examine all blank (uncoded) responses. Determine whether any new codes can be created from what remains. PD and/or client approval is still required before adding new codes. ### 7. Wrap Up 1. Once all passes are complete and no further codes will be added, go through the remaining blank responses and assign them the Other Mentions code. Every record must have a coded response before the file is considered done. 2. Notify the PD and Programmer that coding is complete. --- ## Summary Coding survey responses is a methodical process that requires careful preparation, close reading of the data, and clear communication with the PD and client at key checkpoints. Rushing any stage — particularly list building or approval — creates significantly more work downstream. When in doubt: slow down, re-read the responses, and ask the PD. A well-coded file the first time is always faster than correcting a poorly coded one after the fact. # Understanding AI Use - What it Can/Cannot Do and How to Best Use it. ## Overview Claude, developed by Anthropic, is the preferred AI assistant at MAXimum Research, as of March 2026. While not every employee has access to a paid Team account yet, Claude is the company-sanctioned LLM for any AI-assisted work. If you are using an AI tool for company tasks, this is the one to use. This primer covers what Claude is, how it works, and how to use it effectively and responsibly within our environment. Read it once before you start -- it will save you a lot of confusion down the road. ### Free vs. Paid -- What You Can Actually Do Claude has a free tier that anyone can access at claude.ai. It works, but it has real limitations worth knowing about before you run into them mid-task.

Feature	Free	Paid (Team)
Basic chat and Q&A	Yes	Yes
File uploads	Limited	Yes
Projects	No	Yes
Project-level shared instructions	No	Yes
Web search	Limited	Yes
Higher usage limits	No	Yes
Access to latest/best models	No	Yes
Connectors and integrations	No	Yes
Memory / search old chats	Limited	Yes

The short version: **free tier is fine for one-off questions and simple tasks.** Anything involving Projects, file management, integrations, or heavy back-and-forth will either not work or hit a usage wall quickly. If your role regularly involves using Claude for company work and the free tier is getting in the way, talk to Brian about whether a paid seat makes sense. --- ## !! SECURITY WARNING -- Data You Are NOT Permitted to Upload !! This is not a suggestion. This is company policy. **No respondent-level data or Personally Identifiable Information (PII) may be uploaded to Claude or any other AI tool -- under any circumstances.** This includes but is not limited to: - Survey response data at the individual/respondent level - Names, phone numbers, email addresses, or mailing addresses - Any data that could identify a specific person - Client data files, sample files, or anything containing contact records When Claude helps you analyze data, work with aggregates, summaries, and counts only. Strip or anonymize any file before uploading if there is any doubt. Violations of this policy are a serious security and compliance matter. If you are unsure whether a file is safe to upload, ask Brian before uploading it. --- ## What Claude Is (and Isn't) Claude is an AI assistant that is genuinely useful for writing, research, coding, summarizing documents, drafting emails, and a lot more. It has a built-in knowledge base trained up to a certain date, but it can also search the web when it needs current information -- you'll see it say so when it does. Either way, it doesn't automatically know anything about you, your job, or how you like to work -- **until you tell it.** One important thing to understand upfront: **Claude does not have a persistent global memory.** Every new chat starts with a blank slate, except for what is stored in your User Preferences (more on that below). Anything Claude "learns" during a conversation stays in that conversation only. --- ## The Three Layers of Context Understanding these three layers will save you a lot of frustration: **Layer 1 -- Your User Preferences (Global)** This is text you store in your profile settings. Claude reads this at the start of *every* chat and *every* project, no exceptions. This is the right place to put: - Your name and role - How you prefer responses formatted - Things you never want Claude to do - Background about your job or department To set it: click your profile icon (bottom left) > Settings > Personal Preferences. ***\*While you are in Settings, go to the Capabilities tab and turn on both options at the top*** -- "Search old chats" and "Generate memories from chat history." These are off by default. Turning them on lets Claude reference your past conversations and gradually build a better understanding of how you work over time. Worth doing on day one. **Important caveat:** these features only apply to regular chats outside of Projects. Chats inside a Project are not searched and do not contribute to memory generation. For that reason, keeping good Project instructions and uploading reference files to the Project file area is even more important when working inside a Project. **Layer 2 -- Project Instructions (Shared within a Project)** When you create a Project, you can add instructions that apply to every chat *within that project*. This is the right place for team-shared context -- workflows, terminology, standard formats, etc. Everyone added to the project benefits from those instructions automatically. **Layer 3 -- The Chat Itself** Everything said in the current conversation. Claude remembers this going back about 200,000 words (called a "context window"), but once the chat is closed, that context is gone. Starting a new chat means starting fresh. --- ## Teaching Claude Things -- Where It Actually Sticks This is the most common misunderstanding new users have.

Where you teach it	Who benefits	How long it lasts
User Preferences	You only	Until you change it
Project Instructions	Everyone in the project	As long as the project exists
Inside a chat	Nobody after the chat ends	That chat only

**The bottom line:** If you want Claude to remember something permanently, it has to go in your User Preferences or a Project's instructions. Telling Claude something mid-conversation does NOT save it for next time -- even if Claude says "got it" or "I'll remember that." --- ## Projects -- The Right Tool for Team Work For anything that involves multiple steps, multiple people, or that you'll return to over time, use a **Project** instead of a regular chat. - Projects have their own instruction block (see Layer 2 above) - You can create multiple chats inside one project, keeping different topics organized - Projects can be shared, so everyone works with the same context baked in - Think of it like a folder with a briefing document attached -- every chat in that folder starts with that briefing already read **Good uses for a Project:** - A recurring workflow you run monthly - A multi-step task that will take several sessions - Anything a team of people will all use Claude for in the same context --- ## Managing Long Projects -- Chat Handoffs and Naming Every chat has a context window limit -- roughly 200,000 words of back-and-forth before things start getting trimmed. On a big project, you will hit that wall. The solution is intentional **chat handoffs**: when a chat is getting long or a phase of work is complete, start a fresh chat inside the same project and carry forward only what matters. **How to hand off cleanly:** Before closing a long chat, ask Claude to summarize the current state -- decisions made, files produced, open questions, next steps. Paste that summary at the top of your new chat to get it up to speed instantly. Because you are still inside the same Project, the project-level instructions are already loaded automatically. **Naming your chats matters more than you think.** When a project grows to 8-10 chats, a list of untitled or vague chat names becomes useless fast. Use a consistent prefix so you can find what you need at a glance. Some examples:

Prefix	Use it for
(SPOKE)	A focused work session on one specific piece of the project
(DOC)	A chat dedicated to producing a specific document or deliverable
(BUGS)	Tracking and working through a list of issues or errors
(REVIEW)	Reviewing, editing, or QA on something already built
(PLAN)	Planning, outlining, or scoping before work begins

You don't have to use these exact labels -- pick whatever makes sense for your workflow. The habit of labeling consistently is what matters. --- ## Practical Tips **Be specific.** "Write an email to a client" gets you a generic result. "Write a professional but friendly follow-up email to a market research client who hasn't returned our survey results, keep it under 150 words" gets you something usable. **Give it context.** Claude doesn't know your industry jargon, your client names, or your internal processes unless you tell it. Paste in the relevant background right in the chat. **Correct it directly.** If it does something wrong, just say "no, do it this way instead." It will adjust for the rest of that conversation. **Don't trust it blindly on facts.** Claude can be confidently wrong, especially on specific numbers, dates, or anything that might have changed recently. Always verify anything critical. **Session limits are real.** Heavy use (lots of long back-and-forth, big documents) can hit a usage limit. It will warn you at 80%. If you hit the wall, there are reset windows roughly every few hours. --- ## What Claude Can and Cannot Access Claude runs entirely in your browser session. It has no reach into your network, your file system, or any company resource unless you explicitly hand it something. Understanding this prevents a lot of frustration. **Connectors and Integrations** Claude can be connected to external services (like network drives, Google Drive, Box, and others) via connectors installed at the team level. When a connector is installed at the team level, everyone on the team benefits from it automatically -- you don't need to set anything up yourself. However, **only Brian can approve and install connectors** for the MAXimum Research team account. If you think a connector would be useful for your workflow, bring it to Brian first. One important note even with connectors installed: expanded access generally means better read and list capability -- Claude can browse and pull in content without you manually uploading it. Writing files back out to a connected drive is still not something Claude can do. That limitation does not go away with a connector. --- **What Claude can do with files:** - Read and work with files you upload directly into a chat or project - Generate new files for you to download and save yourself - Read files shared via connected integrations (like Google Drive or Box, if configured) **What Claude cannot do:** - Connect to a network share, mapped drive, or folder on your machine - Save or write files anywhere on your system or the company network - "Watch" a folder or pick up new files automatically - Remember a file you showed it in a previous chat without it being re-uploaded A common misconception: giving Claude a file path (like `U:\Projects\report.docx`) does nothing on its own. **Without a connector installed**, Claude cannot reach out and grab it -- you have to upload the file or paste the content in yourself. If a connector has been set up by Brian for that drive or service, Claude may be able to access it directly -- but don't assume that capability exists unless you've confirmed it with Brian first. Think of Claude's file access as **read-only and session-scoped** -- it can only see what you hand it, and only for as long as that chat is open. Writing files back out is always your job. --- ## Files -- What Gets Saved and What Doesn't This is another area where Claude behaves differently than most tools people are used to. **Claude does not store files it creates.** If Claude writes a document, builds a spreadsheet, or generates a script in one chat, that file does not automatically exist anywhere. It lives in that chat only. If you need it again -- in a different chat, a different spoke, or a week from now -- you are responsible for saving it and bringing it back. **How to keep files accessible across chats in a Project:** Claude.ai Projects have a file upload area at the project level. Anything uploaded there is available in every chat inside that project automatically. Use this for: - Reference documents Claude will need to consult repeatedly - Files Claude created in a previous chat that future chats will need to build on - Templates, standards, or source data that apply to the whole project **Claude does not version or overwrite files.** If you upload a new version of a file that already exists in the project, both copies will sit there with the same name. Claude has no way to know which is current. Before uploading a revised file, either: - Remove the old version from the project files first, or - Add a version indicator inside the file itself (a date, a version number in the filename or header) so it is unambiguous which one is current The habit to build: **if Claude made it and you need it again, save it before you close the chat.** --- ## System Integrations/Connectors/Tools Claude supports a growing list of connectors to external tools and services. Remember, all of these must be approved and installed by Brian before they are available to the team. Here are some worth knowing about:

Integration	What it adds	Who installs it
Microsoft Excel	Claude can read, analyze, and help build spreadsheets directly	You -- install the add-in yourself
Microsoft Word	Claude can read and help draft/edit Word documents	You -- install the add-in yourself
Microsoft PowerPoint	Claude can help build and edit slide decks	You -- install the add-in yourself
Google Drive	Browse and pull in files from a connected Drive	Brian
Box	Browse and pull in files from a connected Box account	Brian
Notion	Read and write to a connected Notion workspace	Brian
Asana	Create and manage tasks directly from a chat	Brian
Slack	Search messages, post updates, interact with channels	Brian
Atlassian (Jira/Confluence)	Read and create tickets, search documentation	Brian
HubSpot	Pull CRM data, contacts, and deal info	Brian
Canva	Generate and edit graphics and design assets	Brian

This list grows regularly as Anthropic adds new connectors. If there is a tool your team uses daily that is not listed here, it is worth checking -- and if it exists, talk to Brian about getting it added. --- ## ## Final Thoughts -- Just Start Using It The best way to get comfortable with Claude is to use it. Start small -- draft an email, summarize a document, ask it to explain something you've been meaning to look up. You'll get a feel for how it thinks and how to talk to it pretty quickly. It won't always get things right on the first try, and that's normal. Correct it, refine your request, give it more context. The more clearly you communicate what you need, the better the result. Think of it less like a search engine and more like a capable colleague who needs a decent briefing before jumping in. AI tools are only going to become more embedded in how we work. Getting comfortable with Claude now puts you ahead of that curve. There is no wrong way to learn it -- just jump in. *Questions, issues, or requests for integrations -- see Brian.* # Standard Market Research Formulas ## Overview This reference document defines the key performance metrics used in project reporting at MAXimum Research. It is intended for use by Sales, Project Directors (PDs), and Phone Operations staff. Metrics are organized by data collection channel: **Phone** and **Web / SMS**. Understanding these rates helps evaluate project health, sample quality, and overall field performance. **A note on manual calculations:** When calculating any of these metrics by hand, results will always appear in **decimal format** (e.g. `0.45`). With the exception of **Production Rate**, all metrics should be interpreted as a **percentage** -- meaning `0.45` = **45%**. Production Rate is expressed as a plain number representing completes per hour (e.g. `2.5` = 2.5 completes per hour). --- ## Phone Metrics ### Production Rate **Formula:** `Completes / Hours Worked` Production measures how many completed interviews are achieved per hour of calling time. It can be calculated at the **project level** or broken down by individual **agent / interviewer (INTV)**. Higher is better. Every project carries two production benchmarks: - **Bid Rate** -- The minimum completes-per-hour needed to meet the budgeted cost of the project. Falling below this rate puts the project over budget. - **Goal Rate** -- Typically set at between 15% and 20% above the Bid Rate. This is the target agents and INTVs should be actively working toward during a shift. Reaching or exceeding the Goal Rate is profitable for both the company and INTVs as it means less man-hours were required to reach the client's expected # of completes. From and INTV standpoint, exceeding the Goal opens the possibility of earning incentive, a bonus to their payrate while on this project. - **Bid Rate & Goal Rate** may change over the course of a project as incidence, survey length, contact/cooperation rates all play a role in assigning/calculating these rates. The rates could increase or decrease multiple times on any given project. ### Incidence Rate **Formula:** `(Completes + Qualified Refusals) / (Completes + Qualified Refusals + Overquotas + Terminates)` Incidence is the percentage of people who *start* the survey and actually qualify to complete it. It reflects how well the available sample matches the target population for a given project. **Qualified Refusals** are respondents who made it through the screener and qualified for the survey, but then declined to participate in the main portion. Because they did qualify, they are counted in the incidence numerator. Incidence can vary significantly from project to project and can shift mid-field. Common causes of a lower-than-expected incidence include: - **List accuracy issues** -- For example, a project targeting registered Democrats may be reaching a high volume of other party affiliations, resulting in excessive terminates early in the survey. - **Survey design** -- A higher number of screening questions gives more opportunities for respondents to terminate before qualifying. - **Quota closures** -- When quotas fill faster than anticipated and the sample cannot suppress already-filled records, those calls still go out and result in overquotas rather than completes. Sales works with the client to establish an initial incidence estimate before fielding begins, and it is common to adjust that rate mid-field as actual data provides a clearer picture. ### Contact Rate **Formula:** `(Completes + Suspends + Refusals + Terminates + Overquotas + Callbacks + Respondent Hang-Ups + Against Company Policy + Non-Residential/Business/Government) / Total Calls Made` Contact Rate is the percentage of all calls made that resulted in a *true contact* -- meaning a live person was actually reached. Higher is better. This metric has a direct upstream impact on both incidence and production. If contact rates are low, fewer people are being reached per hour of dialing, which compresses the opportunity to generate completes regardless of how well the rest of the project is performing. *\*This should NOT be confused with the dialer's CONNECT rate, as that will generally be higher. CONNECTS also contain Answering Machines, "Dialer Dead Air" calls, Language Barriers, and other calls that make it through to an agent/interviewer but are not a true "contact".* ### Cooperation Rate **Formula:** `(Completes + Suspends + Terminates + Overquotas) / Total Contacts` Cooperation Rate measures, of all the people actually contacted, what percentage showed enough interest to *at least begin* the survey -- regardless of whether they ultimately completed it or qualified. Higher is better. This is distinct from Contact Rate. Contact Rate asks *"Are we reaching people?"* Cooperation Rate asks *"Of the people we reach, are they willing to engage?"* ### Refusal Rate **Formula:** `Total Refusals (Soft + Hard + DNC) / Total Contacts` Refusal Rate is the percentage of contacts who were *not* willing to participate and refused out of the call entirely. Lower is better. Elevated refusal rates may point to one of two things: - **Agent / INTV miscoding** -- Calls being incorrectly dispositioned as refusals when they may belong in another category. This is worth auditing at the interviewer level if rates spike unexpectedly. - **Subject sensitivity** -- Some topics (women's health, taxes, personal medical issues, etc.) generate genuinely higher refusal rates because respondents are simply not willing to discuss them with a stranger over the phone. This is expected and should be factored into project planning. ### Disconnect Rate **Formula:** `Disconnected Numbers (All Dead Dialer Codes + INTV-Coded Disconnects) / Total Calls Made` Disconnect Rate reflects the percentage of numbers dialed that are no longer in service. Lower is better. This metric is primarily used as an indicator of **sample quality**. Expected ranges vary significantly by sample type: - **Client-provided lists / Voter roll files** -- Should produce very low disconnect rates. If a client list is running high, the list is likely outdated. - **Consumer sample** -- May run slightly higher than client lists, as consumer databases are not updated as frequently. - **True RDD (Random Digit Dialing)** -- Disconnect rates can be quite high by nature, since RDD numbers are algorithmically generated and have no confirmed association with a real person or active line. --- ## Web / SMS Metrics The three Web / SMS metrics below work as a funnel. Each one measures a different stage of the respondent journey. For example: of **10,000 records sent**, 9,000 were successfully delivered (90% Delivery Rate). Of those 9,000 delivered, 900 clicked the survey link (10% Click Rate). Of those 900 clicks, 90 completed the survey (10% Completion Rate). ### Delivery Rate **Formula:** `Delivered / Sent` Delivery Rate measures what percentage of records sent were successfully delivered to a respondent. Higher is better. This is the web/SMS equivalent of **Contact Rate** in phone fielding. A low delivery rate may indicate issues with message deliverability, spam filtering, or sample quality -- similar to how poor contact rates on the phone side signal dialing issues or an outdated list. ### Response Rate / Click Rate **Formula:** `Clicked / Delivered` Response Rate and Click Rate refer to the same measurement -- the terms are used interchangeably depending on context or client preference. Both apply equally to **email/panel** and **SMS-based** survey distribution. Higher is better. This metric is the web/SMS equivalent of **Cooperation Rate** in phone fielding. It answers the question: *"Of everyone who received the survey invitation, how many actually clicked through to begin it?"* ### Completion Rate **Formula:** `Completes / Sent` Completion Rate is the web/SMS equivalent of **Production Rate** in phone fielding. Rather than measuring completes per hour, it measures what percentage of all records sent ultimately resulted in a completed interview. Higher is better. This metric gives a top-level view of how efficiently a web or SMS deployment is converting the available sample into usable completes. ### Cost Per Complete **Formula:** `(Total Records Sent x Cost Per Record) / Completes` Cost Per Complete measures how much it costs, in SMS/email spend, to generate a single completed interview. Lower is better. This metric helps evaluate the overall efficiency and cost-effectiveness of a web or SMS deployment. Current vendor rates per record sent: - **BBD** -- $0.02 per record - **TTH** -- $0.03 per record For example, if 10,000 records are sent via BBD at $0.02 each, the total send cost is $200.00. If that deployment yields 90 completes, the Cost Per Complete is **$2.22**. # Manual - Checking Tables - Best Practices Before sending a data tables "book" to a client, it must be checked against the topline and the questionnaire to confirm accuracy. This process uses three documents in combination: - **The Questionnaire** — the final hardcopy survey, showing all questions, answer codes, skip logic, and flow. - **The Topline** — the raw frequency output from Survox, cross-tabbed across all banner points. - **The Tables Book** — the client deliverable, one table per question, with all banner points applied. These three documents must agree with one another. The checks below confirm they do. --- ## Step 1: Verify the Total N The first check is simple but critical — confirm that the tables book and the topline are both working from the same dataset. - In the **tables book**, locate the **Total** column on any table. The value in the top row (total respondents) is your N. - In the **topline**, find the **Total** column in TABLE 001. Confirm the N matches. If the two numbers do not match, one of the files is outdated. **The file with the lower N is typically the older version.** Do not proceed until both files reflect the same N. --- ## Step 2: Verify the Banner The banner — the set of cross-tab columns applied across all tables in the book — is defined once and applied globally. This means it only needs to be verified once, not for every question. To check the banner: - Find a question in the tables book that meets all of the following criteria: - Asked of **all respondents** (no skip, no filter, no split) - **Single-response** — multiple-response questions can inflate counts and make the math appear incorrect - Simple and straightforward — a basic demographic like gender works well - In the **Total row** of that table, go banner point by banner point across the columns. - For each banner point, locate the corresponding question in the **topline** and confirm the value matches. If all banner point values match the topline, the banner is correctly defined and does not need to be re-checked on any other table. If any value is off, something is miscounting in the banner specification and it must be resolved before the book can be delivered. --- ## Step 3: Check Each Table Against the Topline and Questionnaire With the N and banner both confirmed, work through the tables book question by question. For each table, you are checking two things: ### 3a. Total Column Matches the Topline For each answer code row in a table, the value in the **Total column** must match the corresponding value in the topline for that question. If it does not, the table is pulling data incorrectly. ### 3b. Base N Reflects Skip Logic and Splits Not every question is asked of every respondent. The questionnaire defines which respondents reach each question — through skips, filters, and routing logic. The table's base N must reflect this. To verify, find the driving question in the questionnaire — the one whose answer routes respondents into or past the question being checked. Locate that driving question in the topline and identify how many respondents gave the qualifying answer. That count should match the base N of the dependent table. **Example:** If the questionnaire says *"If Q2 = 3, continue to Q3; otherwise skip to Q4"*, and the topline shows 92 respondents answered *3* on Q2 — then the base N on the Q3 table should be 92. Split-assigned questions follow the same principle. A split is not driven by another question — it is a pre-assigned quota portion of the total N. A two-way split (A/B) is approximately 50%/50%. A three-way split (A/B/C) is approximately 33%/33%/33%, and so on. Some studies use multiple independent split sets, where a respondent may belong to one split from each set (e.g., they are in Split A of one set and Split D of another). In all cases, the base N for a split-assigned question should match the corresponding split count shown in the topline. If the base is wrong, either the skip logic or split assignment was programmed incorrectly in the tables. --- ## Things to Watch For ### Multiple-Response Questions Some questions allow respondents to select more than one answer. When checking these tables, the sum of all row values will often **exceed** the total N — and that is expected, not an error. This happens because the Total row counts **respondents**, while each answer code row counts **responses**. A single respondent who selected three answers contributes once to the total N but three times across the individual rows. As long as the sum of the row values is **equal to or greater than** the total N, the table is correct. The same logic applies to percentages — individual row percentages will not add up to 100% on a multiple-response question, and they are not supposed to. **Note:** The hardcopy questionnaire does not always clearly label whether a question is single or multiple response. When in doubt, check the original programming specifications or confirm with the programmer. ### Mean, Median, and Other Calculated Statistics Means, medians, and similar statistics are calculated automatically by the system. These do not need to be manually verified as part of the standard table check. ### Summary Tables Some tables book deliverables include summary tables — a single table that consolidates results from multiple related questions. A common example is a battery of yes/no brand awareness questions summarized into a single "yes" table, rather than delivering each question individually. When checking a summary table, each row should match the corresponding individual question's value in the topline. If the individual questions are also present in the tables book and have already been checked, those verified values can be used as the reference instead of going back to the topline. If the individual questions were not included in the client deliverable, the topline is the only reference — apply the same row-by-row total column check used for all other tables. ### Summary Banner Points Some banner points are themselves summaries — combining mentions of a specific code across multiple questions. For example, a "User of Brand X" banner point might count any respondent who mentioned Brand X in Q1, Q3, Q8, Q11, Q15, or Q26. Because a respondent only counts once regardless of how many of those questions they mentioned Brand X in, this behaves like a unique respondent count — not a response count. The total for a summary banner point will land somewhere between the highest single-question value and the sum of all contributing question values, depending on how much respondent overlap exists between questions. Manual verification of the exact number is not practical without knowing the overlap. However, the following rule always applies: **The summary banner point total cannot be lower than the highest value seen in any single contributing question.** **Example:** If Q3 had 40 respondents mention Brand X, and Q7 had 6 — the summary banner point must show at least 40. If 3 of those 6 in Q7 were also among the 40 in Q3, the correct total is 43 unique respondents. It cannot be 30, and it cannot exceed 46 (the raw sum). If the summary banner point value falls below the highest individual question value, it is wrong and must be corrected before delivery. ### Weighted Data Some studies use weighted data. This is typically requested by clients who want to collect data as cost-effectively as possible during fielding, but want the final deliverables to reflect the natural demographic composition of the surveyed area — usually based on census data for that region. Rather than controlling for age, gender, race, or other demographics during data collection, the DP team assigns a relative weight value to each case after fielding. When the final tables are run, Survox applies those weight values as multipliers across the data. Weighted tables are inherently difficult to check manually. Any time whole numbers are multiplied by percentage-based weight values, rounding comes into play at the individual case level — and those rounding differences accumulate across the dataset. A weight of 1.1 rounds down to 1, and a weight of 2.4 rounds down to 2, but their combined value of 3.5 rounds up to 4. Small discrepancies in weighted totals are expected and are not necessarily errors. For this reason, **unweighted tables should always be checked first.** Unweighted data is a true 1:1 ratio of responses to respondents, which makes discrepancies easier to identify and confirm. Once the unweighted tables are verified clean, weighted tables can be reviewed with the understanding that minor rounding variance is normal. ### Statistical Testing When requested by the client, statistical significance testing is applied to the tables. MAXimum Research uses All-Pairs testing at the 90% and 95% confidence levels, testing all columns against one another simultaneously. In the tables, columns are labeled alphabetically — the Total column is typically labeled **A**, and each subsequent banner point column is labeled **B**, **C**, **D**, and so on. Where a statistically significant difference exists between columns, the letter of the column being outperformed appears in the cell of the higher-performing column. Stat testing annotations are generated automatically by the system. There is no standard manual method to verify whether a specific letter flag is correct. When clients ask about stat testing, the annotations can be pointed to and explained at a high level, but no further interpretation or validation of individual flags is expected as part of the table checking process. --- ## Completing the Check Once all tables have been verified, notify the programmer by email that the check is complete and the book is clear for client delivery — or flag any discrepancies found for correction.