How we teach

Practise
what you learn.

A sales follow-up role play and two short sequences to revisit Notion and Make between sessions.

Clear materials and time commitments.

The between-session tasks are optional and their materials are included. A brief review is agreed within the programme’s live hours. The sales role play is also part of the 8-hour reference course.

The cases use fictional data. Before each delivery, the trainer reviews the environment, timing and participation alternatives with the group.

Optional · between sessions

Notion
Between Notion sessions

Three short P001 variations: find the reference, recover outstanding work and leave a handover with access still to check.

See the programme
Between sessions 1–2 · 10–15 min

Choose the reference and organise a note

Before opening the tool

Without looking at the answer, write what distinguishes a shared brief from a copy in a message.

Try it out

  • Read D001 and the received note in inputs/N1-note.md. Choose the reference for reviewing the copy and explain why.
  • Rewrite the note under Done, Outstanding and Review question. Link or cite D001 once; retain the uncertainty about scope and audience.

What to check

  • Does the note keep the shared reference without creating another brief?
  • Does it distinguish a prepared draft from outstanding work?

A question to finish with

Which information did you retrieve from the source rather than assume?

Check my result
  • D001 is the reference for P001. A copied message does not replace its objective.
  • Done: a draft exists. Outstanding: define scope and audience. Question: check both against D001.
  • No offer is invented and the review is not marked complete.

Mistakes to look out for

  • Copying the message as a new brief without checking D001.
  • Confusing “draft prepared” with “copy approved”.

If you cannot use the tool

Use the included D001.md and N1-note.md. Write on paper or in Markdown and cite the reference ID; do not claim that a Notion link was tested.

Between sessions 2–3 · 10–15 min

Find the task without mixing projects

Before opening the tool

Recall the difference between a task title, its properties and its page content.

Try it out

  • Open inputs/N2-tasks.csv. In the case copy, decide how to change T001 to hand its review to Marina; retain ID and Project_ID.
  • Select P001 tasks whose status is not Closed. Record the IDs that should remain visible before comparing the answer.
  • If using the agreed Notion copy, update the existing record and find it through the practice view; do not import the variation CSV into an operational database.

What to check

  • Does T001 retain ID T001 and Project_ID P001, with Marina and Awaiting review?
  • Does the filter exclude closed task T002 and the other project’s T006?

A question to finish with

What error did combining a project filter with a status filter reveal?

Check my result
  • T001 has a specific copy review title, owner Marina and status Awaiting review.
  • Only T001 remains in the selection. T002 is Closed; T006 belongs to P002.
  • The existing record is updated; another T001 is not created.

Mistakes to look out for

  • Filtering only by status and including P002’s T006.
  • Duplicating the task to change its title.
  • Closing T001 while Marina still needs to review it.

If you cannot use the tool

Open the CSV in a spreadsheet or read N2-data.md. Write the changes and filtered IDs on paper. This does not test a Notion view or permissions.

Between sessions 3–4 · 10–15 min

Repair a handover with missing access

Before opening the tool

Recall what belongs in a review request and why a mention does not grant access.

Try it out

  • Read inputs/N3-handover.md: the message says “Done, Marina to review”, but review is outstanding and Marina cannot open D001.
  • Rewrite the update with completed work, outstanding work and a specific question. Adjust the proposed status and record the access blocker without marking it resolved.
  • If another person is available in the classroom copy, ask them to explain the next step and check the agreed links. Otherwise, record this check as pending.

What to check

  • Does the message ask for service scope and audience to be checked against D001?
  • Does it retain Awaiting review and separate pending access from a completed review?

A question to finish with

What would another person need to continue without asking for the context again?

Check my result
  • The update retains brief D001 and notes D002, identifies the prepared draft and asks for scope/audience review.
  • The proposed status stays Awaiting review. D001 access is recorded as blocked or unchecked, not granted by a mention.
  • A check with another person is recorded only if it actually happened.

Mistakes to look out for

  • Using a mention as permission evidence.
  • Marking Closed when writing the message.
  • Copying “access checked” without testing.

If you cannot use the tool

Use the included story to draft the handover and access request on paper/Markdown. Mark “written simulation; access not checked”. This is not equivalent to checking the handover in Notion.

Three optional 10–15 minute tasks between the four sessions of the eight-hour reference edition. Materials are included and a brief recap is agreed within those eight hours. They are not attendance requirements or an additional diploma condition. They do not add individual review outside sessions; existing support retains its limits.

