# A scope change tracker that fills itself from your client meetings > For freelancers and consultants on fixed-scope work who hear new requests on Google Meet and Microsoft Teams calls: how the Change requests template in TrackHeros turns each request into a row with who asked, when it was first asked, whether it was in scope, the effort and cost quoted and the decision, why the request date keeps its first value, and what is still yours to do. Canonical: https://trackheros.com/blog/scope-change-tracker/ Author: Sami Kanafani Updated: 2026-11-04 **In short:** TrackHeros keeps a scope change tracker from your Google Meet and Microsoft Teams calls with its Change requests template: one row per request, with who asked, the date first requested, whether it was in the original scope, the effort and cost quoted, and the decision. The request date keeps its first value, so a request raised again later cannot quietly look new. | Fact | Detail | | --- | --- | | Template | Change requests | | Columns | Request, requested by, date requested, in original scope, estimated effort, cost impact, decision, decision date | | Date requested | Keeps the first value; a later, different date is a conflict for you to decide | | Decision options | Pending, Approved, Rejected, Deferred; Approved and Rejected are final | A scope change tracker is a running table of everything a client has asked for beyond the agreed work: what, who asked, when, what it would cost, and what was decided. This guide is for freelancers and consultants on fixed-scope or fixed-price work who hear those requests on Google Meet or Microsoft Teams calls, and want the table kept for them. The phrases that signal new scope, what to say on the call and the change request email to send are in [scope creep starts in meetings](/blog/scope-creep-starts-in-meetings/); this guide is about the log behind them. ## What is a scope change tracker? A list of change requests, one row each, that stays current from the first time a request is raised until it is approved, rejected or deferred. It is where "you said that was included" gets checked, months after the call where it was said. It is easy to start and hard to keep. Requests arrive in passing, in the last minutes of a good call, and writing them down competes with the next meeting. ## What columns does the Change requests template have? Eight, each with a type and a one-line description of what belongs in it. The template is one of six that TrackHeros offers when you start a tracker. TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. A tracker is a table that fills itself from those meetings. | Column | Type | What goes in it | | ----------------- | -------------------------- | -------------------------------------------------------------------------------- | | Request | Text, names the row | A change, addition or new feature the client asks for; not bugs in agreed work | | Requested by | Person | Who asked for it | | Date requested | Date, keep the first value | The date of the meeting where it was first asked for | | In original scope | Yes / no / unclear | Whether it is said to be part of the agreed work; unclear unless someone says so | | Estimated effort | Text | The estimate as said: "two days", "a sprint" | | Cost impact | Money | Extra cost quoted, with its currency | | Decision | Status | Pending, Approved, Rejected or Deferred; Approved and Rejected are final | | Decision date | Date | When it was decided, if stated | The exclusion in the first row does real work. A bug in something already agreed is a fix you owe, not a change the client is asking for, and keeping it out of the table keeps the table honest. ## Why does the date requested keep its first value? Because the date that matters is the first time a request was made, and requests are raised again. When the client says "as we discussed" three weeks later, the row should still say when it was first discussed. Every other column uses the default rule, where the newest meeting's value wins and earlier values stay in the history. Date requested is set to keep the first value instead. A later, different value is not applied; it is shown as a conflict, and you choose to keep the first value or use the new one. A value that contradicts a keep-the-first-value column always waits for a person, even when a tracker is set to apply confident changes on its own. [What happens when two meetings disagree](/answers/what-happens-when-two-meetings-disagree/) covers the other cases. ## How does a request raised twice stay one row? Rows are named by the Request column. When a later meeting mentions the same request, its row is updated rather than duplicated, so the decision made in the third call lands on the row created in the first. When a new request looks like an existing one, "the accountant email" against "Email the export to the accountant", it is flagged as a possible match: the same row, or a new one. Rows are never merged automatically, because two similar requests are sometimes two requests. Answering same as keeps the new row's history under the existing request. ## What does a request's history show when the client disputes it? Every value the row has held, with the meeting it came from, who said it, when in the meeting, and the words they used. A link opens the transcript at that moment, and the recording jumps there. Here is one request from a fintech client, across four weekly calls: | Meeting | Column changed | Value | Words used | | -------------------------- | ----------------------------- | --------------------------- | ------------------------------------------------------------------------- | | Wednesday 4 February 2026 | Request, requested by, date | New row, Priya, 4 February | Priya: "Could the export also email the file to our accountant?" | | Wednesday 4 February 2026 | In original scope | No | You: "That's outside what we scoped, so I'll send you an estimate today." | | Wednesday 11 February 2026 | Estimated effort, cost impact | About three days, 1,800 EUR | You: "It's about three days, so 1,800 euros on top of the current work." | | Wednesday 18 February 2026 | Decision, decision date | Approved, 18 February | Priya: "Go ahead with the accountant email. We'll take the three days." | | Wednesday 25 February 2026 | In original scope | Yes, waiting for review | Tom: "I thought the accountant email was always part of the export." | The last line is the dispute, and it arrives as a proposed change, not a fact. By default every new or changed value waits in a review queue, so Tom's sentence sits there until you reject it, and the row keeps "No" with Priya's approval of the extra cost beside it. The quotes are rebuilt from the stored transcript, never written by the model, and a value with no transcript line behind it is dropped. ## Which meetings should feed the tracker? Every meeting of the client, which is the template's default. Requests come up in demos, standups and status calls alike, and meetings plainly unrelated to the tracker's subject are skipped. If requests cluster in one meeting, such as the fortnightly [sprint review](/blog/sprint-review-with-a-client/), you can scope the tracker to that recurring meeting instead, or attach it to a single upcoming meeting before it happens. Any finished meeting can also be sent to it by hand. When you create the tracker, you can have it read your recent past meetings in scope, oldest first, so requests made before today are already in the table, each with its first date. A review held partly in Arabic and partly in English is read after its audio pass, through the same transcript as the notes. Trackers read meetings in any of the close to 100 spoken languages TrackHeros recognises; text values are written in the notes' language, and the [languages page](/languages/) lists both. ## What does the tracker leave to you? The judgement and the paperwork. It records what was said; it does not decide that something is scope creep, and it does not send anything to anyone. - **The change request itself:** write and send it the same day, with the row's quotes and links as the reference. The email template is in [scope creep starts in meetings](/blog/scope-creep-starts-in-meetings/). - **Requests made by email or chat:** trackers read meetings only, so add those as rows yourself. - **Live capture:** the table fills after each meeting's notes are ready, not during the call. Read the new requests back before the call ends, as you would anyway. - **Sharing the log:** the table and its full history download as CSV, which opens in Excel or Google Sheets; [pricing](/pricing/) says which plans include export. Each tracker belongs to one client's sealed workspace, so one client's requests never appear in another's log. Promises flow the other way too: [track what the client promised](/blog/track-what-the-client-promised/) keeps the access, files and sign-offs you are waiting for. The [Trackers feature](/features/trackers/) covers the rest. ## Frequently asked **Does TrackHeros decide whether a request is in scope?** No. The In original scope column is yes, no or unclear, and its description says to leave it unclear unless someone in the meeting says so. Whether something was in the contract is for you and the client to settle; the table records what each of you said. **Does it send the change request to the client?** No. Nothing is sent from a tracker. Write the change request yourself, using the row's quotes and the link to the moment in the meeting, and send it the same day. **What if a request was made by email?** Trackers read recorded meetings only. Add the request as a row yourself; when a later meeting discusses it, that row is updated like any other. --- TrackHeros is in early access: https://trackheros.com/#early-access