A weekly client check-in should ask only the questions whose answers actually change programming, and the fastest way to design it is to sort every question by how reliably a client can self-report the answer. Countable behaviors (sessions finished, nights of short sleep, days logged, steps, body weight) are trustworthy and belong front and center. Effort (RIR) and calorie totals are biased self-reports that need behavioral phrasing and calibration over time. Below are the exact questions, grouped by reliability, plus phrasing that beats the 'fine' answer.
Key takeaways
- Sort check-in questions by self-report reliability, not by topic, because your programming inherits whatever error is baked into the answer.
- Countable behaviors are reliable and belong front and center, while effort and nutrition totals are biased and need calibration before you lean on them.
- A client's 3 RIR is less trustworthy than their 1 RIR, and a new client needs roughly four to six sessions before their effort rating is usable.
- Calorie self-report is under-reported by almost everyone, so ask behavioral adherence questions (days logged, meals skipped, meals out), not "did you hit your macros."
- Ask for one number and one concrete event per question to kill the "fine" answer.
- When in-app prompts capture the training side every session, the manual check-in can focus on life, stress, schedule, and adherence.
Why Sort Every Check-In Question by How Reliably Clients Self-Report It?
The single most useful thing you can do to a weekly check-in is sort every question by how reliably the client can actually report the answer.
Because a confident wrong number is worse than no number at all.
Here's the problem with most templates: they list twenty questions and treat every answer as equally true.
But a client's "sessions completed" and a client's "average RIR" live in completely different worlds of trust, and your programming decisions inherit whatever error is baked into the answer.
The two buckets: countable behaviors vs calibrated judgments
Sort every check-in question into one of two buckets, and the whole process gets sharper.
Bucket one is countable behaviors. These are things the client can literally count or read off a screen: sessions completed, days logged, body weight, step count, nights under six hours of sleep, meals out this week.
These answers are high reliability because there is no interpretation involved, just counting, so you can take them close to face value.
Bucket two is calibrated judgments. These are RIR and effort, plus calorie and macro totals.
These answers are biased in predictable ways, which makes them useful only once you know the direction of the error and track the client over time.
The table below seeds the signals this post expands on, and later sections dig into the phrasing and the programming move for each.
| Signal | Self-report reliability | Better phrasing | What it changes in the plan |
|---|---|---|---|
| Sessions completed | High (countable) | How many of your 4 sessions did you finish fully? | Volume you can trust; progression math |
| Body weight / step count | High (countable) | Average daily weight and steps this week? | Energy balance read, NEAT trend |
| Nights under 6h sleep | High (countable) | Average hours, and how many nights under 6? | Hold loads or trim a set on bad weeks |
| RIR / effort | Biased, trainable | Last set of squats: how many more reps if I paid you $100 each? | Load progression, but only once calibrated |
| Calorie / macro totals | Biased (under-reported) | How many days did you log, and which meals get skipped? | Adherence target, not the number itself |
| Joint pain | Needs structure | Which joint, 0 to 10, during or after or next day? | Swap exercise, cut range, drop load |
Why a confident wrong number hurts your programming
A wrong number feels like data, so you act on it, and that is exactly what makes it dangerous.
If a new client reports a clean "3 RIR" every set and you keep adding load on top of a number that is actually off by two reps, you are programming on fiction.
No answer at least tells you to go dig.
A confident wrong answer tells you to proceed, straight into junk volume or a stall.
So trust the behaviors, and calibrate the judgments before you lean on them.
Count what can be counted, calibrate what can only be judged, and never treat a client's confident guess as if it were a measurement.
How Should You Ask About Training Effort and RIR?
Ask about effort behaviorally rather than requesting a bare RIR number, because RIR self-report is patterned and predictable in its errors.
A client typing "hit my RIR targets, all good" gives you almost nothing you can program on.
The number itself is not the problem.
The problem is that the error in that number moves in known directions, and a single digit hides all of it.
Why a 3 RIR is less trustworthy than a 1 RIR
RIR accuracy is not uniform across the set, and that changes how much weight you put on it.
A scoping review by Bastos and colleagues found that RIR prediction accuracy decreased when the estimate was provided farther from failure and when more repetitions were performed in a set.
In plain terms, a client's "3 RIR" is less trustworthy than that same client's "1 RIR."
Controlled work backs this up: reporting was more accurate at 1 RIR than at 3 RIR, and more accurate at 75% of 1RM than at 50%, with no consistent differences by sex or exercise type.
So when you ask about effort on lighter, higher-rep accessory work left further from failure, treat the answer as a rough signal, not gospel.
Anchor your real progression decisions to the heavy, close-to-failure sets where the self-report is tightest.
New clients: budget 4 to 6 sessions before you trust the number
Do not trust a new client's week-one RIR, because RIR is a trainable skill, not an innate one.
Experienced lifters can get close: trained lifters have reported RIR within about one rep near failure, with mean accuracy around -0.17 reps at 1 RIR and 0.65 reps at 3 RIR.
Novices are a different story.
In recreationally active people, velocity-based RIR estimates were not accurate for a majority of repetitions, which tells you a brand-new client's effort rating is mostly noise at first.
The good news is that calibration is fast.
Trainability research found RIR accuracy improves with a brief familiarization of roughly four to six sessions over multiple weeks, and there was no age-related difference in baseline accuracy or in how quickly people improved.
For older clients specifically, predicted RIR still lacked precision for prescribing load but remained useful for monitoring volume, and it tracked effort better than RPE did.
The coaching move: when you program a new client's first mesocycle, budget the first month as calibration, verify their reported RIR against what you see in the numbers, and only lean on it once it holds up.
If you want the deeper mechanics of the two scales, RIR vs RPE walks through when each one earns its keep.
To pull a specific answer instead of a shrug, anchor the question to money or behavior.
Try this phrasing: on the last set of your top squat, how many more reps could you have done if I paid you a hundred dollars each?
That reframes a vague scale into a concrete count, and clients answer it honestly because the stakes feel real.
Ask about the worst set, not the average, with a follow-up like which working set felt hardest this week and why.
That single question surfaces the session where something actually changed, which is usually the one your program needs to react to.
Do not collect a bare RIR digit and trust it, anchor the effort question to real behavior, lean on the close-to-failure sets, and give new clients four to six sessions to earn your trust in their number.
What Recovery Questions Actually Change the Plan?
Ask for sleep as a number, not a vibe, and treat a bad sleep week and high life stress as reasons to pull volume or intensity rather than as lifestyle small talk.
Recovery questions only earn their place in a check-in if the answer can actually move the next week's program.
"How's sleep?" cannot do that.
A count can.
Ask for a sleep number, not a vibe
Ask for average hours and the number of nights under six hours, because a vague "fine" buries the exact signal you need.
Sleep is a legitimate week-to-week programming input, not a wellness afterthought, and the research on how much sleep builds muscle backs that up.
Reviews of inadequate sleep and muscle strength tie poor sleep to blunted strength and resistance-training outcomes, which is reason enough to ask about it every week.
And it is acute, not just chronic: a study in resistance-trained participants found that even acute partial and total sleep deprivation affected strength, power, and endurance.
That means a single bad week matters, and it means the question has to be sensitive enough to catch one.
Two numbers do that: average hours slept, and nights under six hours.
If a client averaged five hours and logged four nights under six, you do not need them to describe how tired they feel, you already have your answer.
Reading a high-stress week as a programming input
Treat a high-stress week as a programming variable, and ask what specifically changed rather than how the client is "coping."
Stress shows up in the gym whether or not the client connects the dots for you.
So ask the concrete version: what changed this week, a work deadline, travel, a sick kid, a move?
You can borrow the logic of an instrument like the Perceived Stress Scale to standardize this, but you do not need the full questionnaire, just a consistent prompt that names real events.
Now put the two together.
A short-sleep, high-stress week is a reason to hold loads or trim a set, not to push a planned progression into a client who is running on fumes.
Here is the exact recovery set to drop into your check-in:
- Average hours of sleep per night this week?
- How many nights under six hours?
- What was the most stressful thing going on this week (deadline, travel, illness, none)?
- Did that stress change your training, your appetite, or your sleep?
Four questions, all answerable with a number or a short fact, each one capable of changing what you program next.
When the answers point at a genuinely fried client, a planned deload week is often the honest call rather than a forced jump.
Make recovery answerable in numbers and named events, then read a short-sleep, high-stress week as a reason to hold the line instead of forcing the planned jump.
How to Turn 'My Shoulder Hurts' Into a Programming Signal
Make joint pain a severity plus location plus timing question, so it stops being a worry and becomes an exercise decision.
"My shoulder hurts" with no detail is a trap.
It forces you into one of two bad moves: overreact and pull everything, or shrug and ignore it until it gets worse.
Neither is coaching.
So ask for four specifics every time a client flags pain, and each one maps to a different change in the plan.
Here are the four parts to collect:
- Severity on a 0 to 10 scale, where 0 is nothing and 10 is stop immediately.
- Location, which joint and which side, not "my arm."
- Timing, whether it shows up during the set, after the session, or the next day.
- Trigger, which specific movement brings it on (overhead press, bench, dip).
Those four turn a vague complaint into something you can act on without guessing.
A 2 out of 10 that fades after warmups is a keep-going signal.
A sharp 7 during the exact bottom of a bench press is a swap-the-exercise signal.
The table below maps the common answers to a programming response.
| Pain answer | Programming response |
|---|---|
| 1 to 3, warms up and fades | Keep going, monitor next week |
| 3 to 5, only at end range | Cut range of motion on that lift |
| 4 to 6, load-dependent | Drop load, build back up slowly |
| 6+, sharp, tied to one movement | Swap the exercise for a pain-free variation |
| Pain next day, not during | Reduce volume on the triggering movement |
Notice how different a "cut range" answer is from a "swap it out" answer.
You only get to that fork if the client gives you severity, location, and timing in the first place.
Without those details, every pain flag costs you a back-and-forth message thread just to find out whether it is a tweak or a real problem.
Build the four-part prompt into the check-in and the answer arrives already structured.
Ask for severity, location, timing, and trigger every time, because a structured pain report tells you whether to swap, shorten, lighten, or carry on, while "my shoulder hurts" only tells you to panic or ignore it.
What to Ask About Nutrition and Adherence Instead of 'Did You Hit Your Macros?'
Stop asking "did you hit your macros," because it invites a useless yes, and ask behavioral questions whose answers clients report reliably.
The yes you get back feels like adherence data.
It is not.
It is a judgment call filtered through a memory that is biased in a known direction, and you cannot program off it.
Why calorie totals are a biased answer for almost everyone
Self-reported calorie intake is systematically under-reported, which makes a client's "yes, I hit my targets" an unreliable foundation for any decision.
The classic New England Journal of Medicine work on self-reported versus actual caloric intake in obese subjects documented a large gap between what people said they ate and what they actually ate, with reported intake landing well below real intake.
Here is the fairness part that keeps this from turning preachy.
Under-reporting is not an "obese client" failing.
When the data are scaled for body size, heavier individuals do not appear to under-report any more than leaner ones, which means this is a general human phenomenon, not a character flaw in one body type.
So when a client's totals do not match the scale trend, assume the math is off, not that they lied.
That framing matters, because your check-in question should make it safe to report behavior honestly rather than defend a number.
Behavioral questions clients report reliably
Ask about behaviors the client can count, because those answers survive the under-reporting bias that wrecks calorie totals.
These are the questions worth asking every week:
- How many days did you log your food?
- Which meals get skipped or logged late?
- Was the weekend different from the weekdays?
- How many meals did you eat out this week?
- What was your average daily step count?
Compare the vague version to the specific one and the difference is obvious.
| Vague question | Specific rewrite |
|---|---|
| Did you hit your macros? | How many of 7 days did you log fully? |
| Eating clean? | Which meals do you usually skip logging? |
| Nutrition going well? | Weekend eating vs weekday, same or different? |
| Staying active? | Average daily steps this week? |
These behavioral answers do more than read cleaner.
They point at different fixes.
A client who logs perfectly Monday through Friday and goes dark on the weekend has a weekend problem, and the fix is a Saturday plan, not a lower calorie target.
A client who logs late and under-counts every single day has a daily consistency problem, and the fix is a logging habit, not a diet change.
You cannot tell those two apart from "did you hit your macros," because both clients will say some version of "mostly."
The behavioral questions separate them in one line each.
If you want the numbers behind the targets you are chasing, the complete guide to nutrition for muscle growth lays out the intake side.
Ask how many days they logged, which meals slip, and whether weekends differ, because calorie totals are under-reported by almost everyone, while countable behaviors tell you exactly which fix the week needs.
How Do You Phrase Questions So Clients Give Specifics, Not 'Fine'?
Swap yes/no and scale-only questions for counts and single concrete events, because stacked or vague questions reliably produce one-word answers.
"Training going ok?" gets you "yeah, good."
"How many of your four sessions did you finish fully?" gets you a number you can program on.
Same client, same week, completely different data, and the only variable was how you asked.
The phrasing rules below all come from the same place: countable behaviors are reported reliably, and judgments are biased, so you build the question to pull a behavior out.
One number, one event per question
Ask for one number and one concrete event per question, because a stacked question gets collapsed into a single lazy answer.
When you ask "how was training, recovery, and nutrition this week," the client picks the easiest word that covers all three, and "fine" covers everything.
Split it.
Replace "training going ok?" with "how many of your four sessions did you finish fully?"
Anchor effort to behavior or money instead of a bare scale: "on your top set of squats, how many more reps if I paid you a hundred dollars each?"
Make nutrition behavioral, not a totals check: "how many days did you log?"
Each of those asks for one thing, and one thing is what you get back.
Ask about the worst data point, not the average
Ask about the worst data point rather than the average, because the average hides the exact week your program needs to react to.
"How did training feel overall" blends a brutal session into four fine ones and you never hear about the brutal one.
Ask instead: "which session felt hardest this week, and why?"
That question surfaces the single workout where something changed, which is usually the one carrying the signal.
Now put the rewrite rules into one table you can steal.
| Vague question | What you actually get | Specific rewrite | What it reveals |
|---|---|---|---|
| How's sleep? | "Fine" | Average hours, and nights under 6? | Whether to hold loads this week |
| How was effort? | "Hard" | Last set, how many more reps for $100 each? | Calibrated RIR you can trust |
| Nutrition going ok? | "Pretty good" | How many of 7 days did you log fully? | Real adherence, not a guess |
| Training going well? | "Yeah" | How many of 4 sessions did you finish? | Volume you can program on |
| Sore anywhere? | "A bit" | Which joint, 0 to 10, during or after? | Swap, shorten, or carry on |
The pattern across every row is the same.
Vague question in, vague answer out.
Specific question in, specific answer out.
You are not making the client work harder, you are making the question do the work, so the easiest honest reply is already the one you can use.
Write the check-in so that "fine" is not a valid answer to any question in it.
Ask for one number and one event per question, anchor effort to real stakes, and probe the worst session instead of the average, because specificity in is the only thing that gets you specificity out.
What the App Captures Automatically, and What Your Check-In Should Ask Instead
When in-app feedback prompts capture the training side every session, your manual weekly check-in should stop re-collecting training data and spend its attention on what the app cannot see.
That is the real payoff of sorting questions by reliability.
The countable training behaviors do not need to live in your check-in message at all, because they are already being counted somewhere more reliable than a client's Sunday-night memory.
Training signals the app already collects every session
In a platform like Mesostrength, clients answer the same per-set feedback prompts every session: sets completed, RIR on each set, joint pain flags, and soreness.
The engine already adjusts sets, weights, and deloads from those answers between sessions.
So you are not sitting there re-asking "did you hit your RIR targets this week?"
The number was logged at the moment it mattered, set by set, not reconstructed days later when the error gets worse.
That changes your job.
Instead of re-collecting the training side, you review exceptions on the roster: the client whose RIR drifted, the one who flagged shoulder pain, the one who missed two sessions.
You spend your attention on the handful that need it, not on transcribing a week of effort ratings out of a chat thread.
Life, stress and adherence: what only you can ask
What the app cannot see is everything outside the session: the work deadline, the three nights of bad sleep, the weekend the logging fell apart, the motivation quietly draining out of a client who still shows up.
Those are the signals your manual check-in should own.
Because nobody is prompting the client mid-week to tell you their appetite tanked after a stressful Tuesday.
That only comes out if you ask.
Here is the split, laid out plainly.
| Captured automatically (every session) | Ask manually (weekly) |
|---|---|
| Sets completed per exercise | Life stress and what specifically changed |
| RIR per set | Sleep hours and nights under six |
| Joint pain flags and soreness | Schedule disruptions (travel, work, illness) |
| Session adherence and progression | Days logged and which meals slip |
| Load and volume adjustments | Weekend vs weekday eating pattern |
| Deload timing | Motivation and how the mesocycle feels |
Read the table left to right and the division is clean.
The left column is training data, counted in the moment, acted on by the engine.
The right column is life and behavior, invisible to any app, countable only when you ask the right question.
So let the automatic prompts carry the training side, and point your limited check-in attention at the things only a human coach can surface.
Let the per-set prompts count the training signals the app sees every session, and spend your manual check-in on the life, stress, and adherence behaviors no app can capture.
Putting It Together: A Weekly Check-In Question Set
A check-in that changes the plan is short, sorts its questions by reliability, and leans on behaviors you can count rather than judgments you have to trust blind.
Below is a ready-to-use question set you can lift straight into your process.
Every question is written in the phrasing from the earlier sections: one number, one event, behavior over vibe.
The core questions, in order
Training and effort
- How many of your scheduled sessions did you finish fully this week?
- Which working set felt hardest, and why?
- On your top set of the main lift, how many more reps could you have done if I paid you a hundred dollars each?
Recovery
- Average hours of sleep per night this week?
- How many nights under six hours?
- What was the most stressful thing going on (deadline, travel, illness, none)?
Joint pain
- Any joint pain this week? If yes: which joint, 0 to 10, and does it show up during, after, or the next day?
- Which specific movement brings it on?
Nutrition and adherence
- How many of seven days did you log your food fully?
- Which meals get skipped or logged late?
- Was the weekend different from the weekdays?
Life and motivation
- What got in the way this week, if anything?
- How are you feeling about the current mesocycle, honestly?
Thirteen questions, each answerable with a number or a short fact, each one capable of changing what you program next.
Keep the cadence weekly and keep the form skimmable, because a wall of text gets a wall of "fine" back, while a tight numbered set gets tight numbered answers.
Trim questions that never change the plan
Drop a question the moment you realize its answer never moves a decision.
If your platform captures the training side automatically, cut questions 1 through 3 and question 7 from the manual list entirely, because sets completed, RIR, and joint pain flags are already logged set by set and the engine is already acting on them.
That leaves you a leaner life-and-adherence check-in, which is exactly where your attention is worth the most.
For everyone else, the test is simple: when did this question last change what you programmed?
If a question has gone three mesocycles without ever flipping a decision, it is small talk, not a check-in item, and it is costing you a client's patience for the questions that matter.
Treat the whole process as iterative.
Track whether this week's answers predicted the right programming move: did the short-sleep flag actually warrant holding loads, did the weekend logging gap actually explain the stalled scale?
Over a few months you will learn which questions earn their place and which ones you can prune, and the set gets shorter and sharper every pass.
Build the shortest set that still catches every signal, cut any question whose answer has never changed the plan, and keep tracking whether your questions actually predicted the right move.