If something blocks you

  • If you cannot open the workspace, use a feature or confirm an authorised environment, stop execution; do not share passwords or change operational permissions.
  • Use the paper/Markdown data and record “not executed in the tool”; this alternative supports reasoning but does not establish access or practice in the application.
  • Keep one question and the blocker for the next session’s brief recap. Do not repeat actions on real contacts or treat access as resolved.
Optional · between sessions

Make
Between Make sessions

Three Tally → HubSpot variations: trace a field, check an empty entry and review an update by email.

See the programme
Between sessions 1–2 · 10–15 min

Trace fields before executing

Before opening the tool

Without opening the answer, draw the Tally source and HubSpot contact and recall which value identifies the enquiry.

Try it out

  • Read inputs/M1-mapping.csv and the fictional enquiry. Two logical destinations are swapped: identify them and prepare the correct mapping on paper.
  • If you already have an authorised classroom copy, compare the labels with the agreed contact properties. Do not create properties, connections or real contacts for this task.
  • Record one form field, its value and where it should appear on the contact. Do not claim it reached the CRM if you only reviewed mapping.

What to check

  • Does Name go to the agreed contact name and Company to the agreed company, without swapping them?
  • Can the email be traced to the enquiry? Normalisation is practised after session 2.

A question to finish with

How does a correct mapping on paper differ from an observed result in HubSpot?

Check my result
  • Name → contact name; Email → email; Company → agreed company property. These are logical labels, not universal internal property names.
  • Lucía Cano and Ladera Demo are not swapped. The enquiry can be identified by its ID and received email.
  • If the scenario has not run, the HubSpot result remains unchecked.

Mistakes to look out for

  • Confusing the company name with the contact name.
  • Assuming a contact exists after reviewing the diagram.
  • Configuring new connections outside the agreed copy.

If you cannot use the tool

The CSV and M1-data.md include all values. Draw the mapping on paper or in Markdown and mark “not executed in Make/HubSpot”. This does not establish a connection or access.

Between sessions 2–3 · 10–15 min

Test an email containing only spaces

Before opening the tool

Recall the order: prepare the email before checking that it contains a value.

Try it out

  • Read the three fictional entries in inputs/M2-requests.csv. For each, write the email after trimming leading/trailing spaces and converting to lowercase.
  • Decide which entries would pass Email present and which would stop before the CRM, then compare with the answer.
  • Only if the test environment is already authorised, run the agreed entries in the classroom copy and record observations. Do not send messages or activate operational scenarios.

What to check

  • Does the spaces-only entry become empty after preparation and stop?
  • Do you distinguish “passes the presence condition” from a valid/deliverable email or permission to send communications?

A question to finish with

What error would checking presence before trimming spaces cause?

Check my result
  • R201: lucia@example.com; passes presence. R202: empty; stops. R203: empty after trimming; stops.
  • A presence filter does not establish deliverability or consent.
  • A stopped entry is not automatically queued: a new test is agreed as a new classroom response.

Mistakes to look out for

  • Passing spaces as an email value.
  • Confusing a filter with an error handler.
  • Assuming a filtered entry retries automatically.

If you cannot use the tool

Use the CSV or M2-data.md and calculate values/decisions on paper. Record “prediction; not executed”; this is not equivalent to reading real scenario history.

Between sessions 3–4 · 10–15 min

Check what changed on the existing contact

Before opening the tool

Recall why repeating the same prepared email must be compared with the existing classroom contact.

Try it out

  • Read inputs/M3-existing-contact.csv, M3-request.csv and M3-fictional-trace.csv. The fictional trace retains the ID but the company contains a person’s name.
  • Compare expected and fictionally observed values. Identify the incorrectly mapped field and write the correction without changing the email key.
  • Describe a controlled repeat with a new practice response and the same email: which ID, email and company you would check. Run it only in an authorised copy, without contacting real people.

What to check

  • Does example contact H001 remain for lucia@example.com, with expected company Ladera Pruebas?
  • Is the issue the company mapping, rather than evidence that the CRM should create a different contact?

A question to finish with

What evidence would distinguish updating the contact from creating a new one?

Check my result
  • R301 uses prepared email lucia@example.com, already represented by H001. This case expects that contact to be updated.
  • Company must take Ladera Pruebas from the Company field; Lucía Cano in that property reveals incorrect mapping.
  • The proposed check compares existing ID, email and company after a new controlled response. H001 and the trace are fictional, not real results or a global deduplication guarantee.

