Why CEFR for grammar tracking

Quick refresher in case you need it: the Common European Framework of Reference for Languages splits English proficiency into six levels — A1 through C2 — with clear "can-do" descriptors for each.

For grammar specifically, each level maps to specific structures:

• A1: present simple, basic articles, possessives, plurals, "to be"

• A2: past simple, present continuous, present perfect (basic), comparatives, going-to future

• B1: present perfect with for/since/ever/never, first and second conditionals, reported speech, modals for advice

• B2: passive voice, mixed conditionals, advanced relative clauses, perfect aspect across tenses

• C1: inversion, cleft sentences, advanced modals (could have, might have), participle clauses

• C2: subjunctive in formal contexts, ellipsis, nuanced cleft variations, register shifts

When you tag your tracker entries against these levels instead of vague labels like "intermediate," the downstream stuff gets easier — placement, lesson planning, progress conversations.

The four-database structure I use

Most Notion teacher templates I've seen go wrong by trying to cram everything into one giant table. Splitting it across four databases keeps each one simple.

Database 1: Students

The hub. One row per student. Properties:

• Name (title)

• Current CEFR level (select: A1, A2, B1, B2, C1, C2)

• Target CEFR level (select)

• Start date

• Class / group (relation to Classes database)

• Notes (text)

The "current level" property is what makes everything else work. Keep it honest — don't bump a student up because they've put in time. Bump them up when their assessed grammar score actually crosses the threshold.

Database 2: Grammar topics

This is the spine. One row per grammar structure, tagged by level. You'd populate it once and rarely touch it again. Properties:

• Topic name (e.g. "Present perfect with for/since")

• CEFR level

• Category (tense, modal, structure, etc.)

• Prerequisites (relation to itself — links to topics a student should know first)

Pre-loading this with around 80 to 120 entries covering A1 through C1 is a one-evening job. Once it's done, you have a complete grammar curriculum mapped out by level.

Database 3: Assessments

One row per assessment given. This is where the actual data lives. Properties:

• Student (relation to Students)

• Date

• Topic (relation to Grammar topics)

• Score (number, 0-100)

• Notes / observations

• Source (in-class quiz, homework, diagnostic test, etc.)

Add a formula property called "Mastery" that returns "Mastered" if score ≥ 85, "Developing" if 60-84, "Struggling" if below 60. This auto-categorizes everything as you enter it.

Database 4: Sessions / lessons

Optional but useful. One row per lesson, with a relation to which grammar topics you covered. Lets you see at a glance whether you've actually taught a particular structure to a particular student, or just assumed they got it elsewhere.

Setting each student's starting level

This is where most trackers fall apart. Teachers either guess the level after a 10-minute conversation or rely on whatever level the student says they are, which is almost always too high or too low.

You need an actual diagnostic. The fastest way I've found is to use a free online CEFR grammar test as the day-one assessment, then transfer the result into the Students database. The one I usually point students to is at https://esl-tests.com/english-level-test/grammar — it's free, no signup, and gives a CEFR level at the end. Whatever tool you use, the point is consistency: if you're trusting your ear across 30 students, you'll have wildly different starting points for students who are actually at the same level, and "progress" then becomes impossible to measure.

Once a starting CEFR level is locked in, every assessment after that becomes a meaningful data point.

The workflow in practice

Here's what a normal week looks like:

Monday — lesson planning. Open the Students database. Filter by your Monday class. Look at each student's recent assessments — the "Struggling" tags from the last two weeks are your priority topics. Build the lesson around fixing those before introducing anything new.

During lessons. When a grammar point comes up, do a quick three-question check at the end. Score it informally and log an Assessment entry that evening.

Friday — review. Group view by Student in the Assessments database, last 7 days. Patterns show up immediately — Maria nailed conditionals this week, ready for mixed conditionals; everyone is struggling with present perfect, need to slow down.

Monthly — level review. For each student, look at the percentage of their level's grammar topics where they've scored "Mastered." If they've mastered 80% or more of their current CEFR level's topics, run a full diagnostic again. If their level has actually moved up, update the Students database. This is the only way the "current level" field stays accurate over time.

Adapting it to your situation

The structure above works for most teachers, but it scales differently depending on your setup:

Solo tutor with 5-15 students — You can run the whole thing in a single workspace. Every student gets a dashboard page that surfaces their recent assessments and current focus topics. Setup time, including pre-populating the grammar topics database, is about an evening.

Language school teacher with multiple classes — Add a Classes database and a relation between Students and Classes. Build views filtered by class so you can pull up "Tuesday B1 group" instantly. The Sessions database becomes more useful here because you're teaching the same content multiple times.

Co-teaching team — Make the Students database collaborative and add an "Assigned teacher" property. The big benefit: if a student moves between teachers, the new teacher inherits a complete grammar history instead of starting from zero.

Mistakes I made early on

Tracking every micro-skill. I tried tagging individual assessments with five sub-skills per topic at one point. Nobody filled in five fields per quiz. Keep it to one topic per assessment, one score, one note. The detail you want comes from doing assessments often, not from going deep on each one.

Letting "current level" drift up without evidence. It's tempting to mark a student B1 because they've been in a B1 class for three months. Resist this. The whole point of the system is that the level reflects measured grammar performance. If they're not testing at B1 yet, they're not B1.

Skipping the prerequisites field. When a B1 student is suddenly struggling with second conditionals, the prerequisites relation lets you check whether they ever mastered first conditionals at A2. Often the answer is "no, they were marked Developing and we moved on." That's the gap to close.

Using one shared view for everything. I started with a single big "all assessments" view and tried to filter on the fly. Build dedicated views — by class, by recent struggles, by student — and switch between them. Filtering live during a class is too slow.

A note on setup time

This isn't a 30-minute project. Setting up the four databases, pre-populating grammar topics for the levels you teach, and building the views you want will take an evening, maybe two. After that, the maintenance is light — five to ten minutes per student per week to log assessments, plus the monthly level review.

If you want to try it without committing to a full build, start with one student. Get the four databases set up, run one diagnostic to establish their level, log a week of assessments, and see how the views feel before you scale up. The structure either fits how you teach or it doesn't, and that's easier to figure out with one student than with forty.