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:

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:

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:

[date#091222-091322]

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:

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.

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:

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.

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.

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:

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:

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:

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:

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:

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:

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:

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.

Good uses for a Project:

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:

What Claude cannot do:

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

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.