Mistakes to look out for

  • Changing the email to hide the error and creating another contact.
  • Assuming the whole record is correct because its ID stayed the same.
  • Repeating actions on real data or treating the fictional trace as account history.

If you cannot use the tool

All states are in CSV and M3-data.md. Complete a comparison table on paper/Markdown and mark “fictional trace; not executed”. This does not demonstrate a real update.

Three optional 10–15 minute tasks between the four sessions of the eight-hour reference edition. Materials are included and a brief recap is agreed within those eight hours. They are not attendance requirements or an additional diploma condition. They do not add individual review outside sessions; existing support retains its limits.

If something blocks you

  • If you cannot open the workspace, use a feature or confirm an authorised environment, stop execution; do not share passwords or change operational permissions.
  • Use the paper/Markdown data and record “not executed in the tool”; this alternative supports reasoning but does not establish access or practice in the application.
  • Keep one question and the blocker for the next session’s brief recap. Do not repeat actions on real contacts or treat access as resolved.
During the session · 25–30 min

Follow up a proposal without inventing a yes

Rehearse Ladera’s follow-up, check commitments and leave a verifiable next action. Part of session 3 practice, without extending the programme’s 8 hours.

See the programme

The shared case

Fictional classroom case. Ladera is exploring an internal request portal. Elena will prepare two scope options by the case’s Thursday; IT consultation, budget and approval remain outstanding. No start is agreed.

How to practise

  • Two or three people: seller, client and observer; with two, the trainer facilitates feedback.
  • The CRM is chosen for each edition; the classroom table can also be used. No built-in AI or particular brand is required.
  • Conversation, feedback and retry fit within 25–30 minutes; no homework or follow-up session is added.

Choose your role document

Seller

Plays Elena: asks, checks conditions and leaves a next step; closing the sale is not required.

Client

Receives a separate brief and responds naturally within the case; may ask questions too.

Observer

Records behaviours and sources for three criteria; supports one correction and checks the retry.

The pack separates the seller, client and observer briefs. During the exercise, each person uses their own brief; the trainer arranges the roles.

How the exercise unfolds

  1. Prepare

    Read shared sources and your own brief; choose what needs clarification.

    4 min
  2. Converse

    Ask, listen and check conditions without reciting a script.

    6–7 min
  3. Record and check

    Review draft commitments and manually record the next action.

    4 min
  4. Feedback

    Cite evidence for each criterion and choose one priority correction.

    4–5 min
  5. Retry

    Repeat the part needing correction and update the record.

    4–5 min
  6. Close

    Check sources, action, owner and the case’s Thursday; collect an individual contribution.

    3–5 min

What the observer looks for

Questions and listening

Observed: Asks a relevant open question and checks one condition in their own words.

Needs review: Leads towards approval, ignores the response or does not check understanding.

Check commitments

Observed: Distinguishes sources from proposals and removes the unconfirmed yes and start from the draft.

Needs review: Asserts a budget, approval or start without a supporting source.

Next action

Observed: Records Elena’s two options by the case’s Thursday; retains IT as outstanding and the opportunity as open.

Needs review: An action, owner or classroom date is missing, or an outstanding matter is hidden.

After the conversation

Observed or Needs review, with a specific phrase or behaviour and its source. It is not an automatic course grade or certificate award.

Choose one correction, repeat the relevant part and record what changed and what remains outstanding.

A sample of feedback

Fictional classroom sample; consult after the first attempt.

What do you need to be able to compare between the two options?

Ladera’s interest does not approve the pilot: remove the invented yes and Monday.

Elena prepares two scope options by the case’s Thursday; the IT consultation remains outstanding.

Trainer rehearsal of this resource is pending. Thursday belongs to the fictional timeline, not today’s date. No real meetings, external messages, bots or automated records.

The criteria help guide feedback. Programme assessment remains the one agreed for each delivery.

What does your
team need to learn?

Tell us what you want to work on, how many people would take part and where you are based. We will prepare a proposal with scope, sessions and a budget.

Would you like to ask about FUNDAE?

We check eligibility for each company and edition, subject to requirements and available training credit in Spain. Funding is neither automatic nor guaranteed. Official FUNDAE information ↗

Discuss eligibility