This guide tells that story in full, explains what Google says it does about fake clicks, and walks you through what to check, what to change and how to ask Google for a credit while the window is still open.

The questions business owners ask first

Before the story, here are the short answers to the questions we hear most. Each one is covered in more detail further down.

Can a competitor really click my Google Ads?

Yes. Anyone who sees your ad can click it, including a competitor, an annoyed former customer, or someone paid to do it. Most deliberate clicking today is not one person at a desk. It is automated: scripts, rented servers and cheap mobile connections that make each click look like a different visitor.

Do I pay for those clicks?

Sometimes. Google filters a share of invalid clicks before you are billed, and you are not charged for those. Clicks its systems miss are billed like any other click unless Google later detects them or you ask for an investigation.

How would I know?

Your Google Ads reports will not tell you on their own. The clearest signs show up on your website: the same click repeating from different places, visits from countries you do not serve, traffic from servers rather than homes or phones, and leads that make no sense.

Will Google credit me for fake clicks?

You can ask Google to investigate activity from the last 60 days. If it finds invalid clicks that were billed, it issues a credit to your account. You cannot claim anything older than 60 days, so speed matters.

Is click fraud illegal in Canada?

Deliberately clicking a business’s ads to drain its budget can fall under the fraud offence in the Criminal Code. Proving who did it is the hard part. We cover this near the end.

Our story: what we found in our own account

We run Google Ads for Canada Create™ the same way we run them for clients, with Search campaigns for our core services and a Performance Max campaign alongside. Like most agencies, we watched cost per lead creep up through the summer and put it down to competition. Then the leads started to look strange.

Form submissions arrived with nonsense in the message box. Others were sales pitches or job requests sent through a form that only appears after an ad click. A few came in clusters minutes apart. None of it looked like a business owner looking for help.

Our website records the Google click ID that comes with every paid visit, along with the time, the visitor’s IP address and whether they did anything on the page. So we went back through every paid landing from late July to early October, about 1,400 clicks in all, and sorted them.

What the logs showed

Roughly four in ten paid clicks over that period showed clear signs of invalid traffic. Worse, the share was climbing:

• About 24% of paid clicks in early August.
• About 35% in September, with one day in mid-September when more than 150 suspicious clicks landed.
• 69% from October 1 to 9.

The patterns were not subtle once we looked for them:

• The same click, three countries. A single Google click ID is created for one click on one ad. We saw the same click ID arrive three times on one day, from a data centre in Amsterdam, a cloud server in Toronto and a mobile network overseas. A real person cannot do that.
• Servers, not people. Dozens of paid landings came from data centres and cloud hosts. One ad-tech company’s servers clicked more than 40 times in two days with an automated browser signature.
• Countries we have never targeted. More than 70 click IDs came from mobile networks in a country we do not serve and have never advertised to. Our campaigns target Canada.
• One address, over and over. One IP address recorded more than 130 ad landings in a single day. Another recorded 65 inside one minute.
• Leads with no intent. The form submissions tied to these clicks were spam, pitches and job requests.

One detail changed how we saw it. Background bot traffic touches every advertiser at a low, steady level. This was different: concentrated, rising week by week, and coming from places our ads were never meant to reach. It looked aimed at us.

We cannot prove who was behind it, and we will not guess in public. What we can say is that the pattern fits deliberate, targeted clicking far better than random noise.

The support ticket: what happened when we reported it

Google limits investigations to the last 60 days, so on October 14 we filed a claim covering mid-August to mid-October. Getting it filed took longer than it should have.

• The invalid click form linked from older help articles now leads to a “page not found” error.
• The working route goes through Google’s new AI support assistant, which first opened a different account linked to the same login and had to be told which one we meant.
• The assistant would not link the investigation form directly. It offered phone, chat or email, and the email option opened a detailed contact form.

We filled it in properly: account, campaigns, dates, keywords, the patterns above, a list of more than 50 suspicious IP addresses and a spreadsheet of the worst sources. A case number arrived within minutes, followed by a note that the matter had gone to a specialist team with a review time of two to three business days.

Google’s answer

The reply came the next morning. It said Google’s systems had already filtered 1,083 invalid clicks on our account in the period we reported, that we were not charged for them, and that some filtered traffic is simply accidental, like the second click of a double click.

That was not the question. We never asked about the clicks Google caught. We asked about the ones it did not catch and did bill. A reply describing filtered clicks tells you the system is working on some of the traffic. It says nothing about the paid clicks still getting through.

If anything, 1,083 filtered clicks in about two months supports the complaint. An account under that much invalid activity is very likely paying for some of it too.

We replied in the same thread, pointed out the difference between filtered and billed clicks, asked for the case to go to Google’s ad traffic quality team for a manual review, and offered the full click-level file with every click ID, timestamp and IP address. At the time of writing that reply has not been answered. We will update this article when it is.

What Google says it does about invalid clicks

To be fair to Google, its position is consistent and clearly written. Here is what it says, in plain terms, from its own help page on invalid traffic:

• Automatic filtering. Automated systems and manual reviews look for traffic that does not represent genuine interest, such as bots, accidental clicks and deliberate clicking by competitors. Invalid clicks caught before your billing cycle ends are removed from your reports and your bill.
• Later credits. If invalid traffic is found after you have been billed, Google issues an “Invalid activity” credit on a later invoice, where appropriate and possible.
• Where to see it. The Invalid clicks column in your campaign reports shows what was filtered. Credits appear in Billing under Summary, as adjustments labelled Invalid activity. The Invalid Activity Credit Report in the Report Editor shows your metrics with credits applied.
• Investigations. If you suspect invalid traffic that was not filtered, you can request an investigation into the last 60 days. Google asks for your customer ID, exact dates, campaign and ad group names, suspicious keywords, IP addresses, device details, click IDs and, for lead problems, your assessment of each lead.
• Limits. Google says investigations take several business days and that it will not confirm whether specific clicks were judged valid or invalid, because that could show fraudsters how detection works.

Google is also clear that lead quality is shared work. Its systems cannot see what happens on your website after the click, so it recommends protecting forms with tools like reCAPTCHA and server-side checks, and focusing campaigns on qualified leads rather than raw form fills.

None of this is new. Advertisers took Google to court over click fraud in the United States in the mid-2000s, and the case settled in 2006 for US$90 million, paid as advertising credits rather than cash. The problem has changed shape since then, from people clicking to automated networks, but the gap between what is filtered and what is billed is the same argument.

Industry estimates of what ad fraud costs advertisers worldwide run into the tens of billions of dollars a year. Those numbers are disputed, and no one outside the ad platforms sees the full picture. Your own account is the only number that matters to you.

What to do: a step-by-step guide

These are the steps we took on our own account and recommend to any business spending real money on Google Ads. Most take minutes.

1. Look at what Google already filtered

Add the Invalid clicks column to your campaign table (Campaigns, Columns, search for “Invalid clicks”). Then open Billing and check the Summary for Invalid activity adjustments. A high filtered count is not proof of a problem, but a sudden jump is a reason to look harder.

2. Make your website keep a record of every paid click

Google adds a click ID to the address of every paid visit (gclid, or gbraid and wbraid on some mobile traffic). Ask your developer to save that ID with the time, IP address, device and whether the visitor scrolled, clicked or filled in a form, and to attach it to every lead. Without this record you have suspicion. With it you have evidence Google can match to its own data.

3. Tighten location targeting

By default Google can show your ads to people who have shown interest in your area, not just people who are there. Change each campaign’s location option to Presence: people in or regularly in your included locations. Google explains the setting in its guides to location options and to preventing clicks from outside your targeted locations.

Then add every country you do not serve as an excluded location, and put your city or region in your ad text. A Toronto ad that says “Toronto” puts off people searching from elsewhere.

4. Exclude the worst IP addresses

Google lets you exclude up to 500 IP addresses per campaign, and you can block a whole range by using an asterisk for the last part of the address. Performance Max does not take campaign-level IP exclusions, so use the account-level list under Admin, Account settings. Google’s IP exclusion guide has the steps.

Treat this as damage control, not a fix. Automated clicking rotates through addresses, so an exclusion list stops repeat offenders but not new ones.

5. Review where your ads show

Search partner sites and Display placements carry more junk traffic than Google Search itself. If a campaign does not need them, switch them off. For Performance Max, review placement reports and use the account-level exclusions available to you.

6. Protect your forms

Add bot protection to every form, validate submissions on the server, and consider a confirmation step for email leads. This will not stop the clicks, but it stops fake leads from reaching your sales team and from teaching Google’s bidding to chase more of the same traffic.

7. Know the warning signs

Check your click records weekly for:

• One click ID arriving more than once, especially from different IP addresses or countries.
• Visits from data centres, cloud hosts or ad-tech companies rather than home, office or mobile connections.
• Clicks from places you do not target.
• Many clicks from one IP address in a short time.
• Paid visits with no scrolling, no clicks and no time on the page.
• Form submissions full of nonsense, pitches or job requests.
• A rising share of all of the above month over month.

8. File an investigation inside 60 days

The window closes on a rolling basis, so the oldest days of a bad stretch expire first. Start from Google’s click quality contact form. If it routes you to the support assistant, ask it plainly to submit an invalid traffic investigation for your account, check that it has picked the right account, and choose email so you have a written record. Include:

• Your 10-digit customer ID, the campaigns affected and the exact dates.
• The keywords driving the suspicious clicks.
• A plain description of each pattern with a dated example.
• A spreadsheet of IP addresses with counts, first and last seen times and what you saw from each.
• Click IDs for the suspicious visits and, for lead problems, your assessment of each lead.

9. If the answer misses the point, reply in the same thread

If the reply only talks about clicks that were already filtered, answer in the same email thread and keep the case number. Say clearly that your request concerns billed clicks, ask for the case to go to the ad traffic quality team for a manual review, and offer your full click-level file. Short, specific and polite gets further than angry.

10. Keep the evidence

Save your raw logs, the support emails and any credits that arrive. If you ever identify who is behind it, you will need that record. Deliberately using deceit or other fraudulent means to take someone’s money can fall under section 380 of the Criminal Code. Whether a case like this would hold up depends on the facts and on proving who did it. This is general information, not legal advice: speak to a lawyer before acting on it.

Can a click fraud tool solve this?

Several independent services monitor paid clicks and push blocks to Google Ads automatically. They can save time if you have no developer and a large budget. Judge any of them by four things: whether they read the click ID and not just the IP address, whether they block at account level so Performance Max is covered, what evidence they hand you for a Google claim, and whether the cost is lower than the waste they stop. No tool can prevent every fake click, because the click happens on Google before any of them sees it.

What this taught us

Three things stand out from our own experience.

• Your own records are your strongest evidence. Google will not show you click-by-click decisions. A file of click IDs, times and addresses is what turns a complaint into a case.
• “Filtered” and “billed” are different questions. Make sure every message to Google is about the clicks you paid for.
• Watch the trend, not the day. Our problem went from one in four clicks to more than two in three in about ten weeks. A monthly check would have caught it in August.

If your cost per lead has climbed and your leads have got stranger, check your clicks before you raise your budget. A lead is only worth what the click behind it was worth, which is why click quality belongs in every Google Ads review and every lead generation plan.

Case status: our reply to Google is still awaiting an answer. We will update this article with the outcome.

For an owner or operations manager, the most useful report may answer a modest question: can we see which requests still need attention? That is a different question from how many people visited the website, whether a marketing campaign influenced an enquiry or how much revenue appears in a case-management system. This guide helps you assess those distinctions when buying CRM and reporting support.

Agree the question before choosing the dashboard

Start with the decision you need to make. You may need to know whether enquiries are assigned, whether staff have responded, whether requested appointments are still outstanding or whether a location has unresolved handoffs. A report that combines these into a single “leads handled” total can obscure the very issue you are trying to resolve.

Ask the supplier to describe the intended reader, the review frequency and the action the report is meant to support. An operations manager reviewing open requests needs different detail from an owner comparing overall workload. A marketing review may need approved summary information without access to private correspondence.

Keep the proposed report proportionate to that purpose. More personal information does not automatically make a report more useful. The Office of the Privacy Commissioner of Canada’s limiting-collection guidance calls for collecting only the personal information needed for an identified, legitimate purpose. Confirm the applicable requirements for your operation and the information the report genuinely needs.

Separate receipt, acknowledgement and staff response

An automatic acknowledgement can tell someone that a message reached a system. It cannot, by itself, show that your staff reviewed the request or provided a relevant response. The reporting agreement should preserve that difference.

Ask what counts as a meaningful staff response for the purposes of your report. An agreed definition could require a staff member to review the enquiry and provide an appropriate reply through an agreed channel. That is a proposed reporting definition, not a universal standard or a guarantee that the person’s needs have been resolved.

In Ontario, pre-planning and prepayment also have distinct meanings. The BAO explains that pre-planning does not require prepayment. A planning enquiry should therefore not be presented as a paid arrangement. Keep contracts, payment evidence and professional decisions within the operator’s approved records and responsibilities.

Require definitions and coverage beside the numbers

A total is difficult to interpret without knowing what is included. Ask whether “enquiries” means messages, unique requests or people. Two family members may contact the home about the same matter; the same person may use both the telephone and a website form. The proposal should explain the agreed counting approach without assuming that every contact is a new arrangement opportunity.

Time periods need equal care. Does the report concern requests received during a period, responses made during that period or all currently open requests? A response to an earlier enquiry may fall outside a received-this-week total. Comparing those two totals as though they described the same group would be misleading.

For a multi-location Canadian operator, clarify the locations, local service hours and time zones included. An agency support target is not the funeral home’s urgent-response commitment. A report should not suggest that a family received professional attention just because an online form was accepted outside staffed hours.

Ask for a short definitions note with each report: covered period, included contact routes, meaning of each measure, exclusions and known limitations. Definitions should remain stable enough for comparisons to be meaningful. If they change, the reader should be told rather than interpreting a different total as an improvement or decline.

Make missing information visible

A missing result can have several explanations. An enquiry may have arrived through a route outside the agreed reporting scope. A staff member may have replied without the response being recorded in the connected system. Historical records may not contain the same information as current records. A vendor connection may also have limits or interruptions.

The buyer’s requirement is to distinguish missing evidence from a confirmed absence of action. “No staff response recorded” is a more careful description than “staff ignored the family” when the report cannot establish what happened. It still identifies a question for the operator to investigate.

Ask who reviews exceptions, which supplier is responsible for a reporting fault and what the report will say while the issue is unresolved. If a connection is part of the scope, its coverage, dependencies and support responsibilities should be explicit. A software logo beside the word “integration” does not establish complete reporting.

Do not require a supplier to invent a source for every enquiry. An honest “unknown” category can be more useful than a confident attribution based on incomplete evidence. The report should describe whether a source was reported by the enquirer, recorded by an included system or left unavailable.

Worked example: twelve enquiries do not mean twelve staff responses

Illustrative reporting example: imagine an operator-approved set of twelve distinct enquiries received during one reporting week. All twelve have an automatic acknowledgement. Eight have the agreed evidence of a staff response. Four have no staff response recorded by the review point. These invented counts illustrate interpretation; they are not client results or a response benchmark.

A summary saying “twelve enquiries handled” would hide the distinction between an acknowledgement and staff response. The owner should ask about the four gaps. Some may reflect missing records rather than missing replies, so the report alone should not be used to judge an employee’s conduct.

The source counts answer a separate question. They do not reveal which of the eight staff responses came from which source, and they do not establish that a campaign caused an arrangement. The response view adds to twelve; the source view also adds to twelve. Adding the two views together would double-count the same enquiries.

Suppose an arrangement is also documented that week for a person who first contacted the home in an earlier period. It should not automatically be divided by the twelve new enquiries to announce a conversion rate. The populations and timing differ. Ask the supplier to explain the relationship between the records before drawing that conclusion.

Keep internal reporting separate from advertising data use

The operator may need identifiable information in an approved internal system to handle an enquiry. That does not make the information suitable for general analytics, a marketing dashboard or disclosure to an advertising platform. Ask who needs access, for what purpose and under which agreed permissions.

Canada Create’s funeral marketing scope keeps identifying family information and sensitive health details out of general analytics and advertising audiences. An internal CRM brief should preserve that boundary and identify separately any proposed external measurement work.

Google treats bereavement products and services as a sensitive-interest category and restricts advertiser-curated audiences for promoting them. Its relationship-hardships advertising policy is a distinct consideration from legitimate internal enquiry handling. A CRM reporting purchase is not permission to create advertising audiences from family records.

Advertising measurement has its own requirements too. Google’s customer-data policies address permitted data, disclosures, consent and restrictions for particular measurement features. Any proposed measurement scope needs its own eligibility and privacy review. Neither an internal record nor a general statement that “everything is connected” establishes permission to transmit it.

Even a summary needs a sensible audience. A small location or a very narrow category may make a family recognisable without displaying a name. Ask whether the report needs that detail, who can receive it and what should remain with authorised operational staff. This is a review of the proposed disclosure, not a claim that removing a name automatically anonymises a report.

Read recorded outcomes without claiming causation

A CRM can contain an enquiry source, an appointment and a later recorded arrangement. That is a record of information and events. It does not establish that the CRM created the arrangement, that a particular advertisement caused it or that every relevant interaction has been captured.

Families may already know the provider, hear a recommendation or use several contact routes. The report may have access to only part of that history. Ask the supplier to state what an attribution claim is based on and what remains unknown. Avoid a proposal that counts all recorded revenue as a return on its own work.

For buying purposes, separate operational usefulness from commercial attribution. You can assess whether staff can find open requests and whether the agreed report is complete within its stated coverage without promising more arrangements. A later marketing evaluation needs an appropriate, separately agreed basis and limitations.

Questions to include in a reporting proposal

Request a sample built from fictional or suitably de-identified information and review it with the staff who would use it. A useful demonstration should let you explain the figures in plain language, spot an unresolved request and identify where more evidence is needed.

• Purpose: what decision does each report support, and who receives it?
• Definitions: what counts as an enquiry, staff response, appointment or recorded outcome?
• Coverage: which systems, contact routes, locations and periods are included?
• Gaps: how are unknown sources, missing records and interrupted connections presented?
• Responsibility: who reviews an exception and who fixes a supplier-side fault?
• Privacy: what information is necessary, who can access it and what stays out of general reporting?
• Review: how often are reports delivered, who explains them and what changes require a new scope?
• Cost: are software, connection fees, ongoing support and staff work included or separate?
• Acceptance: what agreed evidence will show that the report answers its intended question?

A small report with clear definitions can be more decision-useful than a large dashboard with unexplained totals. If the source records cannot support a proposed measure, agree a narrower report or resolve that dependency before treating the measure as part of the purchase.

Scope reporting around a real operating question

Canada Create’s Funeral Home CRM service can assess enquiry management, staff handoffs and reporting within an agreed scope and the limits of your existing tools. Start with the question your team cannot currently answer. Business-process descriptions and fictional examples are enough for an initial discussion; leave family records, identity documents and sensitive case details out of public forms.

For the public-facing website, local search and approved communications around that handoff, see the separate funeral home marketing service. A written proposal should distinguish the marketing work, internal reporting, supplier responsibilities and fees. The useful outcome is a report your team can interpret and act on within its stated limits.

This guide is for funeral-home owners and operations managers comparing a proposed move. It helps you judge the written scope, the work your staff must approve and the obligations that continue when a subscription ends. The aim is a purchasing decision you can defend, with clear exceptions and costs, rather than an assumption that everything transfers. Your licensed operator retains responsibility for family care, professional decisions and required records.

Decide what is actually changing

A new CRM, a replacement funeral management system and a new website can involve different records, suppliers and responsibilities. Decide which purchase solves your problem before asking for a migration price.

• Keeping funeral management software and adding enquiry support: the new service may need only permitted enquiry information, contact preferences and staff responsibilities. Detailed arrangement, contract and financial records may remain in the existing system.
• Replacing the operational platform: the scope may involve active cases, historical arrangements, documents and other records your operator must continue to access. Each category needs its own inclusion or exclusion decision.
• Changing the website supplier: obituary pages, public links, media rights and contact routes need attention even if your internal software stays the same.

If a proposal treats all three as one undifferentiated “data migration,” ask the supplier to separate them. You need to know which organisation holds the source information, which recipient can receive it and who is responsible for each dependency. Keeping a suitable existing system can be a reasonable outcome; a CRM engagement does not automatically require replacing it.

Agree the records and context your team needs

“All customer data” is too vague for a funeral business. A person may appear as an enquirer, a family contact, a pre-planning client or an authorised representative. Those relationships and their purposes matter. Copying a name and telephone number alone may leave staff unable to tell what the person asked for or whether further contact is appropriate.

Use the proposal to distinguish information needed in the new service from information that should remain in an approved record system or archive. The table below is a buying aid, not an instruction to transfer every category.

For each included category, the agreement should say what “available” means. Searchable access for authorised staff, a readable archive and a working connection to another supplier are different deliverables. Have your operator and relevant advisers determine the legal recordkeeping requirements; do not let a convenient software category make that decision.

Ask for evidence of a usable export

The right to receive a file and the ability to use its contents are separate questions. A spreadsheet might provide financial totals while omitting correspondence and supporting documents. A collection of PDFs might be readable but leave staff unable to tell which documents belong together. Neither is necessarily unsuitable, but neither proves that the proposed replacement can support your required work.

Before committing, ask each supplier to explain the information it can release or receive, the format, the included history and the important exclusions. Request a demonstration using synthetic records or another specifically approved, privacy-appropriate example. Do not send family files through a general sales form to obtain a quote.

A useful demonstration answers a business question: can an authorised member of your team identify the relevant enquiry, understand its current position and find the supporting information included in the scope? It should also make missing information visible. A successful opening of one file does not establish that every record, attachment or historical period is covered.

Clarify whether an export requires an active subscription, supplier assistance or a separate fee. Ask what access remains after cancellation and whether a later correction or access request can still be handled. These answers belong in the agreement, rather than in a salesperson’s general assurance that “you own your data.”

Keep permissions and privacy decisions attached to the move

Changing software does not, by itself, create a new right to contact a family or use its information for another purpose. An individual who requested a planning conversation has not necessarily agreed to recurring promotional messages. A request to stop contact must not disappear because the old system held that preference separately.

The Office of the Privacy Commissioner of Canada’s meaningful-consent guidance explains why sensitivity, purpose and people’s reasonable expectations matter. Confirm the applicable federal and provincial requirements with your privacy adviser. Information about deceased people and sensitive information about living family members should not be treated as one uniform legal category.

A transfer for an already authorised purpose needs a different assessment from adding advertising, profiling or a new communication purpose. Confirm whether the proposed recipient or purpose changes the permission required; earlier permission does not necessarily cover a new use. Resolve who may receive the information, why they need it and what restrictions remain before including the transfer in the engagement.

The OPC’s cloud guidance for businesses also makes clear that outsourcing does not remove an organisation’s accountability. Ask about supplier access, subcontractors, storage and processing locations, incident responsibilities and exit arrangements. A Canadian address or a security badge alone cannot answer those questions. Your assessment must reflect the information involved and the laws that apply to your operation.

Separate historical coverage from ongoing connections

A connection between two systems may support new activity without carrying earlier history. It may cover some record types and stop updating others after a particular status change. A website connection may publish selected information while the operational system remains responsible for later corrections. “Integrated” does not identify these boundaries.

Ask the suppliers to name the authoritative system for the information that matters to your team. The proposal should explain which direction agreed updates travel, which historical records are included and what exceptions require staff attention. These details define the service and limitations your team is being asked to approve.

For example, if a planning enquiry becomes a documented arrangement, ask whether its earlier conversation remains accessible and where staff should look for the current position. If a public obituary is corrected, ask which supplier is responsible for keeping the intended public version accurate. The important purchasing question is whether the agreed service preserves the context your staff need, with limitations they can recognise.

Name who carries the work through a supplier change

Family enquiries do not wait for a software project to finish. Your operator needs agreed arrangements for urgent contacts, routine enquiries and unresolved work during the change. The software supplier, website provider and implementation agency may each control only part of that experience.

Identify a decision-maker at your funeral home and a responsible contact for each supplier. Agree who confirms the source information is available, who addresses exclusions and who accepts the finished scope. Your team also needs enough time to review the proposed access and practise its own responsibilities before relying on the new service.

Where a website is involved, include the contact routes and public information your team needs to retain. A working new homepage does not demonstrate that existing obituary links, enquiry forms or the provider’s at-need number are correct. For Ontario operators, keep the applicable BAO website information requirements in view during the change. Other provinces require their own assessment.

Ask what happens if a dependency is late or an agreed test reveals a material gap. The response may be to defer release, retain an approved temporary arrangement or narrow the first release with your approval. Do not accept a promise of zero interruption without a defined commitment and supporting terms. Agency project support is also separate from your funeral home’s responsibility for urgent family care.

Compare the cost of leaving as well as joining

A new subscription price can conceal a more expensive transition. Compare the full written commitment, including work charged by the outgoing supplier and access you may need to retain. No universal migration price or standard completion time can account for every funeral home’s systems, records and contract.

• Outgoing-provider charges: export assistance, termination obligations and any continuing access or archive fees.
• Incoming work: the agreed migration scope, review, staff handover and separately quoted corrections or additional history.
• Overlap: subscriptions, hosting or other services that may need to remain active during an approved transition.
• Third-party dependencies: obituary, website, accounting or other suppliers whose work is outside the main quote.
• Ongoing access: licences or support needed to use retained archives and deal with later questions.

Ask whether the amount is fixed for a defined scope, an estimate with assumptions or work charged as used. Confirm the currency, taxes, payment milestones, term and cancellation conditions. Record who authorises additional work when information is missing or incompatible. A low entry price with uncertain exit rights is not directly comparable with a quote that includes a usable archive and staff review.

Control of your business records does not mean ownership of a supplier’s software, pre-existing tools or third-party materials. Separate permitted data access and export rights from software licences, custom deliverables and publication rights. Have material contract questions reviewed before you accept the agreement.

An illustrative decision: what should this operator approve?

This is a hypothetical purchasing example, not a client case study. A two-location funeral home wants clearer responsibility for planning enquiries. Its current funeral management system remains suitable for arrangements and financial records. An incoming supplier offers to import contacts and provide an enquiry workspace.

The offer could meet a real need, but “contacts imported” leaves several decisions unresolved. Some planning conversations have a named staff contact, others have requested no further promotional communication, and historical documents sit with a separate provider. The operator should not assume that importing the contact list resolves those differences.

In this example, proceeding with a limited scope may be reasonable if the confirmed service solves the enquiry problem and the remaining records stay appropriately accessible. If contact restrictions cannot be established or necessary history is inaccessible, the operator has a reason to resolve the gap before approving that scope. This is a conditional decision, not evidence that adding a CRM will improve revenue or that this arrangement suits every provider.

Agree what remains after the old account closes

Retaining everything indefinitely and deleting everything when a subscription ends are both poor assumptions. The OPC’s retention and disposal guidance explains that retention depends on the purpose and applicable requirements; there is no single period suitable for all records. Your operator and advisers must determine what the business needs or is required to retain.

The exit agreement should identify what returns to you, what remains in an approved archive, who may access it and what the supplier retains for a justified reason. Ask how temporary transfer copies, backups and subcontractor-held information are addressed, including timing and confirmation of disposal where appropriate. Do not request destruction that would conflict with an applicable recordkeeping duty or unresolved legal requirement.

An archive needs an owner after the project closes. Someone at your organisation should know how authorised access, corrections, family requests and later supplier questions will be handled. If access depends on keeping a paid service, include that obligation in the purchasing decision rather than discovering it after cancellation.

A decision you can take back to the supplier

A credible proposal lets you answer five questions in ordinary language:

1. Purpose: which business problem does this move solve, and which existing systems remain?
2. Coverage: what permitted information, history and context will be usable, and what is excluded?
3. Responsibility: which supplier and operator contact handles each dependency, family-response concern and acceptance decision?
4. Commitment: what are the full costs, rights, term and conditions for leaving both the old and new arrangements?
5. Evidence: what agreed demonstration and documented exceptions will support your approval?

If a material answer is missing, request a clearer scope before committing. If the answers describe a smaller project than you first expected, assess that project on its own merits. A controlled decision with acknowledged limits is more useful than an expansive promise that no supplier has confirmed.

Canada Create’s funeral home CRM service starts with your existing tools and a separately agreed implementation scope. Compatibility, access, permissions and vendor participation need assessment before migration work can be promised. Share your business systems and priorities when enquiring, without family records or sensitive case details. Website and public-contact continuity can also be considered within an agreed funeral home marketing engagement.

This guide is for funeral-home owners, licensed operators and operations managers comparing communication support. The buying decision is whether the proposed service can help your team honour a person’s request without assuming more authority or permission than you have. A polished message template cannot settle that question on its own.

Start with the purpose of the contact

“Follow-up included” is too broad to be a useful commitment. Ask the supplier to describe the actual business purpose: responding to a planning enquiry, confirming an appointment, supplying a requested resource or sending promotional material. Each purpose can involve different information, approvals and staff responsibilities.

A sensible brief also identifies what the service will leave to your team. Questions about immediate care, funeral arrangements, disputed instructions or the meaning of a contract need the operator’s approved handling. A communication service should not quietly become the decision-maker because it happens to receive the reply.

Ask the supplier to explain these distinctions with a fictional example before discussing real family records. If all four purposes are presented as one undifferentiated contact list, the proposal needs more work.

Keep planning interest separate from contracts and prepayment

A person may ask about planning without deciding to purchase anything. In Ontario, the Bereavement Authority of Ontario explains that pre-planning can take place without prepayment, while prepayment involves a contract. That distinction matters when you evaluate what the CRM displays and what staff may infer from it. See the BAO’s pre-planning and prepayment guidance.

For the buyer, the requirement is straightforward: staff should be able to tell the difference between an information request, an appointment and an arrangement documented in the operator’s approved records. A convenient label such as “planning complete” needs an agreed meaning. It should never stand in for evidence of a signed contract, funds received or a person’s authority to instruct arrangements.

Ask which system remains authoritative for contracts and financial records, and who verifies a change in status. You may need only clearer communication responsibilities in your current system. A separate CRM is worth considering when there is a defined gap that existing software and staff arrangements cannot reasonably address.

Evaluate permission, preferences and the actual message

For Canadian electronic communications, purpose and content matter. The CRTC’s CASL guidance distinguishes commercial messages and explains applicable consent, identification and unsubscribe requirements, with exceptions depending on the circumstances. A requested reply and a promotional message should not be treated as automatically equivalent. Review the proposed use with the person responsible for your legal obligations. The CRTC’s CASL questions and answers provide the general framework.

Contact preferences answer another question: how does this person want the permitted communication handled? Someone may prefer a telephone conversation, a particular language or contact through an authorised representative. Those preferences do not establish legal authority or create permission for a new purpose. The proposal should explain how staff can see and respect them within the agreed scope.

For a Canadian operator serving more than one province or language community, ask who approves the wording and who can actually respond in the offered language. A translated first message is incomplete support if the next reply reaches staff who cannot continue the conversation. Define the supported languages, review responsibilities and limits before advertising that experience.

The Office of the Privacy Commissioner of Canada stresses that consent and sensitivity depend on context and reasonable expectations; consent does not permit indiscriminate use for unrelated purposes. Apply that principle to the proposed handling of living family members’ information, with advice on the law that applies to your operation. Read the OPC’s meaningful-consent guidance.

Define requested aftercare without turning it into a sales assumption

Aftercare can mean different things in different proposals. One supplier may mean sending an approved resource requested by a family member. Another may mean reminders for staff, a subscription to information or a series of promotional messages. Compare the actual deliverables rather than accepting the label as a complete description.

Ask what the person requested, what the funeral home has agreed to provide and what happens when the reply falls outside that scope. A request for information about local support does not make an agency a grief counsellor. An automated acknowledgement does not mean a member of your team has read a sensitive reply.

Useful communication support gives the operator control over approved resources and escalation. It should allow a staff member to pause a proposed communication when the context has changed or is unclear. Avoid buying a programme whose value depends on interpreting bereavement as a sales signal, repeatedly prompting someone who has asked for space or assuming every family wants the same contact.

You do not need to prescribe a universal contact schedule to assess fit. You need to understand whether the service can respect the purpose, current preference and judgement of the staff member responsible for that relationship.

Name the people responsible for messages and replies

The contract should distinguish content preparation, approval, sending, monitoring and professional response. These may be shared among your staff, an agency and a software vendor. If no one has accepted responsibility for a reply, a feature called “two-way messaging” is an incomplete service commitment.

If AI-assisted drafting or intake is proposed, ask for its specific role, review requirements and human handover. Do not infer that an AI feature can judge authority, provide funeral advice or decide how a sensitive family situation should be handled. The proposal should make limitations visible to both staff and the people using the service.

Test the proposal against a changed preference

A demonstration is more useful when something changes. Ask the supplier to explain what staff would see if a person withdrew from promotional contact, changed their preferred channel or said that a previous representative should no longer receive updates. Use a fictional record and assess the business outcome, rather than requesting a tour of configuration screens.

Look for a clear answer about who reviews the change, which agreed communications it affects and what remains unresolved across other systems. An imported address or an old note should not silently override a newer instruction. One relative’s request also should not be treated as blanket authority over every other living family member.

Stopping an unwanted communication and deleting a record are different decisions. The applicable retention obligations and permitted uses still need review; a universal “delete everything” promise can be as misleading as a promise to retain everything indefinitely. The OPC’s consent guidance discusses withdrawal and circumstances in which some information may still need to be retained.

Worked example: two requests, two different responsibilities

Illustrative procurement scenario: an Ontario funeral home is considering CRM communication support. One adult asks for a pre-planning appointment. Separately, an adult family member asks for a particular aftercare resource and says they do not want promotional messages. These are fictional requests, not a client case study or measured result.

The owner compares two proposals. The first offers a single automated follow-up package but leaves the purpose of later messages, staff review and reply coverage undefined. The second identifies the appointment request and resource request separately, requires approved wording, records the agreed preferences and names the operator’s contact for sensitive replies.

The second proposal is more assessable because its responsibilities are explicit. That does not make it automatically compliant or the right purchase. The owner still needs to confirm the permitted information, vendor limitations, actual staff capacity and full cost. If the existing funeral-management system already supports those requirements, a smaller improvement there may be enough.

Now change one fact: the resource recipient asks for no further contact. A useful demonstration explains how the agreed communication stops, how staff are informed and which records still require review. It should not turn that request into a new attempt to persuade the person to remain in a programme.

Compare the written scope, including ongoing work

The total commitment may include software subscriptions, message charges, content preparation, language review, staff training and ongoing support. Ask what is included in the quoted work and what creates an additional charge. A low setup price is not enough to compare proposals if one leaves monitoring and content updates entirely to your team.

Before approving, check that the proposal answers these questions:

• Which contact purposes, channels and languages are included?
• What must your operator approve, and how much staff review will that require?
• Who handles replies, exceptions and interruptions, during which agreed hours?
• How will changed preferences and uncertain authority be brought to staff attention?
• Which system holds the authoritative contract and financial information?
• What vendor access, subscription or supported connection does the service depend on?
• What evidence will show that the agreed communication controls work before release?
• What ongoing charges, support limits and exit arrangements are part of the commitment?

Where a supplier cannot answer a material question, leave that part of the purchase unresolved. It is better to agree a smaller, reviewable service than to buy an expansive promise that depends on permissions, staffing or software behaviour nobody has confirmed.

Discuss a bounded communication brief

Canada Create’s Funeral Home CRM service can scope enquiry management, approved communications, staff handoffs and related CRM support around your existing tools. Start with business requirements and fictional or suitably de-identified examples. Do not send family records, identity documents, passwords or sensitive case details through a public enquiry form.

If the gap is the creation of public information pages or approved outreach materials, review the separate funeral home marketing service. The communication brief should make clear which work is being commissioned and which decisions remain with your operator. Written scope, fees and responsibilities come before a commitment.

For an owner or operations manager, the first decision is whether to improve the software already in place, connect a supported component or commission a different setup. The right choice depends on the work, the people responsible for it and the information the operator is permitted to use. A feature list alone cannot answer that question.

This guide helps Canadian funeral-home operators make that buying decision. It uses an illustrative Ontario example and distinguishes enquiry management from the professional, contractual and family-care responsibilities that stay with the operator.

Start with the work, rather than the software label

“Funeral management software” and “CRM” are overlapping descriptions. A funeral-management product may include enquiry records, staff assignment, appointments and family communications alongside case administration. A CRM may help organise contacts and outstanding work without providing the arrangements, financial records or other specialised functions the business relies on.

Do not assume the existing system lacks a feature because it is not sold under the CRM label. Equally, do not assume a general CRM can replace a funeral-specific function because both products display a contact record. The useful comparison is between your requirements and the exact edition, permissions and supported functions available to your team.

The table is a requirements comparison, not a claim that every product includes each function. Ask the supplier to identify what is available today, what needs extra work and what remains outside its offer.

Describe the unresolved problem in a sentence

“We need a CRM” is a purchase preference. “When a pre-planning enquiry reaches either location, managers cannot tell who has agreed to call back” describes a business problem. The second statement gives a provider something concrete to assess.

Be precise about the consequence. Staff might be asking a person to repeat information, making duplicate calls, missing an agreed appointment or spending time reconciling different versions of the same record. Those situations do not all call for the same purchase.

• An access gap: the information exists, but the authorised staff member cannot see the appropriate part of it.
• A responsibility or training gap: the feature exists, but staff have different understandings of who owns the work or how its status is recorded.
• A capability gap: the selected product or edition cannot support a requirement that the operator has confirmed is necessary.

A review may find more than one gap. Ask for the reasoning behind the proposed response. A new platform will not, by itself, decide who should return a sensitive call or make staff available to do so. A training session will not supply a connection the vendor does not support.

Compare three options on the same business requirement

Improve the existing setup

This deserves consideration when the current platform already has the relevant functions and the main difficulty concerns agreed responsibilities, authorised access or staff confidence. A limited engagement might assess the setup, confirm what can be changed and provide role-based handover or training.

Ask what the improvement costs and which supplier must approve it. An unused feature may require a different subscription, additional permissions or vendor involvement. Keeping the platform is not automatically free, but it may avoid unnecessary duplicate records and another contract.

Add a supported connection

A connection may be appropriate when the core system works well and a clearly defined gap sits between it and another tool, such as the website’s enquiry route. Its value depends on what is actually supported, which system controls each record and who handles exceptions.

A product logo on an integrations page is only a starting point. The proposal should identify the relevant products and editions, the permitted information, the direction of updates and any historical or status-related limits. Keep a manual handoff visible in the scope if that is the supported option.

Add or replace an agreed component

A separate CRM deserves consideration when the necessary work cannot reasonably be supported by the existing arrangement and the additional responsibility is justified. This does not mean replacing the operator’s entire funeral-management system.

Clarify what the new component will handle and what will stay elsewhere. Include the staff effort needed to maintain reliable records, review contact preferences and deal with interruptions. Replacing more than the unresolved problem requires a stronger case, especially when contracts, archives or established family-service routes could be affected.

These are alternatives, not mandatory stages of a technology upgrade. A business can reasonably decide to keep its current arrangement after a proper assessment.

An illustrative two-location decision

Illustrative example, not a Canada Create client case. Consider an Ontario operator with two funeral-home locations. Staff use an established funeral-management system for arrangements and a shared inbox for website enquiries. The owner is concerned that a request for a pre-planning appointment can receive two callbacks, while another waits because each location assumes the other is handling it.

The owner initially asks for a new CRM. During a supplier demonstration using fictional records, the existing system is shown to include enquiry assignment and location-specific access in the operator’s current edition. The remaining question is whether those functions can support the business’s approved responsibilities and whether the website handoff is suitable.

The comparison changes:

• Improving the current arrangement would require a defined assessment, approved access changes where needed and staff training. The operator still needs to decide who owns an enquiry received outside each location’s normal coverage.
• A limited connection would need evidence that the website and current system support the required information and contact preferences. If they do not, an explicit staff handoff may remain necessary.
• An additional CRM would create another subscription and another place where staff might need to maintain information. The proposal would need to show what worthwhile capability it adds beyond the demonstrated features.

On those illustrative facts, a focused review of the current arrangement is the sensible first purchase to consider. It is a provisional buying conclusion, not proof that the system will solve the problem. The operator should agree what staff must be able to see and do before accepting the work.

The conclusion could change if the demonstration showed that permitted access could not be separated by location or that a necessary function was unavailable. The same problem can lead to a different buying decision when the evidence changes. Neither the number of locations nor a general growth ambition settles the choice.

Keep Canadian operator responsibilities in the decision

A software comparison becomes more useful when it respects the meaning of the records. In Ontario, the Bereavement Authority of Ontario explains that pre-planning can happen without prepayment. A request for a planning appointment therefore should not be treated as proof of a signed prepaid arrangement. A CRM status cannot establish a person’s authority to give funeral instructions or replace the operator’s required documentation.

For a Canadian business, the assessment should identify the applicable provincial requirements and the operator’s approved processes before recommending changes to professional records. This guide does not determine those requirements for every province. Keep funeral advice, regulated arrangements, funds administration and urgent family care with the people and systems the operator authorises.

Privacy also changes what “better visibility” should mean. Managers may need to know that a callback is outstanding without every employee needing access to detailed arrangement information. The Office of the Privacy Commissioner’s meaningful-consent guidance addresses purposes, sensitivity and reasonable expectations. A record collected for one purpose is not unrestricted permission for a different use.

Ask why each category of information is needed in the proposed CRM and who will be permitted to use it. Initial agency discovery and product demonstrations can use fictional records and descriptions of the work. Family names, death certificates, payment documents and detailed arrangements do not belong in a public quote form.

Do not assume that a product marketed in Canada stores all information in Canada or that a funeral-specific label certifies compliance. The OPC’s cloud-computing guidance makes the provider relationship and accountability relevant to the decision. Confirm the selected vendor’s terms, information locations, safeguards and exit options with the appropriate advisers.

Include the work your staff will inherit

A system can look impressive in a demonstration while leaving staff with extra work. Compare the proposed benefit with the responsibilities that continue after launch: reviewing enquiries, keeping contact preferences current, checking unresolved work, learning the new interface and asking for help when something does not behave as expected.

For a multi-location operator, establish who owns shared work, which decisions remain local and how staff absences or system interruptions will be covered. “Everyone can see it” is not the same as “someone is responsible for it.” Neither is an automatic acknowledgement evidence that a staff member has provided a meaningful response.

Consider the full commitment without assuming a price range. It can include implementation, software licences, messaging usage, training, vendor support and later changes. Ask for the quote’s currency, applicable taxes, agreement term and renewal conditions. An inexpensive subscription may still be a poor fit if it requires duplicate entry or an unsupported handoff; a larger scope needs a clear reason beyond a longer feature list.

Ask for a demonstration that answers the buying question

Give each potential provider the same short description of the unresolved work and ask them to address it with fictional or suitably de-identified examples. A polished tour of unrelated features is less useful than a clear answer to the requirement that prompted the enquiry.

• Can the proposed setup show which authorised staff member owns the requested action?
• Is the demonstrated function available in the exact product and edition being quoted?
• Can staff distinguish a general enquiry, voluntary planning request and documented arrangement without changing their legal meaning?
• Which system holds the approved version of a shared record, and who resolves conflicting changes?
• Which information, history or attachments will remain outside the proposed scope?
• What work will staff still need to do, and what training and support are included?
• What happens if a connection fails, a staff member leaves or the business changes providers?
• What would the provider recommend keeping, rather than selling again?

Separate what has been demonstrated from what is conditional on vendor access, further assessment or a later purchase. Record those distinctions in the proposal. A sensible response can be “this requirement is not supported”; that answer is more useful before commitment than an unclear promise discovered after launch.

Make a bounded decision you can explain

Before approving a purchase, the owner and operator should be able to explain the unresolved problem, why the existing arrangement cannot adequately address it, the chosen scope and the responsibilities that remain with staff. If those answers are still vague, buy a defined assessment first rather than treating a broad implementation package as the diagnosis.

Agree how the delivered work will be accepted. For this decision, useful evidence might be an authorised staff view of outstanding enquiries, a demonstrated appointment handoff or a clear explanation of unavailable records. These are acceptance criteria for the commissioned work, not promises of more arrangements, revenue or guaranteed time savings.

The website’s role is to help the right person find information and make an appropriate enquiry. Internal handling begins with the operator’s agreed responsibilities. If the actual problem is too few relevant enquiries rather than unclear staff ownership, adding a CRM alone does not establish the answer; that is a separate marketing decision.

Canada Create can assess the existing tools and the enquiry-management gap before proposing CS+, Canada Create’s CRM, or another agreed setup. Our Funeral Home CRM implementation service sets out the possible scope, vendor dependencies, staff responsibilities and costs. Share your current software and the work you want to improve, without sending private family records.

Compare proposals against the same business need before comparing their totals. “CRM setup” could mean a limited configuration project or a broader engagement involving website enquiries, selected records, staff access and handover. Those are different purchases even when both proposals use the same heading.

This guide is for Canadian funeral-home owners and operators evaluating an implementation engagement. It provides a scope comparison, an illustrative proposal example and the questions that make costs and responsibilities clearer. It does not give a market price range or suggest that a software purchase guarantees additional arrangements.

Give each provider the same requirement

Begin with the work the business needs to improve: for example, staff responsibility for enquiries across locations, requested pre-planning appointments or an accurate view of outstanding follow-up. Name the existing software, the locations and staff roles involved, and the functions that must remain with the operator’s current systems.

The proposal should identify the selected product and edition, the users and locations included, the agreed deliverables and the exclusions. If a provider has not assessed the current software or the permitted records, its migration or connection estimate may still be conditional. That is a useful distinction to have in writing.

Keep the agency engagement separate from the software subscription. The agency may assess requirements and configure an agreed platform, while a vendor controls the product licence, available interfaces and subscription terms. Ask who invoices each component, who can approve changes and who is responsible when a requirement depends on another supplier.

Also distinguish the enquiry-management job from professional funeral work. A proposal to organise planning appointments is not automatically a proposal to replace arrangement contracts, payment reconciliation or required records. Those functions need their own confirmed requirements and operator approval.

Separate the cost components before asking for a total

The categories below are a way to compare offers, not a universal package. A provider may combine some charges, exclude others or leave them subject to assessment. Ask it to state that clearly rather than assuming an unmentioned item is free.

For Canadian budgeting, confirm the currency on every agreement and invoice. Do not assume an international vendor’s displayed dollar amount is CAD. Ask whether applicable taxes are included and how foreign-currency billing, if selected, will affect the amount the business pays. There is no need to assume a particular exchange rate to recognise that uncertainty.

Compare the full agreed term, not just the first invoice or an attractive monthly figure. Monthly billing does not, by itself, establish a month-to-month right to leave. Renewal dates, notice requirements, deposits and payment milestones belong beside the price.

Make migration and connection assumptions visible

“Import your contacts” does not describe whether contact purposes, permissions, opt-outs, attachments or historical notes are included. Nor does it establish that every existing record should be copied into an additional system. The operator must approve the information needed for the agreed purpose and the requirements for retaining material elsewhere.

The quote should distinguish confirmed work from work that depends on vendor access or further assessment. Ask which system controls shared records, what updates are supported and which historical periods or record conditions fall outside the connection. Those details make the quoted responsibility and its limits clear.

Agree who reviews transferred information and what will count as acceptance. A record count alone may not show whether the information staff need is usable or whether contact preferences remain meaningful. Unsupported history, remaining manual work and vendor involvement should be visible before the final implementation commitment.

In Ontario, pre-planning does not necessarily involve prepayment. That distinction matters when a proposal refers loosely to “pre-need customers” or “arrangements”. Ask which records the provider means. An enquiry label is not a signed contract, completed payment or authority to give funeral instructions.

An illustrative comparison: the lower setup fee is not yet the lower commitment

Illustrative example, not actual supplier quotes or a Canada Create client case. An Ontario funeral home wants its current location to have a clearer view of website enquiries. It also wants a quote for adding another location later. Two proposals arrive: Proposal A has a lower initial implementation fee; Proposal B describes a wider initial scope. The missing terms have to be resolved before their prices can be compared fairly.

The owner cannot reasonably call A cheaper overall or B better value from these descriptions alone. A may be sufficient once its scope and continuing charges are clarified. B may include useful work, or work the business does not need. Its more detailed wording does not remove the unresolved vendor dependency.

The next buying action is to ask both providers for a comparable scope and a written commitment for the same term. For A, clarify migration, training and continuing charges. For B, resolve or price the connection dependency and confirm whether the broader work is necessary. Keep the future location as a clearly identified option rather than treating it as already included.

The resulting comparison should let the owner identify confirmed fees, conditional costs and exclusions separately. If a material dependency cannot yet be resolved, a defined assessment may be the appropriate first engagement. It is better to purchase a bounded answer than to approve a complete implementation on an assumption.

Put timing, staff input and acceptance beside the price

A schedule should explain what it depends on. Software access, vendor responses, the condition of existing records and the availability of staff reviewers can affect delivery. Ask which work is confirmed, which work cannot begin until a dependency is met and how a material change would affect the quote.

Your team will need time for decisions as well as training. The operator approves the record purposes, authorised contacts, access requirements and communications. A nominated project contact coordinates business decisions and staff review. These responsibilities should be realistic for the people also handling daily funeral-home work.

Acceptance needs to refer to the commissioned functions. Examples include authorised staff being able to identify the owner of an outstanding enquiry, review the agreed transferred information or use a supported appointment handoff. A completed configuration is different from a promise that families will book more arrangements or that every employee will immediately adopt the system.

Ask what happens if the scope changes. Adding another location, requesting a different vendor connection or expanding historical coverage can be a new requirement rather than a defect. Written change approval helps the business understand the additional fee and schedule before that work begins.

Understand what “support included” means

Software-vendor support, agency implementation support and the operator’s family-response arrangements are separate. A provider should explain which issues it handles, how requests are received, when a person is expected to respond and what is outside the agreement.

Ask the provider to distinguish a defect in delivered work, a later change request, a vendor outage and an urgent family enquiry. Those situations can have different owners and different commercial terms. A support form that accepts requests around the clock does not establish continuous human response or immediate repair.

For Canada Create one-time projects, the Terms of Service provide reasonable handover training and 90 days of limited post-acceptance support to correct defects in the delivered work. Ongoing changes and management need their own agreed scope. Sales and AI-assisted support intake are available 24/7; the standard team-response target is 24 to 48 hours during business days, subject to the Terms. Those targets are not urgent family-care coverage.

Ask separately about staff who join later, refresher training and changes caused by a vendor update. Do not assume that “training included” means indefinite individual onboarding, or that a monthly management fee includes every future request.

Separate access, ownership and a usable exit

Administrator access, the right to use software and ownership of custom work answer different questions. Confirm the named account holder, the access your business receives and the vendor’s export and transition arrangements. A login does not prove ownership of the underlying platform, and an export button does not establish that all records, permissions and attachments will be usable in a different system.

The Office of the Privacy Commissioner’s cloud guidance makes provider contracts, accountability and information handling relevant to outsourcing decisions. The operator should assess permitted access, retention and exit requirements for the selected service. Do not assume unlimited transfer rights or that sensitive professional records belong in an agency’s quote form.

Under Canada Create’s Terms, full and final payment and the continuing agency-credit requirements are conditions of ownership of finalized work created specifically for the client. Third-party materials and pre-existing agency tools are excluded. The Terms provide a non-exclusive, perpetual licence to pre-existing tools as embedded in the deliverables, solely as delivered; they do not transfer the underlying software.

Where included in the engagement, advertising accounts, analytics properties, Google Business Profiles, domains and social media accounts are set up in the client’s name where the platform allows and remain theirs. That named marketing-account provision should not be read as a promise to transfer ownership of a CRM vendor’s platform or provide an unrestricted export.

Before committing, ask whether transition assistance is included, how additional work is priced and which subscriptions or records must remain accessible during a move. Those answers help compare future flexibility without assuming the business will change providers.

Review the complete business commitment

For Canada Create engagements, fees are quoted in writing in CAD unless stated otherwise, plus applicable taxes. The agreement specifies scope, payment schedule and term. The Terms provide that fees and deposits are non-refundable and that all fees for the agreed term remain payable if the client chooses not to continue. Read those conditions before approving the engagement; do not infer an early-exit right from the billing frequency.

These are terms for the funeral home’s purchase of agency services. They are separate from the rights and obligations governing a family’s funeral or prepaid arrangement. A CRM implementation proposal should not blur the two.

For any provider, ask for a written view of the initial commitment and the continuing commitment over the same agreed period. Keep conditional work visible rather than entering an unknown charge as zero. If usage varies, ask what is billed and what information is available to assess it; a made-up allowance would only make the total look more certain than it is.

Consider staff effort alongside supplier charges. The manager’s review time, attendance at training and responsibility for reliable ongoing records are real parts of adoption, even where the agency does not invoice for them. The business should decide whether that commitment is justified by the specific work it wants to improve.

Approve a scope you can describe without the sales presentation

A decision-ready proposal lets you explain the selected platform, the delivered functions, permitted records, staff and vendor responsibilities, acceptance criteria, exclusions and the full agreed commercial commitment. If a material answer is still missing, request it in writing or commission a narrower assessment.

Canada Create’s Funeral Home CRM implementation service starts with your existing tools and enquiry-management requirements. Tell us the locations, software and staff needs the proposal should address. Keep family names, arrangement documents, payment records and passwords out of the enquiry; a written scope and fees follow discovery.

Search has changed in a way most reports still ignore. A homeowner in Etobicoke looking for furnace repair, or a clinic manager in Austin comparing billing services, now often gets an answer before seeing a single website. Google’s AI Overviews summarize the options at the top of the page. AI chat assistants name two or three businesses and explain why. The businesses named in those answers get the call. Everyone else gets impressions.

This guide is for owners and marketing directors in Canada and the US who are measured in booked jobs, not dashboards. It covers what changed, what to measure, what Google and AI systems need before they trust a local business, and how to back every claim on your website so you are worth citing. The goal is simple: get cited in AI search, then turn that mention into a qualified call. If you are in the GTA and want the service side of this work, see what local SEO in Toronto covers.

Why ranking stopped being the finish line

For years the goal was clear: rank in the top three, win the click. That still matters, but a results page now has four places where a local buyer can stop.

Where local buyers stop now

• The map pack, where calls and direction requests happen without a website visit.
• Organic results, still the main route to your service pages.
• Google AI Overviews, which summarize options and name sources at the top of the page.
• AI chat assistants such as ChatGPT, Gemini, Copilot and Perplexity, which shortlist businesses in a conversation.

What a citation is worth

A citation in an AI answer works like a referral. The buyer did not compare ten websites; a system they trust did the shortlisting for them. That shortlist tends to favour businesses with consistent facts, clear service pages and proof that matches across the web. Ranking still feeds the process, because AI Overviews draw on pages Google already considers relevant. Treat traditional SEO as the entry ticket and Google AI Overviews optimization as the next round, not a replacement.

Measure revenue, not visibility

Vanity metrics are easy to grow and easy to report. Impressions, reach, average position and sessions can all rise while revenue stays flat. Before you change a single page, agree on the numbers that decide whether the work is paying.

The five numbers every local SEO report should show

1. Tracked phone calls by source, with call length.
2. Qualified form submissions, with spam, job seekers and vendor pitches removed.
3. Booked jobs or appointments that came from those calls and forms.
4. Cost per qualified lead, by channel.
5. Revenue per channel, even as a range.

If your current report shows none of these, the first fix is measurement, not content.

Separating qualified calls from noise

Not every call is a lead. Set a minimum call length that reflects a real conversation in your trade, tag each call by outcome in your CRM, and listen to a sample every month. One call that books a job is worth more than ten that ask for your hours, and your reporting should show that difference.

The entity signals Google and AI systems trust

Search engines and AI systems describe the world as entities: a business, the services it offers, the places it serves and the evidence that it is real. The clearer those relationships are, the easier it is for a system to name you with confidence.

One name, address and phone everywhere

Your business name, address and phone number should read the same on your website, Google Business Profile, directories, social profiles and invoices. Small differences, such as “Suite 3” in one place and “#3” in another, or an old number on a directory, create doubt. Doubt keeps you out of answers.

A complete Google Business Profile

Choose the most accurate primary category, list every real service, keep hours current, add recent photos of your team and your work, and answer the questions customers actually ask. Our Google Business Profile optimization guide walks through each field.

Structured data that matches the page

LocalBusiness structured data tells search engines your name, address, phone, hours and service areas in a format they read directly. It must match what a visitor sees on the page. Markup that claims something the page does not show weakens trust instead of building it. Google’s own documentation on local business structured data is the plain reference.

Reviews and owner replies

Reviews are evidence written by someone other than you. Ask every satisfied customer, reply to every review with specifics, and handle complaints in public with the same care you would give in private. Do not add review stars to your own site through markup; Google does not show them for a business reviewing itself.

Storefront or service area

A clinic that customers visit and a contractor who drives to job sites are set up differently. Service-area businesses hide the street address and list the cities or regions they serve. Pick the setup that matches how you actually work.

What does it take for a local business to be cited in AI search?

A local business gets cited in AI search when its name, services, location and proof are consistent wherever they appear, its website answers buyer questions directly on clear service pages, and independent sources such as reviews, directories and local media confirm the same facts. AI systems repeat what they can verify.

Six steps make a business citable:

1. Make your core facts identical across the web: name, address, phone, hours and services.
2. Build one page for each real service, and name the city or region you serve in plain words.
3. Answer the main buyer question in the first 40 to 60 words of each section, then expand.
4. Describe the business and its services with structured data that matches the visible page.
5. Earn independent confirmation: reviews, industry associations, local news, supplier and partner listings.
6. Show the people behind the work: named authors, credentials, licence numbers and real project photos.

Think of it as a chain a machine can check: business → offers service → in a place → proven by evidence. A Scarborough plumbing company that offers drain camera inspections across Scarborough and Pickering, lists the licences it holds, and has reviews mentioning drain work by name gives every link in that chain something to confirm. For the content-editing side, see how to get your business cited in AI search answers.

Lead generation websites: turning a visit into a call

A buyer who arrives from an AI answer has half made the decision. Your page then has a few seconds to confirm it. The best lead generation websites in Toronto, and anywhere else, share four habits.

Fast and stable on a phone

Pages should load quickly on mobile data and not jump while loading. Google’s Core Web Vitals measure exactly this, and you can check any page for free in Google’s PageSpeed Insights.

Click to call where the eye lands

Put a tap-to-call number in the header and in the first screen of every service page, next to your hours. A buyer ready to call should never have to scroll to find out how.

One page per real service

A single services page that lists everything cannot answer specific questions. Give each real service its own page with its own proof, and avoid two pages chasing the same search; they compete with each other instead of with your competitors.

Forms that qualify

Ask for what you need to quote: the service, the location and the timing. Every extra field costs you some submissions, but the right fields save your team hours of back and forth.

Proof you can stand behind: the message-evidence matrix

Every claim on your website is either backed by evidence or a liability. A message-evidence matrix is a simple table that keeps the two connected. Build it before you write or rewrite a page.

If you cannot fill the evidence column for a claim, rewrite the claim or remove it.

Feed E-E-A-T with raw data from your business

Experience, expertise, authoritativeness and trustworthiness are not added by a writer after the fact. They come from the business. Give whoever writes your pages:

• Real numbers you can stand behind, such as jobs completed in a season or typical turnaround times.
• Original photos of your team, vehicles and finished work, with written permission from anyone identifiable.
• Licence, registration and association numbers.
• The questions customers ask on the phone, in their own words.
• A named author or reviewer for each page, with a short bio.

Keep a human editor in charge

AI writing tools can speed up drafting, but they also state invented facts with confidence. Every page should be read and approved by someone who knows the work before it goes live, and reviewed again whenever prices, services or staff change.

Calibrating for Toronto and for US markets

Toronto and the GTA

Demand in the GTA is local down to the neighbourhood. A buyer in Scarborough, North York or Mississauga often searches with the neighbourhood name, and map results reflect distance. Name the areas you truly serve on pages that show work there, rather than listing every city in a footer. The GTA is also multilingual: if your team serves customers in Farsi, Mandarin, Punjabi or Tagalog, say so, and offer pages in those languages written by fluent speakers.

Canadian rules worth knowing

Write Canadian pages in Canadian English. Follow-up emails and texts to leads fall under Canada’s Anti-Spam Legislation (CASL), which requires consent, clear sender identification and a working unsubscribe option.

Serving US buyers too

US searches often use state and county names, US spelling and different licensing terms. If you serve both countries, give each market its own pages rather than one page trying to speak to both.

How to choose a Canadian digital marketing agency

If you hire help, judge any agency, including ours, by its answers to these questions:

• Which numbers will you report each month, and can I see a sample report?
• How do you track calls and separate qualified leads from noise?
• Who writes the content, and who checks the facts before it goes live?
• Will the website, profiles and ad accounts be in my business’s name?
• What will you need from me each month?

An agency that answers in impressions and rankings alone is selling visibility. Look for one that answers in calls and booked work.

Frequently asked questions

Is local SEO still worth it if AI answers the question?

Yes. AI Overviews and AI assistants draw on the same signals local SEO builds: consistent business facts, clear service pages, reviews and independent mentions. Strong local SEO is what makes a business eligible to be named.

How long does it take to show up in AI answers?

It depends on how consistent your facts already are and how competitive your area and trade are. Fixing business data and profiles comes first; content and reviews build over the following months.

Do I need separate pages for AI search?

No. The same well-organized service pages serve Google’s results, AI Overviews and AI chat assistants. What changes is how directly each page answers the buyer’s question.

Can I track leads that come from AI assistants?

Partly. Some visits show up in analytics as referrals from AI assistants, and many do not. Ask every caller how they found you and record the answer in your CRM.

See where your website is losing calls

If your reports show more visibility than revenue, start with a clear picture of where calls are being lost. Claim your free website SEO audit to see what is helping your site and what is holding it back, or get a proposal in one business day.

Call our 24/7 sales and support line toll-free at +1 (800) 808-9235, or (416) 273-9030 in Toronto.

A cheap lead from a search for your company name can be useful. It does not tell you whether the person needed the ad to become a customer.

Before cutting or defending that spend, define the change you are considering and the business outcome that would justify it. Then ask whether you can compare brand advertising with a credible alternative in which the selected ads are withheld. If you cannot, a pause may still produce observations, but it will leave important explanations unresolved.

This guide follows Ternbridge, a fictional Toronto company selling purchasing-approval software, through that decision. Its company details, reports and amounts are invented teaching examples. No advertising account was inspected, no campaign was changed and no lift study was run. The examples do not describe Canada Create clients or recommended budgets.

The question is about advertising on your own brand. If you are considering searches for another supplier, use the separate SaaS competitor-keyword guide.

Both routes end at the same product. Seeing which route a visitor used leaves open whether that visitor would have arrived under the alternative advertising policy.

Read the diagram

One buyer. Brand ad or organic result. Both lead to Ternbridge. What changes without the ad? The observed route alone cannot answer that question.

The report that starts the argument

Ternbridge’s growth lead brings a campaign report to finance. Brand Search has the lowest reported cost per demo. Finance asks why the company pays for visitors who already know its name. Sales worries that removing the ad will send buyers elsewhere.

Each person has a reasonable concern. They are asking different questions.

The growth lead is describing attributed results: outcomes credited to advertising under the account’s measurement rules. Finance wants to know what the advertising added. Sales is concerned about the route a buyer takes when returning to the product. One attractive campaign ratio cannot settle all three.

A brand search can follow a recommendation, a product demonstration, an event or a month of research. An ad might make the next step easier. It might help someone find the right page. It might also receive credit for a visit that would otherwise have reached an organic result. The visible journey does not reveal which alternative would have occurred.

Nor does a strong organic listing settle the matter. The results page, other advertisers, the person’s intent and the destination offered can all affect the visit. Seeing your company near the top once is a weak basis for a permanent spending policy.

Growth, finance and sales are looking for different kinds of evidence. Agree whether the spending decision concerns credited demos, additional new business or a dependable customer route before choosing a metric.

Read the diagram

Growth: credited demos; what got credit? Finance: additional demand; what did ads add? Sales: customer navigation; how do buyers return? Choose the question that will decide the spend.

Ternbridge replaces “Are brand ads worth it?” with a more useful question: “Would withholding our defined own-brand Search advertising materially change qualified new-business demand in the market we can test?”

That question leaves room for several outcomes. The ads could add valuable demand. The available evidence could support reducing the selected spend. The study could be too imprecise to decide. Or the company could discover that its original concern is customer navigation rather than acquisition.

Write down which decision is yours. A team paying for a dependable route to an urgent customer service has a different objective from a software company trying to acquire new accounts. Keep any navigation or customer-experience objective visible instead of claiming that every credited conversion represents new demand.

What would you actually stop?

The campaign named “Brand” is a convenient starting point. Its name does not define all the advertising a person might encounter after searching for your company.

Ternbridge lists its company name, product name and common variations. It separates product-evaluation searches from account-access and support requests where the available wording allows that distinction. Ambiguous terms stay ambiguous. A short product name can also have an ordinary meaning unrelated to the company.

Then the account owner checks where that traffic can be served. Another Search campaign or an automated campaign may still reach relevant brand demand. If the proposed test pauses one named campaign while another takes over, the change concerns routing and delivery across campaigns. It may not create the intended no-brand-ad comparison.

The red boundary marks the selected own-brand Search exposure. Other campaigns remain visible because their ability to reach the same demand must be checked when defining the comparison.

Read the diagram

Selected own-brand Search. Define campaigns and brand terms, products, country and study population. Other campaign routes may still serve relevant brand demand.

Google provides brand controls for Search and Performance Max, but their scope depends on the campaign and setting. Its brand-exclusion documentation describes inventory-specific behaviour, including options affecting Shopping. Do not interpret a brand-exclusion label as a switch that removes every possible exposure everywhere.

For Ternbridge, the proposed scope is deliberately narrow: its own-brand Search advertising in a defined country and study population. Category advertising, sales outreach and ordinary product availability remain part of the background. The study would estimate the effect of the selected advertising within that environment. It would not measure the value of every marketing activity or the brand itself.

Record the boundary in a short account map:

• Which campaigns and brand terms belong to the proposed change?
• Which other campaigns might still serve relevant demand?
• Which products, countries and customer groups are included?
• What will remain active, and why?
• Who will verify that the saved settings produce the intended exposure?

A closed gate in the campaign named Brand does not close every advertising route. Check whether another eligible campaign would deliver an equivalent exposure before treating the intended holdout as unexposed.

Read the diagram

Named Brand campaign: paused. Other eligible campaign: may still serve. Both concern the same buyer. Verify the intended absence of selected ads.

Resolve a known mismatch before treating the plan as ready. If a buyer would still see an equivalent ad through another campaign, either include that delivery in the defined scope or explain the narrower question you can answer. Do not quietly call the group unexposed.

The existing search-terms guide covers query review. Here, the purpose of that review is to define the treatment, not to build a longer keyword list.

Decide whose outcome counts

Ternbridge sells to organizations. Three employees from one prospective customer can attend separate demonstrations and submit several forms before procurement approves anything.

Counting every form as new demand would make the outcome sensitive to how those employees return. One might click a brand ad, another might use a saved link and a third might search organically. If the ad is withheld, a different route could collect the credit while the same prospective customer continues its evaluation.

The team therefore defines a qualified new-business organization for this example: one previously unqualified prospective customer that meets its agreed product-fit and active-evaluation criteria. Repeated contacts belong to that organization. Existing customers seeking support are recorded separately. These are Ternbridge’s fictional definitions, not universal sales stages.

Repeated contacts are grouped under the same prospective organization when they meet the agreed qualification definition. Existing customers asking for support stay in a separate outcome category.

Read the diagram

Three contacts and repeated forms converge to one qualified new-business organization. Existing-customer support is a separate outcome.

For a geographic design, the analyst also needs an outcome that can be assigned to the study’s regions under a consistent rule. A form’s office address, an account’s headquarters and the location where someone encountered an ad are different pieces of information.

A national company’s buying committee makes this particularly important. Its finance lead may work in Toronto, its evaluator in Calgary and its procurement team elsewhere. Assigning the opportunity to headquarters does not prove that all relevant advertising exposure happened there. The design needs to assess that mismatch rather than hide it in a tidy map.

Use only the information the business is permitted to collect and analyse. The worksheet accompanying this guide needs definitions and aggregate checks, not customer names or raw contact details. More intrusive tracking is not the automatic answer to an uncertain location.

For the business-outcome analysis, preserve the relevant total across acquisition routes. A record should not disappear simply because it no longer receives paid-search credit. Keep unknown geography, unresolved duplicates and incomplete qualification visible, with their consequences for the analysis.

Carry the counted business unit, qualification rule and geographic assignment into the aggregate analysis. An unresolved location stays visible as unknown rather than being guessed into a region.

Read the diagram

Counted unit: one organization. Qualification: agreed definition. Geography: consistent rule, with unknown location kept separate. Aggregate: preserve the relevant status.

Ternbridge can report qualified organizations sooner than signed customers. That may make the first outcome more informative within a feasible study. It also limits the eventual claim: an increase in qualified organizations would not establish the same increase in contracts or contribution.

If CRM definitions or imports are unreliable, use the Google Ads and CRM mapping guide to address that prerequisite. Changing the reporting model cannot repair a missing business definition.

Read paid and organic numbers together

The growth lead’s first proposal is to pause brand ads for a period and see whether organic traffic takes over. That can expose a useful pattern. By itself, it cannot isolate the advertising’s effect from everything else that changed over time.

Consider this separate, fictional pair of equal-length reporting periods. Assume the same defined brand-query scope and compatible click definitions are available in both.

Paid clicks decrease by 65 while organic clicks increase by 65, leaving the same combined total. These equal-length, fictional reporting periods describe a change in route mix; they do not isolate its cause.

Read the diagram

Period A: 90 paid plus 110 organic equals 200 clicks. Period B: 25 paid plus 175 organic equals 200 clicks. Paid change: minus 65. Organic change: plus 65. Clicks are not unique people or causal business outcomes.

Paid clicks fall by 65 and organic clicks rise by 65. Combined clicks remain 200. The qualified-organization count falls by one, about 1.61% of the original 62.

Those calculations are descriptive. The click rows do not count unique people. The organization row covers a different business population across acquisition routes, so dividing it by the 200 branded clicks would not produce a valid conversion rate. The table does not connect individual clicks to organizations or establish what caused the difference.

Perhaps demand changed between the periods. Perhaps a product announcement affected branded searches. Perhaps another campaign picked up some exposure. Even with a perfectly reconciled report, the missing counterfactual remains: what would the same business have experienced during period B under the alternative advertising policy?

The all-route qualified-organization count declines from 62 to 61, a difference of one. That business population is separate from the branded-click population, so dividing organizations by the click total would not give a valid conversion rate.

Read the diagram

Reporting period A: 62 qualified new-business organizations across acquisition routes. Period B: 61. Demand and product changes remain possible explanations. The outcome under the alternative advertising policy is unobserved.

Google’s paid and organic report can help review text-ad and organic visibility together. It requires a Search Console connection, and organic history begins when that data starts being imported. Organic results are not restricted by the ad campaign’s geographic targeting, so apparently aligned rows can cover different reach.

Use that report to investigate how people find the site. Do not treat it as a causal sales report. Likewise, changing attribution models reallocates credit among observed interactions; it does not reveal which customers would have vanished without an ad. The attribution-model guide explains that separate reporting task.

Ternbridge keeps the pause-and-compare proposal as an observational option if no stronger design is feasible. It stops calling it proof before the design has earned that description.

Choose the comparison before touching campaigns

A familiar Google Ads experiment may compare two bidding approaches while both groups continue to receive advertising. That can answer a bidding question. The own-brand question needs a design that can withhold the selected exposure from a suitable comparison group.

Google documents user-based and geographic Conversion Lift approaches. Access is not universal, and supported campaign types, conversion requirements and study conditions differ. The user-based setup guidance is a separate reference from the geographic route. A feature described in documentation is not evidence that Ternbridge, or your account, can use it for the exact proposed scope.

The current geographic Conversion Lift documentation includes Search among supported campaign types, requires single-country campaigns and provides a feasibility review. It also directs advertisers to their Google account representative regarding access. Confirm those details for the actual study instead of borrowing eligibility from an unrelated campaign.

Changing a bid strategy while both groups receive ads answers a different question from withholding selected brand exposure. The comparison must match the actual policy the business is considering.

Read the diagram

Bid strategy comparison: strategy A with ads on versus strategy B with ads on. Selected-ad holdout: ads on versus selected ads withheld. Different questions require different exposure.

A specialist-designed geographic experiment is another possible route. Google’s primary geo-experiment research describes assigning non-overlapping regions to conditions and implementing those conditions through geographic advertising. The research establishes a methodology to investigate; its existence does not validate an improvised regional comparison.

Ask the person designing the study to explain three things plainly: what is assigned, what differs between the groups, and how the measured outcome supports the business question. They should also be able to explain where contamination, missing data or ordinary variation could weaken the answer.

Verify the account, outcome data and proposed question before choosing a route. An available platform feature or a specialist proposal still needs to be suitable for this specific comparison.

Read the diagram

First verify access, data and the study question. Possible routes: native study if eligible and suitable; specialist-led geographic study if feasible; defer or revise when evidence would be insufficient.

For Ternbridge, a study that withholds the defined brand advertising is relevant. A study that merely replaces the bid strategy in half the traffic is a different proposal. A study covering all Search spend is broader than the agreed brand question. Either broader proposal might be worthwhile, but it needs its own rationale and spending decision.

Do not select a method solely because it is available in a menu. Establish whether it can answer the question with the account’s campaigns, outcome data and operating constraints. The existing campaign-experiment guide covers ordinary supported comparisons without pretending they all create an advertising holdout.

Make the geography fit the question

Ternbridge is based in Toronto and sells across Canada and the United States. Someone suggests turning brand ads off in Canada while leaving them on in the US.

That would change advertising in two markets with different demand, competitors, customer mixes and business conditions. Calling one the control does not make those differences disappear. A national before-and-after comparison may help describe what happened; it does not become randomized evidence by using two countries.

For the geographic platform route described above, single-country scope is also an eligibility condition. Ternbridge starts by assessing a Canadian design and would evaluate a US study separately. The company’s office address does not determine the only useful test population, but neither does international reach guarantee enough suitable regions.

Ternbridge’s Toronto headquarters identifies the company location, not a control group. Assess a candidate Canadian study within one country and evaluate US work separately instead of assuming the countries are comparable.

Read the diagram

Toronto headquarters: company location. Canada: candidate single-country study. United States: assess separately. Countries are not a ready-made control.

A regional design needs more than two similar-looking totals. The analyst should examine pre-study behaviour, outcome frequency, concentration in a few large accounts and the relationship between regions. A region dominated by one unusual contract can behave very differently from another with many smaller opportunities, even when their totals match.

Ask what historical evidence supports the comparison and what the method assumes. How were regions selected or assigned? Can the outcome be measured consistently there? What size of business effect could the design reasonably distinguish within the proposed exposure? Those answers should precede the campaign edits.

A company serving only a small local area may lack a useful geographic design. A national SaaS company may also struggle if its buying committees span regions or qualified outcomes are sparse. Neither situation is fixed by drawing smaller polygons until the spreadsheet has more rows.

A buying committee can connect several regions while producing only one organization-level outcome. Adding map tiles does not create independent observations or solve sparse outcomes.

Read the diagram

One buyer organization. Committee spans region boundaries. Sparse outcomes. More tiles do not create independence.

The practical outcome can be a no-go decision on the proposed study. Ternbridge’s team would rather learn that the design is weak before withholding advertising than spend weeks collecting data that cannot settle the argument.

If the best feasible evidence remains observational, label it accordingly. The business can still combine those observations with costs, operational needs and a cautious spending policy. It should not present the resulting judgement as a measured causal effect.

Check what could cross the boundary

Imagine the account map looks clean: one set of regions retains the selected brand ads and another has them withheld. The next question is whether delivery and business activity will actually respect that plan.

One risk is substitution through another campaign. A second is budget movement. If withholding spend in some places causes a shared or constrained budget to be spent more aggressively in comparison regions, the comparison has changed in two ways.

Google’s geo-experiment implementation guidance specifically discusses budget redistribution in go-dark designs and separating campaign resources across experimental conditions. This makes budget behaviour part of study design, not a bookkeeping task to inspect only after a surprising result.

Withholding selected exposure can change where a shared budget is spent. Review delivery and spending together so the comparison does not silently include greater advertising elsewhere.

Read the diagram

Shared budget connected to selected exposure and other campaign activity or comparison regions. Redistribution is a potential mechanism, not a measured flow. Verify how spending actually behaves.

People and buying groups can cross the boundary too. Someone may see an ad while travelling and convert from another region. Colleagues may share a product link across offices. The geographic lift documentation discusses contamination between experimental areas. Actual exposure and outcome mapping deserve review even when the location settings were saved correctly.

Ternbridge adds a short integrity plan. The account owner checks whether the intended campaigns serve in the intended places. The analyst checks outcome completeness and geographic assignment. Sales records material changes in qualification or availability. Marketing logs promotions and product announcements that might affect regions differently.

Keep campaign delivery, outcome coverage and material incidents in the same review process. Fix a customer-facing fault when necessary, then record what changed and assess the effect on the study.

Read the diagram

Campaign delivery: actual ad exposure. Outcome coverage: complete, assigned records. Material incidents: fix, log and review impact.

This is not an invitation to continually improve only the advertising-on group. Routine changes can alter the comparison. If a customer-facing fault requires correction, fix the problem and document its effect on the study rather than preserving harm for experimental neatness.

The initial plan should also identify the ordinary operating state to restore after the study. Paused placeholders, duplicated campaigns, exclusions and temporary budgets can otherwise become an accidental long-term setup.

Agree the campaign changes, budget limits and verification steps with the account owner before implementation. The planning deliverable should make the proposed change and its boundaries clear.

Set the evidence and spending conditions together

Ternbridge’s finance lead wants to know how much uncertainty the business is paying to reduce. That question belongs before launch.

Begin with the decision’s scale. Is the company considering a modest adjustment to one campaign, or removing a substantial part of its acquisition program? What loss of useful demand would make the change unacceptable? What improvement would be large enough to justify implementation and ongoing administration?

Those conditions come from the business. A universal percentage or fixed test budget would ignore customer economics, outcome frequency and the consequences of a mistake.

The business sets the acceptable demand loss, the effect worth acting on and the cost it will bear to learn more. Those commercial limits guide the design but do not themselves establish statistical precision.

Read the diagram

Agree before launch: acceptable demand loss; useful effect size; cost of learning. Commercial limits and statistical precision are separate inputs.

Then ask whether the proposed method can answer at that level of precision. A long record of clicks does not necessarily supply enough new qualified organizations. Replacing the primary outcome with page views may make the report fill faster while abandoning the decision that mattered.

Ternbridge can use qualified organizations as a nearer-term business outcome if the team agrees that this answers a narrower question. It would still need separate evidence or a clearly labelled model to connect that result with signed customers. A historical close rate is an assumption when applied to additional opportunities; it is not a guarantee about them.

The analyst should state the planned analysis and uncertainty standard before reviewing the preferred result. If the platform provides feasibility or study-power information, preserve its definition and limitations. A favourable feasibility estimate is not an assurance that the ads will produce positive lift or that the final answer will justify their cost.

A large volume of clicks can coexist with too few qualified organizations to inform the chosen decision. Assess feasibility for the business outcome and keep the question intact if measurement needs revision or the study must be deferred.

Read the diagram

Many clicks measure activity volume. Qualified organizations are the chosen business outcome. Assess feasibility: feasible, revise measurement or defer. Keep the business question intact.

Agree on the exposure boundary, financial limits, planned end state and incident conditions. Stopping further exposure and completing outcome analysis may happen at different times. A tracking failure might invalidate part of the study without revealing whether the campaign was valuable.

Do not extend a fixed-horizon study repeatedly until it produces the desired label. Any extension needs a defensible analysis approach and a fresh assessment of the value and cost of more information. Ending with an unresolved answer can be preferable to paying indefinitely for precision the available design cannot provide.

Know when the outcomes are ready

Brand searches often occur late in a buying journey, but that does not mean every associated opportunity is ready to classify when the ad stops serving.

For Ternbridge, a product evaluator may return to a pricing page, request a technical review and take weeks to reach procurement. A demo completed yesterday can be a genuine step without yet being a qualified organization or a signed customer under the chosen definition.

Separate the period when advertising differs from the period needed to observe the relevant outcomes. Record the date basis used by each report and how pending cases will be handled. Keep those rules consistent across the comparison.

The selected advertising exposure may end before evaluations and procurement decisions are ready to classify. Use the same outcome definition and observation rule across the comparison.

Read the diagram

Ad-exposure track ends. Outcome-observation track continues through evaluation to classification under the agreed rule. The groups use the same rule and observation period.

Google’s conversion-lag guidance explains why recent acquisition-cost or return figures can change as conversions arrive. Use the account’s relevant history and the study method rather than importing a universal waiting period. A mature platform conversion count can still be an immature sales result if the measured action happens much earlier than qualification.

If a lift report includes modelled or projected outcomes, label them as such. Do not quietly combine an estimate of future conversions with realized contracts and call the total completed business. Google’s user-based lift reporting guidance describes projected delayed outcomes for particular study types. Check the selected method’s definitions rather than assuming every lift report handles the delay in the same way.

Ternbridge’s review packet has three status labels: observed and ready under the agreed definition; pending; and unresolved because data are missing. Pending is not the same as lost. Missing is not the same as zero.

Separate outcomes that are ready under the definition from those still pending and those unresolved because data are missing. These statuses affect what can be concluded and should not be collapsed into losses or zeros.

Read the diagram

Observed and ready. Pending is not lost. Missing is not zero. Keep the original cohort and agreed classification rule.

The original cohort also stays intact. A later contract from an earlier evaluation should be handled under the agreed observation rule, rather than moved into a new period merely because that produces a cleaner comparison.

This discipline prevents an apparently decisive result from depending on who was given more time. It also lets leadership receive an operating update while the final business conclusion remains open.

Read the result before calculating a return

When the study ends, start with what was actually implemented. Did the selected advertising differ as intended? Did the outcome records remain complete enough for the analysis? Did a regional promotion, outage or campaign change materially alter the comparison?

An analysis can be mathematically correct for data that no longer answer the original question. Resolve that issue before celebrating the result.

The report should identify the outcome, population, period, estimated effect, uncertainty and important assumptions. Google distinguishes incremental results from ordinary attributed conversions in its Conversion Lift measurement documentation. The campaign’s credited total is not an interchangeable substitute for the study estimate.

Read the result as a complete packet: what was measured, where and when, how large the estimate is, how uncertain it is and which limitations matter. The campaign’s attributed total belongs to a separate reporting field.

Read the diagram

Result packet fields: outcome; studied population; period; effect estimate; uncertainty; assumptions and limitations. Attributed conversions remain separate. No result values are supplied in this planning diagram.

A positive estimate with wide uncertainty can leave both a worthwhile benefit and an uneconomic result plausible. A narrow estimate can still be too small to matter commercially. Evidence consistent with little effect does not automatically establish exact equivalence, especially if the study was incapable of detecting the difference the business cares about.

Do not manufacture a confidence interval from two aggregate totals or borrow a platform’s confidence label for a different outcome. If the primary report measures form events and a separate analysis measures qualified organizations, the latter needs an analysis appropriate to its data and assignment.

For a geographic study, unequal region size, pre-period relationships and the chosen estimator can affect interpretation. Simply subtracting one region’s raw total from another is not a universal lift calculation. Ask the analyst to make the result understandable without hiding the method or replacing it with a homemade shortcut.

A valid comparison can still leave the commercial decision unresolved because precision is insufficient or the effect is too small to matter. An invalid comparison belongs outside that interpretation matrix and needs redesign, regardless of precision.

Read the diagram

Commercial relevance and evidence precision are separate dimensions for interpreting a valid comparison. An invalid comparison leads to redesign; greater precision cannot repair it. No plotted position is a measured Ternbridge result.

“The study could not resolve our commercial threshold” is a different statement from “brand advertising contributes nothing.” Likewise, “the tested ads increased the measured outcome in this setting” does not establish that every future brand campaign should receive unlimited spend.

Work out what the additional customers would need to earn

Before seeing a result, Ternbridge can make its economic question explicit without pretending to know the answer.

Consider a separate fictional planning scenario for a defined acquisition period. Keeping the selected advertising would cost CAD 18,000 in media plus CAD 4,500 in other campaign costs that would genuinely change with that policy. The total incremental cost being considered is CAD 22,500.

Assume an additional acquired customer would contribute CAD 7,500 over its first 12 months after the direct delivery costs included in the example’s definition. That contribution excludes the CAD 22,500 campaign costs, which are deducted separately. All figures are assumptions for teaching, not observed Ternbridge results, pricing benchmarks or a forecast.

Include the costs that genuinely change between the advertising policies. The example adds media and other changing campaign costs; unchanged allocated overhead and the one-time cost of the study are considered separately.

Read the diagram

CAD 18,000 media plus CAD 4,500 other changing campaign costs equals CAD 22,500. Unchanged allocated overhead and one-time study costs are outside this policy-cost example.

The calculation is straightforward: CAD 22,500 divided by CAD 7,500 is three additional customers to cover the included campaign costs. Three produces break-even under these assumptions, not a desirable return. The business may require more to compensate for risk and other demands on its resources.

The difficult input is additional customers caused by the advertising. Attributed customers cannot simply be inserted into that column. Nor can an incremental qualified-opportunity estimate become a customer count without a further assumption about conversion to contracts.

Each assumed additional acquired customer contributes CAD 7,500 in the first year before the included campaign costs. Three cover CAD 22,500 exactly; four leave CAD 7,500. Attributed customers and qualified organizations cannot be substituted for this causal customer input.

Read the diagram

Assumed additional customers and contribution less CAD 22,500: zero, minus CAD 22,500; one, minus CAD 15,000; two, minus CAD 7,500; three, CAD 0, break-even; four, plus CAD 7,500. These are conditional scenarios, not forecasts or study estimates.

Keep the horizon consistent. First-year contribution cannot be compared casually with lifetime revenue, and an annual contract value says little by itself about delivery cost or cash collection. The ROAS and ROI guide covers those financial definitions more fully.

Have finance distinguish avoidable costs from allocated overhead. If the company would pay the same management fee after reducing one brand campaign, that fee is not automatically a saving from this particular decision. If a study needs a one-time analysis project, that is a cost of obtaining information and should be evaluated separately from the ongoing policy comparison.

The threshold is sensitive to assumptions. If first-year contribution were CAD 6,000 instead, CAD 22,500 would require 3.75 customers in the arithmetic, meaning at least four whole customers to cover the stated costs. Four would leave CAD 1,500. This does not predict four wins; it shows why finance must review the contribution assumption before an impressive-looking lift estimate becomes a budget recommendation.

Lower contribution per customer raises the threshold while campaign costs stay fixed. At CAD 6,000, the arithmetic requirement is 3.75 customers, so four whole customers are needed to cover the stated costs and leave CAD 1,500.

Read the diagram

CAD 22,500 costs. At CAD 7,500 first-year contribution per additional customer: threshold three and whole-customer requirement three, leaving CAD 0 at three. At CAD 6,000: threshold 3.75 and whole-customer requirement four, leaving CAD 1,500 at four.

Make the decision the evidence can support

Ternbridge’s initial meeting began with a cheap brand-demo report and a proposal to pause advertising. It ends with a more specific plan and several limits the team can explain.

The company has defined the brand-Search exposure it wants to evaluate, separated new-business organizations from repeat contacts, and rejected Canada-versus-US as a ready-made controlled comparison. It has a proposed economic threshold, while recognizing that a study of qualified organizations would not directly establish additional customers.

The next decision is whether the actual account, regional data and outcome frequency can support the chosen study. Until that feasibility work is complete, the fictional team has no measured basis for declaring the brand campaign essential or unnecessary. Any interim spending policy remains a business judgement made under uncertainty.

Ternbridge has made the spending question more precise and rejected a premature causal conclusion. Its next decision is whether the actual account, geographic data and outcome frequency can support a useful study.

Read the diagram

Defined: selected brand-Search exposure and qualified new-business organizations. Rejected: Canada versus US as a ready-made control. Open: account and study feasibility, and the eventual result. Next: feasibility before a campaign-value verdict.

Your eventual action should follow the evidence:

• Keep the defined policy when the relevant result and economics support it, preserving the limits of the tested market and period.
• Reduce or remove the selected spend when a defensible analysis supports that choice and the business accepts the customer-journey consequences.
• Redesign the study when exposure leakage, outcome definitions or unsuitable comparisons prevented an answer.
• Retain an explicitly provisional policy when no feasible study can resolve the decision at an acceptable cost.

Avoid combining the result with several untested changes. Cutting brand advertising, doubling category spend and rebuilding the landing page together creates a new operating policy. It may be a sensible proposal, but the original test does not automatically validate the package.

After any authorized change, check the resulting account state and the relevant business outcomes. Temporary experiment settings should not remain active by accident. Record what was restored, what was adopted and which later changes would make the original finding less relevant.

Finish an authorized change by checking the resulting account configuration. Record what was restored, what was deliberately adopted and what still needs resolution so temporary settings do not become a permanent policy by accident.

Read the diagram

Review temporary configuration, including paused placeholders, exclusions, budgets and duplicate campaigns. Restore, adopt or resolve deliberately. Verify the final account state.

A short decision note is enough if it contains the important facts: what changed in the comparison, what was measured, what the result supports, what remains uncertain and what the business has chosen to do. Keep the supporting analysis available. A permanent rule such as “always bid on brand” or “never pay for brand” throws away the conditions that made the evidence useful.

The accompanying brand-spend worksheet helps prepare that discussion without connecting an account. Use it to establish the question and missing evidence, rather than treating completed boxes as proof that a study is valid.

Download the brand-spend decision kit (ZIP) or the printable worksheet (PDF). The kit includes an editable worksheet and the guide’s static teaching examples.

Attach the spending choice to the tested exposure, measured outcome, supported finding and remaining uncertainty. Keep the market and period boundaries visible when deciding whether later circumstances justify a new review.

Read the diagram

Decision note: what changed; what was measured; what the evidence supports; what remains uncertain; what policy was chosen. Preserve the supporting analysis and the limits of the tested setting.

If your team needs help separating brand-campaign reporting from a defensible spending decision, start with Canada Create’s Google Ads service. Bring the campaign scope, outcome definitions and the decision you need to make. Custom-scoped engagements; proposal after discovery.

Set the ISO 27001 scope around the information and activities your organization needs to manage. Then explain how that boundary works across products, legal entities, locations, supporting functions and external providers. The result should let engineering, management and the certification body discuss the same business.

This guide takes you through that decision. It is written for Toronto-based SaaS and AI teams serving enterprise and institutional customers in Canada and the United States. You will build a boundary register, test proposed exclusions and turn the findings into a scope document that remains useful when the company changes.

The running example, Maple Quay Analytics and its Harbour platform, is entirely fictional. Its companies, architecture, records and decisions illustrate the method; they are not client evidence or a pre-approved certification design. The worksheet is a planning aid to use alongside the licensed standard and advice appropriate to your organization.

Separate the boundary decision from the certificate wording

ISO/IEC 27001 sets requirements for an information security management system, usually shortened to ISMS. The management system connects leadership, risk decisions, operating processes, evaluation and improvement. It is broader than a security-tool inventory. ISO's current catalogue lists ISO/IEC 27001:2022 and its 2024 climate-action amendment. Establish the applicable edition and amendments when you begin the work.

Three related records serve different readers:

• The internal scope document explains the ISMS boundary and its basis. It can refer to controlled inventories, diagrams, entity records and dependency decisions.
• The certification application gives the certification body the facts it needs to understand the proposed engagement, including organizational structure, activities, locations and relevant personnel.
• The certificate communicates the certified coverage in the form issued by the certification body. Its wording and any attached schedule need to match the certification actually granted.

You can draft an internal boundary before certification. Do not describe that draft as an approved certificate scope or start using it as a certification claim. ISO explains that external certification bodies perform certification; ISO itself does not issue certificates.

A short public statement may point to a much richer internal record. That is useful: customers need understandable coverage, while operational owners need enough detail to decide whether a new support tool, subsidiary or environment changes it. Trying to force every asset identifier into one sentence usually makes both tasks harder.

Keep scope separate from control selection, too. A scope defines the activities and boundaries the ISMS addresses. The risk assessment and treatment process determine the necessary controls; the Statement of Applicability records the relevant control decisions and their justification. BSI's implementation guide describes those connected activities. Removing a business activity from the boundary and deciding that a particular reference control is unnecessary are different decisions.

Write down the business outcome the scope must support

Before debating systems, write a plain-language purpose for the ISMS. Record the relevant internal and external issues, interested-party requirements, and interfaces with activities performed by other organizations. Identify the service, the information involved, the interested parties and the requirements the management system needs to address. Customer requests matter, but so do the organization's own objectives and the requirements its responsible advisers identify.

For Maple Quay, the initial purpose is to manage information security for the design, delivery and support of Harbour, an analytics service used by logistics organizations. Harbour receives operational records, produces dashboards and offers an AI-assisted summary feature. Its buyers want to understand the security management behind that service.

The commercial team should collect the actual request. Does a prospect require a certificate covering Harbour's operation? Does it name the contracting entity? Will it use a dedicated environment? Is its procurement team asking about Canadian hosting, US support access, or both? Those questions can produce different work even when the email contains the same phrase, “ISO 27001 required.”

Create a requirements record with five fields: requesting party, requirement, affected activity or information, responsible interpreter, and evidence of the agreed interpretation. Keep an uncertain requirement marked as a question until the appropriate person resolves it. A sales assumption should not quietly become the basis of a certification project.

Separate information-security scope from legal applicability. A scope document cannot decide which privacy law applies, remove a contractual obligation, or demonstrate that every customer requirement has been met. Record relevant obligations through your legal, privacy and contract owners, then show where the ISMS addresses the information-security work they identify.

The practical output is a sentence and a short set of traceable requirements. If the proposed boundary cannot support that purpose, changing the wording will not repair it. Reconsider the boundary or the business commitment before building the rest of the program.

Establish one factual operating picture

Maple Quay Analytics Inc. is based in Toronto. Its US subsidiary, Maple Quay Support LLC, provides remote support for Harbour. A Canadian cloud region hosts the application and its recovery copies. Approved personnel in Canada and the US can access designated support functions. A separate external model provider processes selected operational records to generate the optional summaries.

The company also runs an unrelated research pilot called Tide. Tide is proposed for exclusion from the Harbour ISMS boundary. Whether that proposal is supportable depends on evidence about its data, identities, release paths and shared resources. Its name, budget and experimental status settle none of those questions.

Start with the current operating picture, then show planned changes separately. A future US hosting region belongs in the change register until its design and scope effects have been decided. An architecture diagram that mixes today's service with next year's roadmap can send implementation teams in different directions.

Use four simple views:

1. A business view showing legal entities, service activities and accountable management.
2. An information view showing important collections, transfers, copies and deletion paths.
3. A control view showing who can administer identities, change software, recover data or approve suppliers.
4. A location view distinguishing operating offices, remote work and provider-hosted environments.

Give each view a date and owner. Reconcile disagreements before polishing the artwork. For example, the support manager may describe read-only access while engineering can demonstrate that a support role also generates customer exports. That discrepancy changes the boundary discussion.

The aim is enough factual detail to make decisions. Do not put secrets, customer records, private home addresses or complete access credentials into a broadly shared scoping worksheet. Use reference identifiers and keep sensitive supporting evidence in the organization's approved restricted location.

Follow authority across entities and supporting functions

A legal-entity chart tells you who exists. It does not, by itself, tell you where the service's information-security responsibilities sit. For each Harbour activity, identify who directs the work, which entity supplies the people and what authority the ISMS management team has over that activity.

Maple Quay's US support subsidiary can access Harbour's support console. Leaving it out because the parent company signs customer contracts would leave a service activity unexplained. The scope team needs to document the support work, access arrangements, applicable policies, management responsibilities and the proposed treatment of that entity in the certification engagement.

Present those facts to the certification body. Do not assume that describing a subsidiary in the internal ISMS automatically places its legal name or every location on a certificate. Equally, do not remove a function from the working boundary merely because the intended certificate has a short company name.

The same reasoning applies inside one entity. Human resources may never log into Harbour, yet its employment-change records could start the process for withdrawing production access. Procurement may select a model provider. Finance may approve a subscription that creates a new data-transfer route. Their relevant activities need attention even if their entire departments do not belong to the same operational scope.

Describe the activity precisely. “Personnel changes affecting Harbour access” is more useful than a binary argument over “all HR” versus “no HR.” Then identify the supporting information and systems needed for that activity to work. If payroll data is not required for access withdrawal, do not copy it into the evidence collection merely because the same team holds it.

Contractors also belong in the factual picture. A release engineer's ability to deploy code matters regardless of who processes their invoice. Record the duties, access, supervision and applicable controls. When a person works on both Harbour and Tide, investigate the actual separation between those roles rather than assigning the person to one box on an organization chart.

Management needs sufficient authority and resources to operate the scope it chooses. A program owner who cannot obtain records, require corrective work or resolve cross-entity responsibilities has a governance problem to surface early.

Test five ways something can affect the service

Use the following five questions as a workshop prompt. They are a practical method for finding dependencies, rather than a substitute for the standard's requirements.

Can it hold or receive relevant information?

Look beyond the primary database. Support attachments, exported reports, diagnostic records, backups and collaboration tools may contain information relevant to the ISMS purpose. For Harbour, an export attached to a support case remains part of the information flow even after it leaves the application.

Ask for one representative example using synthetic data or a safely redacted record. Record where it went, which role could access it and which owner can explain its handling. Avoid collecting unnecessary customer information merely to draw a flow.

Can it change the service or the information?

The source repository, build runner, deployment service and infrastructure-management process may influence Harbour without normally storing its customer records. A production-only asset list would miss that authority.

Trace one approved release from source change to deployed result. Identify the identities and systems that can alter the path. Include emergency or manual routes in the questions. This is a documentation walkthrough; any active security testing needs its own authorization and safe method.

Can it grant, recover or remove access?

Single sign-on is one part of the picture. Recovery contacts, privileged cloud roles, local accounts, service identities and identity administrators can sit elsewhere. Follow who can create or regain access, not only who currently has a visible application account.

For Maple Quay, shared identity administration matters to both Harbour and Tide. Excluding Tide's research activity does not erase the need to manage the administrators and identity services that affect Harbour.

Can it interrupt or restore the service?

Recovery infrastructure, key management, backup administration, incident coordination and essential suppliers can affect availability. A backup environment with little daily activity may still be central to the service's recovery plan.

Ask what happens when the normal production environment is unavailable. Where does the team get instructions and access? Which provider or person can restore the information? The answers often reveal dependencies absent from a customer-facing architecture diagram.

Does it make a decision the ISMS depends on?

Include management decisions such as accepting risk, approving a supplier, interpreting a customer requirement or funding necessary remediation. An ISMS includes decisions and responsibilities as well as technical components.

Give every “yes” a destination: a managed activity, a recorded external dependency or an unresolved decision requiring investigation. A “no” needs a basis when the proposed exclusion is significant. Silence means the question has not been answered.

Describe suppliers through the responsibilities you retain

A cloud provider operates infrastructure that Maple Quay does not manage directly. Maple Quay still chooses its services, configures its workloads, manages its identities and decides how it will evaluate the supplier relationship. Keep those responsibilities visible on different sides of the same boundary.

AWS states explicitly that customers are not automatically ISO/IEC 27001 certified by association. It also directs customers to check which services and regions its certification covers. A provider certificate can support a supplier review; it does not settle the customer's own ISMS scope.

For each material provider, record the contracted service, the relevant information or operational dependency, the provider's responsibility, the responsibility your company retains, and the evidence used to review that division. Name the internal owner who follows up when evidence is missing or the service changes.

The Canadian Centre for Cyber Security's cloud assessment guidance recommends checking whether third-party assurance covers the applicable locations, services and dates. Its guidance concerns cloud assessment, rather than defining a universal SaaS certification scope, but that coverage check is directly useful when evaluating a provider's evidence.

Harbour's model provider deserves a separate dependency record. Selected operational records leave the application for processing. The scope discussion should identify the destination, applicable service terms and settings, retention arrangements, access routes and incident contacts. Record unknowns explicitly; a generic supplier logo cannot establish those facts.

The AI feature also raises questions beyond information security, including the reliability and use of generated summaries. Keep those in the appropriate product and AI-risk work. NIST's AI Risk Management Framework addresses broader trustworthiness considerations. An ISO 27001 certificate should not be presented as a blanket conclusion about a model's accuracy or suitability.

In this example, the payroll provider supplies personnel-status records used by people operations when initiating access changes. That interface is recorded as B11; responsibility for Harbour access changes remains with the internal owner in B07. Including this interface does not mean a future Maple Quay certificate would certify the payroll provider's entire business. “Externally operated” identifies who performs an activity; it is not a reason to stop managing the relationship.

Make an exclusion survive a concrete challenge

Treat a proposed exclusion as a decision to substantiate. Write down the exact activity or component being excluded, why it sits outside the stated purpose, which connections remain, and what evidence supports the boundary. Add the owner and the condition that would require reconsideration.

For Tide, the initial proposal says: separate research, synthetic records, no Harbour customer access. That is a starting hypothesis. The team checks the repositories, cloud accounts, identity permissions, secrets, release permissions and information transfers that could connect it to Harbour.

Suppose the review finds that Tide's build runner can assume a Harbour deployment role. The claimed separation fails this test. The team can bring the relevant build activity into scope, redesign and verify the separation, or revise the program's intended coverage. It should not retain the original exclusion merely because Tide has no paying customers.

Now consider a revised design with a separate research account and no route to Harbour data or deployment privileges. Shared corporate identity administration remains managed within the Harbour ISMS because it can affect Harbour. Tide's research activity may still be proposed for exclusion, supported by the documented separation and a trigger for review if access or data use changes.

This is a deliberately narrow conclusion. It does not declare that everything associated with Tide is irrelevant, or that the organization has no other responsibilities for its research. The excluded activity and the shared supporting functions must remain distinguishable.

Use the same challenge for ordinary exclusions. “Development only” is weak if production secrets are available there. “US office” is weak if it provides the service's support. “No customer data” is weak if the system can grant privileged access or disable recovery. “Already certified supplier” is weak if the company's retained responsibilities have not been considered.

When evidence needed to justify an exclusion is incomplete, keep that exclusion decision unresolved. Do not convert uncertainty into exclusion to make a diagram look finished. Assign the next factual check, the person who can perform it and the decision owner who will consider the result.

Build a boundary register people can maintain

Use one row per meaningful scoping decision. A row may describe an activity, a group of related systems or a specific external dependency. Keep its granularity clear: twelve rows in a register do not mean twelve assets, twelve controls or twelve audit samples.

The worksheet uses four working dispositions:

• Managed: activities and supporting components governed within the proposed ISMS.
• Dependency: externally operated activity whose relevant interfaces and retained responsibilities are managed by the organization.
• Excluded: a specifically described activity outside the proposed boundary, with a recorded rationale and review trigger.
• Unresolved: a decision awaiting facts or accountable review.

These labels organize this worksheet; they are not ISO certification categories. Dependency identifies the division of responsibilities, not an automatic exclusion. Record how relevant outsourced activities and their interfaces are addressed within the ISMS. A dependency row must point to an internal owner. An exclusion row must explain the connections that were considered. A managed row must be precise enough for someone to identify its actual coverage.

Maple Quay's illustrative register contains the following twelve decisions:

The count is eight managed rows, three dependency rows and one excluded row: twelve in total. It is a navigation check, not a measure of security or readiness. Some systems and people support several rows; do not add them together as if the rows were mutually exclusive headcount groups.

Each row also needs its rationale, evidence references, information or authority path, review trigger, proposal or decision date and review state. In the companion example, every record remains an illustrative proposal. None is labelled as management-approved, certification-body-accepted or implemented merely because the table is complete.

For a real workshop, start with the blank worksheet and replace the example structure where it does not fit. Expand B03 into separate rows if environments have materially different administration or responsibilities. Combine rows only when the combined decision remains understandable and has a clear owner.

Download the scope decision worksheet and fictional worked example (ZIP). Includes a blank template and optional offline structural checks.

Draft a scope description that matches the register

Write the concise scope description after the main decisions are visible. Use recognizable service names and activities. Make it possible to identify the organization responsible and the supporting references without exposing sensitive operational detail.

Maple Quay's illustrative internal description could read:

“The ISMS covers the design, development, operation and support of the Harbour analytics service by Maple Quay Analytics Inc. and the Harbour support activities provided by Maple Quay Support LLC. It includes the supporting information, personnel activities, technology administration, remote working and supplier management identified in boundary register MQ-SCOPE-01, version 0.3. Operational locations and cloud environments are identified in the associated location and environment schedule. The separated Tide research activity is excluded as described in decision B12; shared functions affecting Harbour remain covered.”

That wording is a discussion draft. The associated register must do real work: identify the actual environments, relationships, exclusions and decisions rather than pointing to empty attachments. The certification body determines how the relevant facts appear in its application, certification scope and certificate schedule.

Read every broad word as a challenge. “Support” should lead to the people, locations and systems that deliver support. “Development” should connect to the release authority discussed earlier. “Supplier management” should have named owners and records. If the description says “all,” confirm that the supporting record can sustain that claim.

Location deserves a separate pass. Maple Quay's Canadian hosting and US support are different facts. Canadian hosting alone does not establish that all administration, support access or external processing occurs in Canada. A Toronto headquarters address alone does not describe where remote personnel work. Record the actual activities and locations needed for scoping; share personal-location detail only through appropriate restricted arrangements.

Avoid promises that the scope cannot prove. “Secure platform,” “fully compliant” and “all customer data stays in Canada” need their own support and review. A management-system scope should identify coverage without quietly adding a performance guarantee or a data-residency claim.

Run six walkthroughs before freezing the baseline

A coherent document can still describe the wrong business. Ask the people who operate the service to walk through these six cases using approved records and synthetic examples. Record the result as supported, contradicted or unresolved, with an evidence reference. These are scoping checks, not certification audit results.

A customer support export

Follow a Harbour export into a support case and through the permitted support route. Does B06 cover every destination being used? Does B02 identify the US support activity? If a new collaboration tool receives the attachment, update the information view and investigate its treatment rather than hiding it under “support.”

A production change

Follow a release through the repository, build process and deployment authority. Can every material step be connected to B05 and the relevant identity responsibilities in B04? Check an exception path as well as the standard route. If Tide infrastructure can change Harbour, B12's separation claim needs reconsideration.

A personnel departure

Follow a synthetic departure notification through the people-operations and access-removal responsibilities. The test asks whether the scope includes the activity and its dependencies. It also exposes missing ownership: a payroll provider recording an end date does not explain who removes a privileged account.

A recovery decision

Ask the platform owner to identify the recovery environment, relevant access and supplier dependency without making an unplanned production change. Does B03 include that environment? Do B04 and B09 explain the administration and provider responsibilities? Record where supporting evidence is unavailable.

A model-provider change

Suppose Harbour replaces its summary provider or changes the selected processing region. Which facts in B10 become stale? Who checks the information flow, contract, settings and supplier evidence? Who decides whether the scope description or certification-body notification needs updating? A product setting can create an organizational decision.

A buyer's reading of the proposed coverage

Give a colleague outside the scope team the concise description and a short fictional buying scenario. Ask them which service, entities and activities they think it covers. Then compare their interpretation with the register. This is a useful clarity test, not evidence that any actual customer will accept the eventual certificate.

For each discrepancy, decide whether the issue is an inaccurate document, an unsupported boundary, missing evidence or a change that requires implementation. Those are different next steps. A corrected diagram can fix an inaccurate label. It cannot remove a real deployment permission or establish an unverified supplier location.

Keep the unanswered questions visible. A baseline can be versioned while decisions are pending, provided its status is clear. Management should know which uncertainties could materially change the scope, resources or certification engagement before committing to the next stage.

Connect scope to the rest of the ISMS

Once the boundary is established, check the documents that depend on it. The risk assessment should address the relevant activities and dependencies. Treatment decisions and the Statement of Applicability should reflect the risks and necessary controls. The internal audit program and management review need to consider the ISMS actually being operated.

Use a trace rather than a new giant checklist. Select B10 and follow it into the supplier assessment, information-security risk record, relevant treatment decisions and operating responsibilities. Then select B07 and follow the personnel-change activity. These two paths cross different teams and help reveal whether the common scope exists only in the introductory document.

Do not force a one-to-one relationship between register rows and controls. One identity process can support several activities. One supplier dependency can create several risks. Store the relationship references so readers can follow them without pretending that every row requires a unique policy.

Existing SOC 2 work may supply useful inventories, operating records and descriptions. Confirm their coverage, dates and relevance before reusing them. A record that covers one product or entity may be incomplete for the ISO program. For the separate consulting and examination decisions, see our SaaS SOC 2 readiness guide.

The purpose of this consistency review is to find mismatches while they are manageable. BSI's implementation guidance connects planned operation, risk assessment, internal audit, management review and improvement. Your records should show how those activities work within the organization's chosen scope.

Keep the scope accurate through change and certification

Give the boundary register an owner and connect reviews to changes that can affect it. Useful triggers include a new product, acquisition, cloud region, support country, privileged-access route, material supplier or use of real customer information in a previously synthetic environment. Set a planned review cadence as part of the organization's management process as well.

For Maple Quay, enabling a future US hosting region would reopen B03, relevant supplier evidence and the location schedule. It would also prompt a check of customer commitments and the proposed or existing certification coverage. The fact that the same software runs there does not settle those questions.

Record what changed, which rows and documents are affected, who approved the organizational decision, and whether the certification body must be consulted or notified under the engagement terms. Keep the effective dates distinguishable. A planned change, a deployed change, an updated internal scope and a revised certificate can occur on different dates.

When reviewing a certificate, check the issuer, certified organization, scope, locations, standard and dates. ANAB's certificate-checking guidance explains the key fields and directs validity questions to the issuing certification body. Resolve uncertainty with that body rather than relying on a badge or an old PDF saved in a sales folder.

Give customer-facing teams approved language that reflects the current status and coverage. A scope expansion under discussion should not be advertised as certified. Keep internal operational detail restricted while providing the appropriate certificate and coverage explanation through the company's approved sharing process.

Leave the scope workshop with a decision package

Bring together the sponsor, ISMS owner, product and engineering leads, IT, support, people operations and the owners of relevant legal and supplier questions. Use the service purpose, current architecture and customer requirements as inputs. Invite additional people because their responsibilities affect the boundary, not simply because their department appears on a template.

The useful outcome is a dated package: a concise scope description, the boundary register, location and environment schedule, supporting diagrams, an exclusion record and a list of unresolved decisions. Each unresolved item needs an owner and the next evidence needed. Management should be able to explain why the proposed coverage serves the business purpose and what it will take to operate it.

Take that package into implementation planning and the certification-body conversation. A good next discussion is concrete: which activities are covered, which dependencies remain external, which exclusions have support, and which changes must happen before the proposal can become an operating baseline.

If your team needs help organizing that work, review Canada Create's ISO 27001 readiness and compliance consulting. Custom-scoped engagements; proposal after discovery. Share the high-level service and boundary questions first; agree secure arrangements before transferring sensitive operational evidence.

An effective scope remains understandable after the first workshop. Your team can point from a sentence to a decision, from that decision to the real service, and from a change in the service to the person responsible for revisiting it.

Start there before choosing which competitors to target. A familiar brand can attract buyers comparing products, existing customers opening their accounts, and employees searching for help. Those people may use similar words while needing entirely different things.

This guide follows one fictional SaaS campaign from search intent to a completed commercial decision. Its historical teaching cohort produces 45 demos and two customers from CAD 6,000 in media. The two contracts contribute CAD 4,800 over the stated evaluation horizon. That leaves contribution less media at negative CAD 1,200, before other acquisition costs. A promising-looking part of the campaign deserves investigation, but the campaign as a whole does not earn an automatic budget increase.

Northline, ElmSuite, all product details, searches and figures below are invented. They are teaching assumptions, not Canada Create client results, market benchmarks or recommended spending levels. The subject is acquiring customers through searches related to another brand. Defending your own brand requires a separate decision.

Five searches, five different conversations

Imagine Northline, a Toronto workflow software company, considering ads around ElmSuite. Before building the campaign, read these searches as requests from people:

• ElmSuite: The person may want the website, a product explanation or a starting point for research. The brand alone leaves the purpose unresolved.
• ElmSuite login: The immediate task is probably accessing an existing account. Northline cannot provide that access.
• ElmSuite pricing: The person may be comparing suppliers, checking a renewal, preparing a budget or finding a current price. Commercial language gives a clue, not a completed qualification.
• ElmSuite alternative: This is a stronger indication that the person wants another option. It still says little about company size, required integrations or purchase timing.
• ElmSuite integration: The person may need help connecting an existing product, or may be investigating whether a new purchase will work with their systems. The missing integration name matters.

Google distinguishes an advertiser’s keyword from the search term entered by a user. Reviewing the keyword list alone therefore cannot tell you the full mix of requests the campaign reaches. Google’s search terms report documentation explains that distinction.

Use these clues to form a working hypothesis. Keep uncertainty visible. Calling every pricing search a switching opportunity makes the campaign look more commercially focused than the evidence allows. Calling every integration search a support request can discard a genuine purchase question.

For Northline, “alternative” would justify closer consideration. “Login” would raise an immediate relevance concern. Pricing and integration queries would need their full wording, the destination offered and downstream conversations reviewed together. A naked brand search should not acquire a confident intent label simply because an ad attracted a click.

This classification is useful only if it changes what you do. If someone wants account access, a stronger demo button will not solve their problem. If someone needs an integration Northline genuinely supports, a specific explanation could help them evaluate the product. And if the intent cannot be established, the report should say so rather than assign a convenient story.

Give the buyer a real reason to switch

A competitor’s popularity is a weak reason to buy its search traffic. Start with the job your product can replace and the conditions under which that replacement makes sense.

For Northline, assume the useful difference is approval routing for small operations teams that need a named finance-system connection. Its product team can demonstrate that workflow in the current release. Also assume Northline does not provide a feature needed by larger organizations: multi-entity approval administration. Those boundaries make the campaign more specific and more honest.

The first audience has a plausible reason to investigate. The second may be a poor fit even if it searches for an ElmSuite alternative. A campaign aimed at all dissatisfied ElmSuite users would combine these people and leave sales to discover the distinction after the money was spent.

Ask the product team to show the difference using a real workflow before turning it into an ad promise. Can a prospect complete the required task? What plan includes it? What setup is necessary? What still needs manual work? A feature name in a spreadsheet is less useful than an answer to the buyer’s practical question.

Then consider switching effort. Moving software can require data exports, configuration, staff training and a period of overlap. A lower subscription price may not compensate for those demands. If Northline supports a particular import format, explain the format and its limits. If some historical records need manual handling, disclose that early. “Easy migration” is too broad when the work depends on the customer’s data.

The campaign does not have to remove every obstacle. It does need a credible route through the important ones. A prospect willing to switch in six months may be valuable, but their timing should not be confused with a near-term sales opportunity. Someone locked into a required integration Northline lacks is a different problem entirely.

This pre-auction work also gives sales a useful starting point. Instead of asking only which competitor the prospect uses, ask which task is difficult, what must remain connected and what would make a move worthwhile. The answers help distinguish poor traffic from a genuine product gap.

A narrow, well-supported reason to switch is enough to consider a bounded test. A broad claim that your product is “better” does not tell the buyer or the campaign team very much.

Review targeting, the displayed ad and the destination separately

Competitor campaigns involve three surfaces: the keyword used for targeting, the ad the searcher sees and the page reached after clicking. A decision about one surface does not settle the others.

Google’s trademark policy distinguishes trademark use as a keyword from use in an ad. Its complaint-review criteria say Google does not restrict trademarks used as keywords, while identifying direct-competitor trademark use in ads and confusing or misleading use as restricted. Read the current Google Ads trademark policy for its scope and criteria.

That is a platform-policy distinction. It does not establish that a proposed campaign or comparison page is legally cleared in Canada, the United States or another jurisdiction. Get appropriate advice for an actual disputed claim, trademark use or campaign concern. An approved ad is not a legal opinion.

Advertiser identity deserves its own check. The visitor should understand who is making the offer and who will receive the enquiry. Google’s misrepresentation policy addresses misleading identity and affiliation, deceptive pricing, unavailable offers and inconsistencies between advertising and destinations.

For Northline, the practical approach is straightforward: identify Northline clearly, describe a benefit it can support and make the destination visibly Northline’s. Do not imitate ElmSuite’s account-access screen or create the impression that Northline provides ElmSuite support. Keep the product and conditions consistent from the ad through the enquiry confirmation.

Do not treat a disclaimer at the bottom as a substitute for a clear first impression. Review what a hurried mobile visitor would reasonably understand before scrolling. If the headline, colours and form imply one supplier while the footer names another, the experience needs repair.

This is a review framework, not approved ad copy. The actual words, business identity, trademark use, offer and page need to be checked together immediately before a campaign goes live. Policy details can change, and the circumstances of a real product comparison matter.

Build a comparison destination that helps someone decide

Someone evaluating an alternative needs enough information to decide whether continuing is worth their time. Lead with the replacement job and a clear fit statement. Follow with the evidence that supports it, including limitations that could rule the product out.

Northline’s page might explain that its current product supports a particular approval workflow for a single operating entity. It could show the steps, identify the eligible plan and explain the finance-system connection. It should also say that multi-entity administration is outside the offer. That limitation may reduce enquiries while improving the usefulness of the conversations that remain.

A comparison claim needs a source and a date. For your own product, that could be current documentation, an approved plan description or a reproducible demonstration. For another supplier, use current first-party product or pricing information where available. Record what the source actually establishes. An absent mention in a help article does not prove that a feature does not exist.

A compact claim record keeps the page maintainable:

• Claim: the precise capability or condition being described.
• Evidence: the source or demonstration that supports it.
• Checked date: when someone last verified that evidence.
• Limitation: plan, configuration, geography or other relevant boundary.
• Review responsibility: the person who can resolve a change or uncertainty.

In Northline’s claim record, “imports approval templates from a supported CSV” would be narrower and more testable than “moves everything automatically.” If the demonstration covers templates but not historic approval logs, the page should preserve that distinction.

Pricing comparisons need similar care. Check whether the amounts refer to monthly or annual commitments, seats, usage, required add-ons and the same currency. If one product requires a quote, say so. Do not fill a missing price with an estimate and present the resulting difference as verified savings.

Keep the next step proportionate to the uncertainty. A visitor who needs to verify an integration may need a technical explanation before a sales meeting. A visitor with a specific switching requirement may be ready for a fit conversation. The button and confirmation should explain what happens next, including whether the submission requests a meeting or actually books one.

The broader principle is covered in our guide to landing page message match. Here, the extra challenge is that the person began by naming another supplier. Your page must quickly explain why your offer is relevant without obscuring who you are.

There is also a maintenance cost. When a plan changes, an integration is retired or a rival adds a feature, the old comparison may cease to be useful. Give the page a review trigger tied to those changes. A visible checked date helps the reader, but it does not replace the work behind that date. For the organic side of comparison content, use the separate SaaS SEO guide.

What a helpful comparison leaves out

Resist building a giant feature grid simply because there are many things you could compare. A buyer replacing an approval workflow may care deeply about routing, permissions and the finance-system connection, while having little interest in unrelated modules. Put the decision-relevant differences first. Link to deeper documentation when a specialist needs it.

Be equally careful with evidence from sales conversations. One prospect’s experience can identify a question to investigate, but it cannot establish a universal weakness in another supplier’s product. If a prospect says a workflow is impossible, check whether the issue is plan access, configuration, training or an actual product limitation before turning it into public copy. An anonymized anecdote is still an anecdote.

A useful page can acknowledge that staying with the current supplier is reasonable for some readers. That does not weaken the offer. It makes the fit boundary explicit and prevents a campaign from asking sales to solve a problem the product cannot solve. Northline should want the right operations team to understand its advantage and the multi-entity buyer to understand its limit.

Decide what the first cohort needs to tell you

Before spending, write the decision in a sentence. For Northline: “We want to learn whether people evaluating this replacement job can become suitable customers within our approved acquisition economics.” That wording is more useful than “see how competitor ads perform.” It connects the audience, offer and outcome.

Choose a spending boundary the business can afford to learn from. There is no universal budget hidden in this example. The amount depends on the company’s economics, tolerance for uncertainty and ability to follow the outcomes. A budget too small to produce an interpretable result may still spend real money; a large budget cannot rescue unclear qualification or a product mismatch.

Agree on the downstream definitions. In this teaching cohort, a demo is a completed first product demonstration for a unique prospect organization. A qualified opportunity is a demo organization that meets the agreed product-fit and active-purchase criteria. A win is an acquired contract from that same cohort. Repeated meetings do not create extra demos, and several contacts from one organization do not create several customers.

Your company may need different stages, especially with trials or self-serve sign-ups. Whatever the model, keep stage definitions stable enough that a change in reporting cannot masquerade as better campaign performance.

Also agree on the economic horizon. For this example, assume CAD 2,400 of contribution per acquired contract over its first 12 months, after the direct delivery costs included in the example’s approved contribution definition. The cohort is historical and fully reviewed through that horizon.

Media, agency, creative and sales acquisition costs are outside that CAD 2,400 figure. Media is deducted explicitly later. The other acquisition costs remain unquantified, so the result cannot be described as total profit or complete customer acquisition cost. This boundary matters as much as the arithmetic.

Keep the unknown searches in the accounts

A campaign report should reconcile to the media paid for the cohort, including spending that cannot be assigned to a useful query category. Google says some search terms are omitted from the report for privacy reasons; search terms insights may aggregate such activity without revealing the individual queries. Visible terms are therefore not a complete census. Google’s reporting explanation is the source for that limitation.

For the teaching example, every media dollar belongs to exactly one of three mutually exclusive reporting buckets:

1. Switching/comparison: visible searches with enough evidence for this working classification.
2. Navigation/support: visible searches whose immediate request concerns access or help with the other product.
3. Unclassified search detail: activity whose intent cannot be assigned from the available detail.

The third bucket is essential. It is not a synonym for poor traffic, nor a place to hide inconvenient results. Privacy-related omissions can contribute to it; ambiguity and unreconciled detail can also leave intent unknown. Do not guess a concealed query from an account’s name or from the fact that a demo happened.

In a real account, the ability to connect reporting buckets with later CRM outcomes has to be validated. Do not assume that every closed contract can be traced to an individual visible search. If a campaign-level outcome is known but its query category is not, preserve that uncertainty at the level supported by the records. The synthetic example supplies a complete, consistent allocation for teaching; it does not claim that a Google report automatically provides this table.

For report operation, use the existing search terms review guide. If the review identifies clearly unwanted requests, the negative-keyword guide explains how to assess exclusions without casually removing useful searches. The commercial task here is to decide what the evidence supports, before treating a longer exclusion list as progress.

The complete fictional cohort: 45 demos, 11 opportunities, two wins

Here is Northline’s fully reviewed historical teaching cohort. All amounts are CAD. Each organization enters the table once, stages are nested, and the three buckets account for all media spending. There are no pending outcomes in this illustrative closed cohort.

At the demo stage, navigation/support looks attractive: CAD 1,800 divided by 18 demos is CAD 100 per demo. Switching/comparison costs CAD 150 per demo. If the team judged the campaign on that metric alone, it might favour the part with no wins.

Follow the same organizations one stage further. Switching/comparison produces eight qualified opportunities at CAD 450 each. Navigation/support produces two at CAD 900 each. The unclassified bucket produces one at CAD 600.

The change in ranking is worth investigating, but it is not a diagnosis by itself. Perhaps navigation-oriented visitors misunderstood the offer. Perhaps some were genuinely evaluating a move but lacked a required capability. Perhaps qualification was applied inconsistently. Review the relevant conversations before claiming to know why the pattern occurred.

The whole-campaign media calculations are:

• CAD 6,000 ÷ 45 demos = CAD 133.33 per demo, rounded to cents.
• CAD 6,000 ÷ 11 qualified opportunities = CAD 545.45 per qualified opportunity, rounded to cents.
• CAD 6,000 ÷ 2 wins = CAD 3,000 per win.

Keep the unrounded fractions for calculations; round only the displayed monetary rates. Multiplying CAD 133.33 by 45 will not exactly recreate CAD 6,000 because the displayed rate is rounded. That small difference is a display issue, not missing campaign spend.

The switching/comparison bucket alone has a media cost per win of CAD 1,800. Neither of the other buckets has a finite cost per win because their win count is zero. Report “no wins” rather than displaying a cost of CAD 0. A zero value would suggest free acquisition when the business actually spent money without recording a customer in that bucket.

Finally, retain the original denominator when presenting the campaign. Showing the two wins beside only the CAD 3,600 switching spend would silently remove CAD 2,400 that Northline paid. It is reasonable to inspect a segment. It is misleading to substitute that segment for the full campaign without saying so.

What did the two contracts contribute after media?

Each acquired contract contributes CAD 2,400 over its first 12 months. Two wins produce CAD 4,800 of contribution on that basis.

The complete campaign calculation is:

2 × CAD 2,400 = CAD 4,800 contribution.

CAD 4,800 − CAD 6,000 media = negative CAD 1,200 contribution less media.

The calculation gives a clear answer to one question. The attributed contracts’ contribution does not cover the cohort’s media cost over the stated horizon. It says nothing about uncounted later renewals, and it excludes agency, creative and sales acquisition costs. Adding positive acquisition costs would make this defined result less favourable, not rescue it.

Avoid calling CAD 4,800 revenue. It is contribution under the example’s definition. Avoid calling negative CAD 1,200 incremental profit. The example has not established how many contracts happened because of the advertising. And avoid calling CAD 3,000 complete CAC: it contains media only.

The switching/comparison segment has a different arithmetic result: CAD 4,800 contribution less CAD 3,600 media equals positive CAD 1,200 before the other acquisition costs. Navigation/support contributes negative CAD 1,800 after media, and unclassified search detail contributes negative CAD 600. Add the three results and the campaign returns to negative CAD 1,200.

That segment result is a reason to ask a more focused question. It is not proof that removing the other traffic will reproduce the same two wins at the same cost. The campaign would be operating under different conditions, and the evidence contains only two customers.

A small sensitivity check shows the fragility. Holding media at CAD 6,000 and contribution per win at CAD 2,400, one win leaves negative CAD 3,600; two leave negative CAD 1,200; three leave positive CAD 1,200. The media-only break-even calculation is 6,000 ÷ 2,400 = 2.5 contracts, so three whole contracts are needed to cover media under these assumptions.

That third contract is not forecast. Nor does three-win media coverage establish an acceptable business return after other costs. It simply shows how much the conclusion can move when a small cohort gains or loses one outcome. If leadership needs a dependable forecast, this example does not supply one.

Use the same horizon when comparing your options

The example uses the first 12 months. Your business might evaluate a shorter cash-recovery window or a longer contribution period. What matters is that the team chooses and documents the basis before judging the result, then applies it consistently.

Do not compare one campaign using first-year contribution with another using projected lifetime revenue. The numbers can appear comparable while describing different things. Similarly, an annual contract value does not reveal when cash arrives or what it costs to serve the customer. If those questions affect the spending decision, bring them into the evaluation explicitly rather than stretching a media-only calculation to answer them.

For a real cohort, finance should also explain how cancellations, credits and changes in delivery cost affect the agreed contribution measure. A previously recorded win may need an economic adjustment even when the sales record remains closed-won. Preserve that update instead of freezing the most favourable version of the result.

Finally, consider the alternative use of the budget. Northline might have another acquisition route with stronger evidence, or a product issue that deserves attention first. This example cannot rank those choices because it contains no comparable data for them. A competitor campaign does not earn funding merely by clearing a media-only threshold; the company still has to decide whether its expected value and uncertainty justify the commitment relative to available options.

Make a decision that fits what you know

This cohort does not support scaling the unchanged campaign. The complete result is negative, the cheaper demo bucket produces no wins and two customers are too few to establish a reliable future pattern. A useful decision would separate what should stop now from what deserves a better test.

Narrow when the product fits a specific replacement job and the evidence suggests the campaign also reaches clearly irrelevant requests. Northline could consider a separate test with a defined spending limit focused on the switching question. That proposal still needs appropriate targeting, identity and destination review. The keyword match-type guide owns the mechanics; choosing a match type alone does not validate the audience.

Repair when the enquiry evidence points to a fixable mismatch. If visitors expected support from ElmSuite, clarify the advertiser and offer. If suitable prospects could not find an integration answer, provide the verified answer. If the required integration does not exist, repair means changing the claim or excluding that use case, not making the page more persuasive.

Stop when there is no supported reason to switch, the offer cannot meet the need, the economics remain unacceptable or a policy or identity problem is unresolved. Spending more to obtain a larger sample is not a remedy for advertising an unavailable capability.

Continue within a defined boundary when a still-valid question remains, the business accepts the cost of learning and outcomes can be evaluated properly. Continuing means a deliberate commitment to answer that question, not leaving a campaign on because it already exists.

Northline’s most defensible next proposal is to stop treating all competitor-related interest as equally useful, investigate the navigation/support demos and decide whether the switching use case warrants a new test. The historical loss remains in the record. A future test should be reported as a new cohort rather than folded into the old one until the original shortfall disappears.

A simple decision note can capture the conclusion in ordinary language: “The complete cohort did not cover media. The switching segment warrants investigation because it produced both wins, but the count is too small to assume repeatability. We will resolve identity and qualification questions before deciding whether to fund a narrower test.” That is more informative than either “competitor ads work” or “competitor ads never work.”

Respect timing, measurement gaps and causality

A current campaign will rarely arrive as neatly resolved as the teaching table. Some prospects are still evaluating, some contracts are awaiting a final decision and some recorded outcomes have not reached the advertising report.

Google explains that conversion delay can make recent performance appear weaker while spending is already reported. Its conversion-timing guidance supports reviewing the account’s actual delay history. It does not supply one universal waiting period for every SaaS sales process.

Separate a mature cohort from a pending one. For pending opportunities, show current status and the unresolved exposure. Do not count them as lost to make an early judgement, or count their expected contract value as realized contribution to make the campaign look successful. A forecast can be useful, but it needs a clear label and should sit alongside actual outcomes.

Measurement quality is a different question from maturity. Duplicate organizations, inconsistent qualification and missing outcomes can distort an old cohort too. Reconcile the records before interpreting the result. The separate guide to Google Ads and CRM conversion mapping covers connection and validation work. Here, the key limit is simple: a decision cannot be more precise than the records that support it.

Attribution adds another boundary. An organization may encounter your content, receive a referral and later click a competitor-search ad before buying. Crediting that campaign in a reporting model does not tell you whether the organization would have purchased without it. The cohort evaluates attributed economics; incremental lift remains unmeasured.

If the next question is causal, define a suitable comparison and assess whether a credible test is feasible. Our Google Ads experiment planning guide covers experiment mechanics and interpretation. Simply comparing the month before a change with the month after it leaves other explanations open, including seasonality, offer changes and differences in the prospects reached.

An inconclusive answer is acceptable. It can mean the available evidence does not support a confident commitment at the proposed scale. Keep that conclusion separate from a claim that the channel has no possible value.

What should be true before you spend the next dollar?

A useful competitor campaign begins with a real replacement job, gives the visitor a clear and supportable offer, and follows outcomes far enough to assess the spending. It also keeps unknowns visible instead of making the dashboard tidier at the expense of the decision.

Before continuing, be able to explain who should consider switching, why your product fits, what the page proves and what the completed cohort says after all its media is included. If one of those answers is missing, identify the missing evidence and the work needed to obtain it. Sometimes the next step is a narrower campaign. Sometimes it is a product explanation, a reporting repair or a decision to stop.

For Northline, 45 demos do not outweigh a negative CAD 1,200 contribution-less-media result. The two wins are still useful evidence. They identify a question worth examining without establishing a success story. Holding those two facts together is the discipline that makes a competitor-keyword test worth running.

If you need help reviewing that decision for your own account, Canada Create’s Google Ads service is the relevant starting point. For the wider connection between acquisition, product fit and the software buyer’s journey, see our SaaS marketing service.

That question is worth answering before a redesign produces thirty attractive templates with thirty slightly different accounts of the same product. A cleaner layout cannot resolve an ambiguous fact. It can make the ambiguity easier to publish.

This workshop starts with an intentionally wrong model, repairs it, and puts the repair through three editing tasks. You will leave with four content types, completed sample records, field definitions and tests you can adapt to your own site. The companion HarbourGraph Content Model Workshop brings the dictionary, sample records and validation script together in one package. The aim is a small model that survives ordinary work, rather than an impressive diagram nobody can use.

Our example is HarbourGraph, a fictional Toronto software company. Its product, people, evidence references, dates and capability claims are invented solely for this exercise. They describe no real product or client. The exercise is a website content model, not a system for granting software access.

Start with the question a visitor needs answered

HarbourGraph sells a workflow product called HarbourGraph Flow in Standard and Enterprise plans. Its marketing website has an Enterprise product page, an operations use-case page and a plan comparison page. Each mentions a feature called Approval history, identified throughout the exercise as F-17.

A Canadian visitor comparing plans needs a precise answer: “Can I use Approval history on Standard, or do I need Enterprise?” A visitor evaluating a US deployment has a different question. The product’s general explanation does not answer either one.

For the opening exercise, these are the approved fictional facts:

• F-17 records who approved a workflow step and when.
• F-17 is available on Enterprise in Canada.
• F-17 is not included on Standard in Canada.
• F-17 availability in the United States is unknown for both plans.

Unknown does not mean unavailable. It also does not mean coming soon, available on request or probably the same as Canada. Each of those phrases would add a claim we have not established.

The first workshop deliverable is this short list, agreed before anyone chooses fields. Ask a product representative to explain what would make each statement wrong. If the answer is “it depends on the plan,” plan belongs in the model. If the answer is “the US release has not been confirmed,” the model needs a way to preserve uncertainty.

Keep the scope small. We will not model every product, integration, translation or pricing exception. We will model enough to reveal whether the underlying structure can carry a qualified product fact without asking every editor to remember its exceptions.

Revision one: show the model that fails

Start with the spreadsheet a rushed team might actually create:

The pages reference F-17 and display a check mark whenever Available is true. Reuse appears to work: one record, three destinations, no duplicate description to maintain.

Now run the visitor’s question through it. The comparison page puts a check mark in both plan columns. The use-case page says “Available with HarbourGraph Flow” without a regional qualification. A US page could produce the same statement. The database is consistent, but the claim is wrong.

This is the first important result of the workshop. Centralizing a bad model centralizes the error. Shared content is useful only when the shared unit means the same thing everywhere it is used.

Do not fix this with a footnote editors must remember to paste beneath the component. That leaves the primary field asserting a universal fact and the surrounding prose trying to retract it. Do not add a second global checkbox called Enterprise only, either. The two fields can disagree, and neither captures the unresolved regional question.

Write the failing test in ordinary language: “When the page asks for F-17, Standard, Canada, the answer must be not included.” The first model cannot pass because it does not store Standard or Canada. That is a structural failure, not an editor’s spelling mistake.

Keep this failed sheet. It is useful evidence of why the new relationship exists. Without it, a future simplification may put the global checkbox straight back.

Separate the fact, the page and the card

Before adding more fields, separate three decisions that often get bundled together.

The fact is that Approval history records the approver and time. That explanation can be shared. The page’s job determines why a visitor should care: an operations page might introduce handovers, while a comparison page helps someone distinguish plans. Those introductions should not automatically become the same paragraph.

The card is a presentation choice. It may have an icon, border, short heading and spacing rules. Reusing its design does not require every instance to share one content record. Equally, one feature record can appear in a card, a comparison row and a text-led section without acquiring three identities.

Use a simple test when deciding what to share. If changing this statement should change every use because all uses refer to the same fact, consider a shared record. If changing it should affect only one audience’s explanation, keep it with that page. If it changes how content looks, put it in the presentation system unless editors have a deliberate reason to choose it.

For HarbourGraph, the feature explanation is shared. “Review handovers before your next shift” belongs to the operations page. Red borders, column spacing and the position of a status label belong to the component. Availability needs its own structured relationship because it depends on the product, feature, plan and region together.

Avoid making every sentence a reusable object. A model can be technically normalized and editorially exhausting. An editor should not have to open six records to fix one introductory paragraph. Create a separate record when identity, reuse, ownership, conditional meaning or lifecycle justifies the extra step.

Revision two: give the condition its own record

The revised model has four types: Product, Feature, Availability and Page.

Product identifies what is being offered. Feature explains a capability. Availability says whether a particular feature is included for one product, plan and region during a defined period. Page assembles an audience-specific narrative and references the facts it needs.

The relationship reads like a sentence: “For product P-01, feature F-17 has this availability in this plan and region.” Availability points to one Product and one Feature. Many availability records can point to the same pair, because plans, regions and effective periods differ.

A Page holds one Product reference and an ordered list of Feature references. Its view definitions say which plan and region to request. The renderer resolves the appropriate Availability record for each view. A Canadian comparison page therefore requests Enterprise/CA and Standard/CA separately. It never asks a global feature checkbox to answer both.

A view is a small configuration object on the Page in this example, not a fifth independent content type. If views later need independent ownership or reuse, that decision can change. The workshop should reveal that need rather than assuming it.

We will use exact matches. There is no hidden “all regions” fallback. When a matching approved record is missing, the resolver returns an internal missing-record error and blocks the positive claim. It must not borrow another region’s value. An explicit unknown record is different: someone has recorded and reviewed the uncertainty, and the page follows its agreed unknown-state treatment.

These are design choices for this exercise. They are not universal requirements imposed by a CMS. Your product may need contract tier, deployment method or customer segment as an additional dimension. Add a dimension only when it changes the answer and your team can maintain it.

Fill in the records before designing the editor

A diagram can hide uncertainty behind a convincing arrow. Completed records force it into view.

Product and feature

P-01 and F-17 are stable identifiers. Renaming Approval history should not break its relationships. A public URL slug may change under a separate URL-management decision; it should not be the only identity that joins records together.

F-17 also has lifecycle active and internal evidence reference SYN-F17-01. That reference points to a fictional workshop fact sheet, not a real product document. Its fact owner is the fictional Product lead role, its reviewer is the fictional Content lead role, and its reviewed date is October 10, 2026. Its next review trigger is a change to approval-event behaviour.

Availability at the opening snapshot

All four records below are approved, effective from October 1, 2026, with no end date yet. Their review metadata is complete in the sample record file.

An end date is exclusive in this exercise. A record effective from November 1 stops applying at the start of its end date, if one is set. That convention prevents two adjoining periods from both claiming the same day. The prototype uses calendar dates in UTC; a real launch needing a particular local hour should use an explicitly defined timezone and timestamp instead.

The status describes a website fact. The approval field describes whether that fact may be used in the published view. Those are separate fields. “Available, draft” is a perfectly meaningful editorial state, but it must not become an available claim on the live website.

Page records

PG-04 is a prototype test page, not a recommendation to create a live regional landing page. It exists to test unknown-state behaviour. A production team must separately decide whether a US page has a useful, supported purpose.

The operations page can discuss why approval history matters, but its status treatment must still qualify the claim. For example: “Approval history is available on Enterprise in Canada. It is not included on Standard.” Its audience-specific introduction stays on the Page; the two status statements come from their matching availability records.

Write a field dictionary an editor can use

A field name is not a definition. “Status” is particularly dangerous when one person reads it as product availability and another reads it as publishing approval.

Start with the fields that affect truth. Give each a type, requirement, definition and invalid example. The following compact dictionary covers the main decisions; the companion dictionary includes every sample field.

There are also rules across records. Two approved availability records for the same product, feature, plan and region must not overlap in time. A reference cannot point to a missing object. An approved feature requires a completed review object. A draft record can be incomplete while an editor works, but it cannot pass the publish gate until required review details are present.

Write the error an editor should see. “Two approved Standard/CA records overlap from November 1” is more helpful than “validation failed.” Show the conflicting record IDs and the dates. Validation should help the person repair the content, rather than merely preventing the Save button from working.

Keep internal review information out of public output by design. Hiding a field in the visual template does not prove it is absent from an API response. The implementation must define which fields may leave the editorial system and test that boundary. A public fact can be supported by internal evidence without publishing reviewers’ names, internal notes or document locations.

Test the relationships, including the absent ones

A relationship diagram shows what can connect. A relationship test shows what happens when it should not.

Try a Page that references F-99, which does not exist. The validation report should identify that Page and the missing Feature. Try an Availability record pointing to P-99. Reject it before it can be approved. Try Standard spelled with a trailing space or region set to Canada instead of CA. The editing interface may normalize an allowed input, but the stored contract must be unambiguous.

Next, create two approved A-02 variants covering the same date. Returning the first match is not a solution. It makes database ordering decide the website’s product claim. The resolver should stop and report a conflict.

Finally, remove A-03 temporarily. The US Enterprise view should report a missing approved availability record. Restore A-03 with status unknown and the view should display the chosen uncertainty treatment. This pair of tests proves the system can distinguish a deliberate unknown from broken data.

For the workshop, the unknown treatment is “Availability has not been confirmed for this plan and region.” A real team may decide to omit a claim and route the question to a verified contact instead. Decide that treatment explicitly. Do not turn unknown into an optimistic check mark, and do not style it so faintly that the qualification disappears on a phone.

Read the output as a customer would

Before the editing tasks, write the expected output for the opening snapshot. This gives the designer something more useful than a box labelled dynamic content.

On PG-01, the feature block reads: “Approval history. Records who approved a workflow step and when. Available on Enterprise in Canada.” Its context travels with the claim. A visitor arriving halfway down the page should not need to infer the plan from the navigation.

On PG-03, the comparison row has two explicit answers: “Standard, Canada: not included” and “Enterprise, Canada: available.” The row does not show one large check mark beside the feature name and leave the reader to guess which column it qualifies. If the table becomes stacked cards on mobile, each card retains its plan and region labels.

On PG-04, neither US plan receives a check mark. Both say availability has not been confirmed for that plan and region. This is a deliberately unexciting answer. The model is doing useful work by refusing to make the page sound more certain than its evidence.

Now remove the decorative treatment mentally. Can the answer still be understood from text alone? A red dot and a grey dot are insufficient if the reader does not know what the colours mean. Use meaningful status text. An icon can reinforce that text; it should not carry the whole claim.

Check the sentence around the component as well. The data-driven label may correctly say Standard is not included while the page introduction says “Every HarbourGraph customer can review approval history.” That contradiction lives outside the shared record. A dependency review therefore needs both automated checks of structured output and human review of nearby editorial claims.

This is also where you decide whether to show the feature explanation on every page. The comparison row may need only a concise feature name, an optional explanatory detail and the two status values. The operations page may need the full explanation. Both can reference F-17 without rendering every field. A reusable record is a source of selected facts, not an instruction to print its entire contents.

Finally, test an unsupported view, such as a region that the exercise does not define. Do not quietly interpret it as Canada. The editing interface should reject an invalid region before publication, and the delivery layer should handle an unexpected request without producing a positive claim. The exact public error experience is an implementation decision. The truth constraint is simpler: missing or invalid context must never become an invented availability answer.

Use these output examples as acceptance text, not as a promise that a particular CMS will generate them automatically. The template, resolver and release process must be built and tested to produce the agreed result.

Editor task one: change one explanation and trace every use

Now make a plausible editorial improvement. Change F-17’s explanation from “Records who approved a workflow step and when” to “Shows the approver and approval time for each completed workflow step.” This is an invented approved revision for the exercise. It does not broaden the capability into a compliance claim or a guarantee of complete audit coverage.

The editor creates a draft revision, records why it changed and sends it to the designated reviewer. The published view continues using the approved revision until the new one is approved and released. A simple prototype can model this with two snapshots rather than pretending its files implement a production workflow.

Trace F-17 through PG-01, PG-02, PG-03 and PG-04. All four reference the Feature, but their visible effects may differ. A comparison component may display only the feature name and status. Its output might not contain the explanation. It still belongs in the dependency review because an accessibility label, expanded detail or mobile treatment may use that field.

The expected result is specific: the approved explanation changes wherever that field is rendered; page introductions remain unchanged; Enterprise/CA remains available; Standard/CA remains not included; US remains unknown. Changing a description must not silently change availability.

Then separate content correctness from delivery correctness. The approved record may be right while a static build still contains the old sentence. A server cache, edge cache, search index or separately maintained download may be behind. A dependency map tells you what to inspect; it does not prove every destination has refreshed.

For each relevant route, record the approved content revision, the requested plan and region, the rendered wording and the observation time. Verify the actual delivery path visitors use, as well as the preview. If preview is current and production is old, investigate the release and cache path. Re-editing the fact to force a refresh can obscure the real problem.

Keep exports and other channels in their own delivery list if they exist. The workshop does not assume that changing the website CMS updates a sales PDF, application interface or email campaign. Those destinations need defined integrations or an explicit manual handoff.

Editor task two: add Standard later without changing today

The second task introduces a proposed change: Approval history may become available on Standard in Canada on November 1, 2026. This is another fictional scenario, not a product announcement.

Create A-05 for P-01/F-17/Standard/CA with status available, valid_from November 1 and approval draft. Leave A-02, the currently approved not_included record, unchanged while the proposal is being reviewed. On October 10, the public resolver must still return not_included for Standard/CA. A draft is not an exception the public site is allowed to discover.

Preview the proposed release as a coherent package. In that preview, A-02 ends on November 1 and A-05 begins on November 1. In the current published snapshot, A-02 still has no end date and A-05 remains excluded. This avoids editing the live interval before the replacement is approved.

Approval alone is not a scheduling engine. The implementation must specify how the paired changes are released together, how time is interpreted and what happens if release delivery fails. The sample validator checks the resulting snapshots; it does not provide transactional publication in a real CMS.

After approval and release of the pair, test October 31, November 1 and November 2. Standard/CA should resolve to not_included, available and available respectively. Enterprise/CA should remain available across all three dates. Both US views should remain unknown. Those unchanged answers are as important as the new one: they show that the update did not spread beyond its intended context.

Reject a release containing A-05 as approved while A-02 still has an open-ended period. Both would match after November 1. Also reject a release that ends A-02 on October 31 but starts A-05 on November 1, because an exclusive end date would leave October 31 uncovered.

This exercise exposes a useful question for the redesign team: can editors preview a proposed set of related changes together? If the chosen implementation cannot support that safely, simplify the release process or build an explicit staging mechanism. Do not conceal the limitation beneath a field called scheduled.

Editor task three: retire a feature without erasing its history

Retirement creates a different problem. Suppose the fictional product team retires F-17 after a later replacement. Removing the Feature record immediately would leave four Page references pointing at nothing. Leaving every page untouched would keep presenting a retired capability as a current reason to buy.

First, identify inbound references. Separate current sales pages from pages with a legitimate historical purpose. Our four active marketing views should stop promoting F-17. A dated release-history page, if the team deliberately maintains one, may still need to describe what existed at that time.

For the exercise, create a retired snapshot in which F-17 has lifecycle retired. Remove it from the current Page feature lists through an approved page revision. Preserve F-17 and its evidence in the editorial record. The validator fails if an active current Page still references the retired feature.

If historical display is required, model it explicitly. A historical page needs an as-of date and a clear historical label; it should not accidentally resolve today’s state. Our small sample does not implement that extension. Its retirement test proves that current references are cleared and the underlying record remains recoverable for editorial history.

Do not use content-model retirement as an automatic instruction to delete a public URL or change its search treatment. A feature record, a page and a URL have different lifecycles. Decisions about page usefulness belong in a content audit and editorial backlog, with URL and redirect decisions handled in the wider redesign plan.

Ask the editor to explain the difference between remove from this page, retire this feature and delete this record. If the interface presents those actions as interchangeable, the model has not yet been translated into a safe editing experience.

Try the editor’s work, not just the database

Give someone who did not design the model a short task card: “Explain whether Approval history is included on Standard in Canada, then prepare next month’s proposed change without changing today’s public answer.” Watch where they hesitate.

If they open F-17 and cannot find a plan field, they may think the model is missing something. The interface should make the Availability relationship discoverable. A helpful label might be “Where this feature is included,” followed by the plan, region and effective period. Raw record IDs alone are poor navigation for most editors.

If they duplicate F-17 to create a Standard version, ask why. Perhaps the relationship editor is too hard to find. Perhaps the product really does have materially different behaviour by plan and the shared explanation needs reconsideration. A usability test can reveal either a poor interface or a wrong boundary. Do not assume every workaround is user error.

Ask them to locate the fact owner and explain the evidence reference. Then preview both a positive claim and an unknown state on a narrow screen. A model that passes a schema check can still fail if the qualification is far below the claim or hidden inside a collapsed section.

Record actual friction: the field they misunderstood, the duplicate they created, the page they forgot to inspect. Revise labels and relationships, then rerun the same task. “Editors liked the prototype” is less useful than “the editor prepared the draft change and correctly identified that both US views remain unknown.”

The goal is not to make editors memorize the diagram. It is to make the correct task easier than an unsafe shortcut.

Translate the tested model into the platform

Only now choose the implementation details.

In WordPress, developers can register custom post types and retrieve and render their content. That provides a possible foundation for Product and Feature records. The WordPress custom post type documentation describes those mechanisms. Availability relationships, field validation, effective-date resolution and the editing interface still need deliberate implementation; the existence of a custom post type does not supply the whole model.

WordPress also uses roles and capabilities to control actions. Its roles and capabilities documentation is the relevant starting point. The organization’s review responsibilities must be mapped to tested permissions and an actual publishing process. Do not assume that adding a Reviewer label creates a multi-step approval workflow or prevents every indirect publishing route.

Contentful describes a content model as the collection of content types in a space, with reference fields linking types. Its documentation on content models and references provides a different possible implementation vocabulary. References can connect a single entry or multiple entries. The particular plan, configuration, application and frontend determine how the full editorial and delivery process works.

Neither example makes this model a ready-made entitlement system. A marketing record saying available must never be treated as authority to grant an account access to a software feature. Product access belongs in the appropriate application controls. Likewise, a CMS publication event is not proof that every rendered route, cache or build has delivered the new content.

Keep the platform decision separate from this exercise. If that decision is still open, use the B2B website platform decision guide for the broader discussion. For WordPress ownership, operating controls and architecture, continue with the enterprise WordPress guide. Here, the decision is narrower: can the selected implementation represent and test these facts without losing their conditions?

Leave the workshop with a package someone can build

The useful output is a small, inspectable package: the four-type relationship model; a complete field dictionary; the fictional sample records; the failed global-checkbox example; current, draft, released and retired snapshots; and the expected outcomes for each editor task.

Download the HarbourGraph Content Model Workshop (ZIP), including the field dictionary, fictional records and offline validation script. Its 44 checks validate the supplied synthetic examples; they do not certify a real CMS or production release.

Include the unresolved decisions as well. Who confirms a previously unknown region? Does a release need a precise local time? Which destinations use the explanation? Can the chosen publishing process release related changes together? Will historical pages exist, and how will they resolve an as-of date? An unanswered question written down is safer than a default nobody remembers choosing.

Give each open decision a responsible role and a consequence. For example: “Product lead to define evidence required to change US from unknown; until then, no positive US availability claim.” Or: “Web team to demonstrate paired publication of A-02 and A-05; until verified, the proposed Standard launch remains a preview.” These are concrete blockers, not a generic governance checklist.

The sample script accompanying this workshop checks record references, date intervals, approved-state selection and the three task outcomes. Its passing result proves those synthetic inputs satisfy those tests. It does not certify a real website, security boundary, publishing workflow or cache system. The final implementation needs the same tests against its real editing and delivery paths.

Add the package to your website project brief so that content relationships and acceptance criteria are part of the work being commissioned. Keep the broader website redesign checklist for the rest of the launch.

For an enterprise redesign, bring the model into the first template discussion. Canada Create’s Toronto web design service provides the relevant project starting point, with WordPress development as an implementation route where appropriate. The useful brief is specific: here are the facts we share, here are the conditions that change them, and here is how an editor must be able to prove the right answer reaches the right page.

A good content model earns its place by surviving those edits. Before building thirty pages, make one shared fact pass the test.

Before anyone answers, ask which number fell.

A decline in Google Search clicks, a decline in recorded analytics sessions and a decline in qualified enquiries describe different problems. They can happen together. They can also disagree. Restoring yesterday’s deployment because today’s dashboard looks worse can leave the real problem untouched while creating another one.

The first job is to establish what changed for visitors and search engines, locate the loss, and find a defect that the team can reproduce. A verified fault deserves attention without waiting for an arbitrary recovery period. A percentage alone does not tell you which deployment to restore.

This guide follows one invented investigation from the first alarming report to a repair decision. Meridian Signal, a fictional Toronto enterprise AI vendor, has migrated 60 marketing and resource URLs. Every company detail, URL, traffic figure and test observation in the example is synthetic. Nothing here describes a Canada Create client or an actual Google inspection.

If your migration has not launched, start with the website migration checklist. If you are still deciding what a redesign should change, use the website redesign checklist for Toronto businesses. Here, the launch has happened. We need to understand the evidence it left behind.

The first report does not yet describe the incident

Meridian Signal’s marketing lead reports that organic traffic is down after the move. Engineering sees a working homepage, successful deployments and no obvious outage. Sales wants to know whether next month’s pipeline is at risk.

All three perspectives matter. None establishes the cause.

Give the initial report a more precise shape: “Google Search Console clicks for the defined 60-URL migration cohort fell from 1,800 to 1,404 between the selected comparison periods.” That statement identifies a source, a population and a difference. It is a much better starting point than “the new website lost 22% of our business.”

The cohort might not cover the whole website. Search clicks are not customers. The periods might still need adjustment. Those limits belong beside the finding, rather than in a footnote added after someone has approved a rollback.

For a real incident, preserve the first export and write down:

• The reporting property, date ranges, timezone convention and extraction time.
• The search type, countries, devices and other filters included.
• The URLs included in the migration cohort and the rule used to select them.
• The deployment time and any later releases or configuration changes.
• The current customer-facing symptoms, if any, with reproducible examples.

Keep the raw export separate from the working analysis. If another person changes a filter tomorrow, you should still be able to reproduce today’s statement.

For Meridian Signal, assume two equal-length reporting periods with the same weekday mix and a fixed Web Search scope. They are teaching periods, labelled A and B, not dates from a real account. The launch boundary is excluded from both. That makes the arithmetic readable; it does not establish that demand or competition was identical.

Keep three instruments separate

Search Console records activity in Google Search. Analytics records activity according to its own collection and reporting configuration. A lead system records submissions, routing and qualification under another set of rules.

Treat these as separate instruments pointed at related parts of the journey:

• Search clicks help locate changes in acquisition from Google.
• Analytics sessions help investigate recorded on-site activity.
• Enquiries and qualified leads help investigate commercial consequences.

Do not divide one instrument’s total by another and call the difference missing traffic. Search Console has its own definitions for clicks, impressions and position; the same labels should retain those definitions throughout an investigation. Google’s performance metric definitions are the reference for that report.

At Meridian Signal, the analytics decline on product pages is larger than the Search Console decline. The consent and tag deployment also changed at launch. That creates a measurement hypothesis worth testing. It does not prove that the gap consists entirely of unrecorded sessions.

The next useful question is specific: can the analytics owner reproduce the expected collection behaviour on affected and unaffected templates under the relevant consent states? Preserve that result in the analytics investigation. Keep it beside the search investigation, without using it to explain away the search loss.

A similar discipline applies to enquiries. If the form stopped delivering submissions to the CRM, the team has an operational problem even if search clicks remain steady. Conversely, fewer qualified leads could reflect a change in visitor mix without a form defect. Test the journey and inspect the receiving system before declaring either explanation true.

The old URLs are not the whole story

Your first choice is whether to investigate the disappearing old pages or reconstruct where their visitors were supposed to go.

Choose the second.

A report filtered to an old directory can look disastrous after that directory has deliberately been replaced. The disappearance is real within that filter. It does not establish the disappearance of the visitor task.

Meridian Signal moved a review product page from https://meridiansignal.example/solutions/review/ to https://meridiansignal.example/products/review/. Both are intended to help a prospective buyer evaluate the same product. They belong to one task-equivalent pair.

For each comparison period, account for the old and new members of that pair under one consistent reporting scope. In the synthetic data, the review pair has 25 clicks in period A and 15 in period B. Its period B total consists of 3 attributed to the old address and 12 to the new address. Looking only at the old address would turn a 40% pair-level decline into a misleading 88% decline.

Another product pair moves from 25 to 25 clicks while its old address falls from 25 to 0. That pair has changed address without losing clicks in this illustration. It is a useful counterexample to the assumption that every vanishing old URL is an incident.

Google’s migration guidance recommends monitoring the old and new sites and checking URL mappings and redirects. Search fluctuations can occur while a move is processed. Neither point establishes that every loss is harmless or that a particular site will recover. Google’s guidance for moves with URL changes supports checking the transition rather than judging an old address in isolation.

Pair the task, then reconcile the totals

Start with the actual redirect map if one exists. Treat it as an intention that needs verification. A spreadsheet row saying “old review page to new review page” does not prove that the production redirect behaves that way.

Add a stable pair identifier, old address, intended destination and visitor task. Separate exact replacements from consolidations and genuinely retired content. A many-to-one consolidation needs a group-level comparison: adding the same destination’s clicks to every old URL would inflate the result.

This guide’s dataset uses 60 mutually exclusive pairs. There are no merged destinations, duplicate rows or overlapping properties. Real accounts may be less tidy. If a Domain property and a URL-prefix property cover the same activity, adding their totals can double count it. Choose a reporting basis, document it and reconcile the pair totals against that basis.

There is another boundary to preserve: the full property chart and a selected URL cohort are not automatically the same population. If the property gained new pages outside the migration cohort, keep those additions visible separately. Otherwise, new content can conceal losses within the moved pages, or excluded pages can make the cohort appear worse than the whole site.

When the mapping is incomplete, say so. An “unresolved mapping” group is more honest than forcing unrelated pages into pairs to make the spreadsheet balance. Give the unresolved group an owner and investigate it before making a sitewide conclusion.

If the pre-launch baseline is missing

You can still investigate a broken page without a perfect before-and-after dataset. What changes is the strength of the conclusion you can draw about lost traffic.

Start with records the organization already has: reporting exports, the approved URL map, versioned content, release notes and retained application logs. Record where each came from and what period it actually covers. A content export can establish what a page used to say; it cannot reconstruct search clicks that were never retained.

Keep reconstruction separate from observation. If someone remembers that a product page was important, label that as a lead to investigate. Do not assign it an invented baseline because the analysis needs a number. If only 38 of the 60 pairs have a defensible prior-period record, report that coverage explicitly and analyze the remaining pairs as a separate evidence gap.

The same principle applies when the team cannot access the old property. A current redirect trace can establish the route now. It does not establish how that route behaved on launch day. A surviving deployment artefact may narrow the uncertainty, but the investigation should not claim a historical test that nobody performed.

This keeps the work moving. You can correct a verified current defect while leaving its historic traffic contribution unresolved. The absence of perfect measurement should not become a reason to leave a broken customer journey in place.

One percentage hides three different stories

The 60-pair total is down 22%. Split it by the templates and purposes that changed during the migration:

• Forty product and use-case pairs: 1,000 clicks before, 600 after. Change: minus 400, or minus 40%.
• Ten documentation pairs: 500 before, 510 after. Change: plus 10, or plus 2%.
• Ten editorial pairs: 300 before, 294 after. Change: minus 6, or minus 2%.

Together, 1,800 becomes 1,404. The net difference is minus 396 clicks; minus 396 divided by 1,800 is minus 22%.

The product group loses 400 clicks while the other two groups together gain four. That is why the product loss is slightly larger than the net cohort loss. It is an accounting relationship, not evidence that one product template defect explains everything.

The next investigation should concentrate on the product group. It should not begin by rebuilding the documentation area, which has a different observed result.

Within the product group, look for another useful split: a shared template, an import batch, a locale, a URL depth or an important customer task. Prefer categories that could connect to something the release changed. A long list of arbitrary slices creates charts without bringing the team closer to a testable explanation.

Keep absolute changes beside percentages. A page that falls from two clicks to zero has a larger percentage decline than a page that falls from 200 to 120. Both may matter, but the latter has a larger contribution to the observed total. Business importance can still change priority: a low-volume page supporting an essential customer task may need immediate attention.

Check whether the comparison itself moved

A launch can coincide with another change. Before assigning all variation to the migration, ask what would make the chosen periods a poor comparison.

For a Toronto business, a Canadian holiday, a campaign launch or an enterprise buying cycle may affect the audience. An international SaaS site may have a different country mix after launch. A branded announcement can temporarily increase searches for the company while non-branded demand moves another way.

Google identifies several possible causes of search declines, including technical issues, changing demand, ranking changes and reporting anomalies. Its troubleshooting guidance recommends examining the pattern rather than treating every downturn as the same event. Google’s guide to debugging search traffic drops provides that broader context.

Use those alternatives to improve the investigation, not to create an excuse for inaction. If product pages have a reproducible indexing defect, a holiday does not make the defect acceptable. If no defect has been found, a launch date alone is not enough to prove technical causation.

For Meridian Signal, documentation is a useful comparison family because it did not show the same aggregate decline. It is not a randomized control group. Its audience, queries and release changes differ from those of the product pages. The strongest next step is to compare examples within the product family as well.

Use query groups to ask better questions

Page families show where the loss sits. Query groups can help clarify which searches changed.

Separate branded queries, product-category queries and specific use-case queries when the available data supports that distinction. Keep the grouping rule consistent between periods. Do not silently move awkward queries between categories until the chart tells a preferred story.

For example, if the review page loses searches about review workflow while keeping branded navigational searches, compare the old and new page’s explanation of that workflow. If the new page replaced practical details with a short brand message, the content change deserves investigation. That is a hypothesis about relevance, not a reason to restore every sentence of the old site.

Preserve an “unclassified” group. Query-level reporting has limits, and a classified query export need not reconcile perfectly with every property total. State what the exported rows cover. Google explains that report aggregation and table totals can differ in its Search Console report overview. Do not manufacture missing queries or represent a partial list as a complete explanation of the loss.

Twelve pages share a concrete defect

Now choose between two responses: request indexing for all 60 destinations, or test examples that can distinguish competing explanations.

Test the examples first.

In the investigation, the team examines the 40 product destinations and records unintended noindex observations on 12. The selected product controls and the documentation control do not show that condition. These are generated teaching observations, not a record of an actual crawler run.

That is a meaningful finding. The intended public product pages are giving an instruction that conflicts with their intended search availability. Google documents noindex in page metadata or response headers and explains that it must be accessible to the crawler to be processed. A robots.txt block is not an interchangeable way of expressing the same instruction. Google’s noindex documentation explains the distinction.

But twelve affected destinations do not establish the share of lost clicks caused by that defect. Twelve of forty pages is 30% of a page count, not 30% of traffic loss. The affected URLs may have different histories, demand and indexing states. Other product pages in the synthetic dataset also lose clicks.

The right conclusion is narrower and more useful: “We have found a reproducible condition on intended public product pages that requires a source-level repair. Its contribution to the observed click decline remains unproven.”

Examine the route as well as the destination

For the review pair, record what happens when a visitor requests the old address. Does it lead to the intended review product page? Does the final page load successfully? Is the destination actually the same customer task, or merely a convenient place to send the request?

A successful HTTP response tells you something about delivery. It does not establish that the page contains the expected product explanation or that a prospect can complete the next step. Google also distinguishes successful responses from error handling, including pages that look like errors while returning a success status. Google’s HTTP status documentation is the primary reference for crawler behaviour.

Save the redirect route independently of the rendered-page check. A final screenshot can hide an unnecessary intermediate hop or a destination mismatch. Equally, a clean route can lead to the wrong content. Each observation answers a different question.

Do not turn the investigation into a race to make every cell green. If the page was deliberately retired and has no appropriate replacement, its treatment requires a content decision. Sending every retired address to the homepage simply makes the route look busy without establishing that the visitor’s need has been preserved.

Record what the page exposes now

For the affected review destination and the controls, capture the response status, relevant response headers, page-level indexing instructions, intended canonical address and rendered product content. Check whether essential navigation reaches the destination and whether the next customer action works.

The purpose is comparison. If the review page and another product page share a template but emit different indexing instructions, examine the difference in their content records or configuration. If every page from one import batch has the same unexpected value, that batch becomes a stronger lead than “the platform is bad for SEO.”

Canonical checks need the same care. A declared canonical is a signal; it is not a command that guarantees Google will choose that URL. Compare the intended destination with the declaration and with the available indexed evidence before calling the problem resolved. Google’s canonicalization guidance explains the available signals and their limits.

In the example log, the twelve noindex observations share a migrated product-record flag. That shared condition is a proposed lead for engineering to verify. The public-facing symptom does not, by itself, prove which CMS field, template branch, response-header rule or cache layer generated it.

Keep live evidence and indexed evidence on separate lines

This distinction prevents a surprisingly common argument: one person says the page is fixed, while another says Google still reports the old problem. Both may be describing their evidence accurately.

A current response or live test concerns a present fetch. Search Console’s indexed information reflects Google’s stored information about the URL. Label the surface and record the relevant timestamps. Do not attach today’s date to an older crawl simply because you opened the report today.

Google says the live URL test does not predict all indexing conditions or Google’s selected canonical. A positive live result does not guarantee search appearance. Its URL Inspection documentation also distinguishes live results from indexed information.

For a real investigation, use a compact record with separate fields:

• Current response observed at: timestamp and method.
• Live inspection performed at: timestamp, result and limitations.
• Indexed evidence retrieved at: timestamp.
• Indexed crawl time shown: the tool’s reported time, if available.
• Difference requiring explanation: a plain-language description.

If a field has not been checked, write “not checked.” A blank cell is too easily mistaken for a passing result. In the example files accompanying this guide, inspection fields are deliberately marked illustrative or not performed. There is no fabricated Search Console screenshot or claim that Google visited the fictional domain.

Download the synthetic 60-pair migration dataset and illustrative test log (ZIP). Meridian Signal and every observation in these files are fictional; no actual Google inspection, repair or recovery was performed or observed.

Choose controls that could change your mind

A useful control is not simply a page that looks healthy. It is a comparison chosen to challenge a specific explanation.

For Meridian Signal, an unaffected product destination using the same template can help test whether the whole template emits noindex. A product destination from a different import batch can help test whether the import is the relevant boundary. A documentation page can reveal a broader delivery failure, but it is less useful for isolating a product-record setting.

Write the expectation before running the comparison. If the proposed explanation is “all pages using this template have the fault,” then finding an exception means the explanation needs revision. Preserve the exception. Do not drop it from the test set because it complicates the ticket.

Also distinguish “the selected controls passed” from “every other page is unaffected.” A sample supports a statement about the tested examples. A broader claim needs broader coverage. For the invented 40-page product cohort, checking every destination is manageable; a real site with thousands of variations may need a risk-based sample followed by a scoped expansion.

Record why a URL was selected: reported failure, important customer task, shared implementation, or intended exclusion. That small note makes the test set auditable. It also helps the next engineer add an example that tests a new hypothesis instead of repeating checks that cannot distinguish the remaining possibilities.

Repair the verified condition without widening the incident

Once engineering has traced the unwanted instruction to its source, the next question is the smallest safe change that restores the intended behaviour.

For Meridian Signal, the proposed repair targets the migrated product-record flag for the twelve intended public destinations. It does not globally remove indexing controls. Other pages may have legitimate reasons to remain excluded. An emergency change that makes private, duplicate or unfinished material discoverable would expand the incident.

The implementation owner should verify the source hypothesis before approving the patch. If the condition actually comes from a response-header rule or a cached template, editing a content field may not fix it. The repair should follow the evidence to the emitting layer.

Build the test set before deployment. Include all twelve known affected URLs, other product URLs that did not show the fault, a documentation control and any intentional exclusions that the proposed change could touch. Testing only the originally reported page is insufficient when the fix changes shared behaviour.

Use the organization’s normal release authorization. A marketing request to investigate a decline is not a blanket instruction to overwrite production. Preserve the old configuration, document the proposed scope and identify how the patch itself can be reversed if it causes a regression.

After an authorized release, repeat the relevant checks on the live destination. Compare the output with the saved pre-fix evidence. Check the old route again, the final page content, the indexing instruction and the customer action. Record what passed and what remains unchecked.

The useful completion statement is technical: the unwanted instruction is no longer present on the verified affected set, and the defined controls still behave as intended. It is not yet a claim that rankings or leads have recovered.

A handoff an engineer can act on

The following is an illustrative repair request, not an instruction to change any live site:

• Example pair: https://meridiansignal.example/solutions/review/ → https://meridiansignal.example/products/review/.
• Intended task: evaluate the review product and reach its enquiry path.
• Observed condition: an unintended noindex instruction on the public destination in the synthetic test log.
• Known scope: twelve of forty product destinations show the condition; contribution to click loss is unknown.
• Proposed source investigation: trace the migrated product-record flag through the template, response headers and relevant cache behaviour.
• Proposed fix: correct only the verified source and affected public records after review.
• Reviewer: the designated engineering release owner, with the SEO owner checking intended search behaviour.
• Reversal plan: restore the prior patch configuration if validation identifies a new defect, while preserving the evidence and any new content or submissions.
• Verification: affected set, unaffected product controls, documentation control, intentional exclusions and the enquiry journey.

Attach a saved response sample, a reproducible test description and the mapping row. Keep the technical ticket small enough that the receiving engineer can tell what is known before reading a longer analysis.

When does rollback deserve consideration?

A rollback deserves consideration when the current deployment is causing a verified problem and the team has evidence that restoring a known state is a safer way to address it than a targeted repair. That is a deployment assessment, with customer and data consequences.

It is not an automatic response to a traffic percentage.

Suppose a launch has broken a critical enquiry route across the site, and the implementation team cannot safely repair it in the current release. A tested restoration path may deserve urgent review. Suppose instead that twelve product records emit one unwanted instruction and a scoped repair can be validated. Reverting the CMS, navigation, integrations and content together may introduce much more change than the observed defect requires.

Those are scenarios for assessing options, not universal rules. The people responsible for the running system must judge the real dependencies and authorize the deployment.

Ask what would actually be restored

“The old site” sounds like a single object. It may involve application code, a database, uploaded files, redirects, configuration, DNS, integrations and third-party settings with different histories.

Since launch, people may have submitted forms, edited product content, uploaded documents or changed access permissions. Restoring an old database without a reconciliation plan can discard legitimate changes. Restoring old code against a newer data structure can create another failure. Reversing a domain move can also leave the URL transition more complicated.

Before approving a restoration, collect the evidence that answers these questions:

• Which customer task is currently failing, and how can someone reproduce it?
• Which verified defect would the restoration remove?
• Which parts of the system must change together, and which must remain current?
• What data or configuration has diverged since the proposed restore point?
• Has the restore path been tested in a suitable environment?
• Who can approve it, execute it and validate the result?
• What happens if the restored version fails its own checks?

A backup file is evidence that something was saved. It is not proof that a safe restoration has been rehearsed or that newer data can be preserved. The decision packet should expose that uncertainty before a production action, not after it.

Keep repair, observation and restoration as distinct options

If there is a verified defect with a bounded repair, evaluate that repair. If the site’s intended behaviour checks out and the remaining question concerns search processing or demand, continue a defined observation and investigation plan. If the current deployment has a serious defect and no safe scoped repair, assess restoration with the authorized owners.

Observation is not “wait and hope.” It needs a question, evidence to collect and a trigger for reassessment. For Meridian Signal, the question after the repair would be whether subsequent search evidence changes for the affected pairs, and whether unexplained losses remain elsewhere in the product cohort.

A new customer-facing failure should change the priority immediately. An unchanged traffic report should prompt examination of what it can and cannot yet establish. Neither response requires pretending that every migration follows a universal 30-, 60- or 90-day recovery schedule.

A repaired page is not a recovered business result

The investigation ends with a proposed repair path, subject to release approval, and a way to verify it. It does not end with an invented upward curve.

Keep three closeout statements separate:

1. Technical condition: what was changed and what the post-release checks observed.
2. Search outcome: what later reporting and indexed evidence show for the same paired cohort.
3. Commercial outcome: what happened to enquiries and qualified leads under a stable measurement definition.

An organization can complete the first while the other two remain unresolved. That is an honest status, not an incomplete explanation to hide from leadership.

Preserve the original comparison alongside the follow-up. Keep the 60 pair identifiers stable. Annotate subsequent releases, measurement changes and material content edits. If you revise the cohort, publish a new version of the analysis rather than quietly replacing the original denominator.

Continue examining the product pages that did not share the noindex observation. Their losses were part of the initial finding too. The repair may be correct while other explanations remain open: content changes, destination mismatch, demand, changed search presentation or another technical condition. Select the next check from the remaining evidence.

Write the update so it cannot be mistaken for a guarantee

A useful illustrative update would say:

“Across the defined 60-pair cohort, clicks declined from 1,800 to 1,404 in the selected periods. The product group accounts for a loss of 400 clicks, partly offset by the other groups. Twelve product destinations showed an unintended noindex condition in our test scenario. The proposed repair addresses that condition after source verification and release approval. The proportion of the click loss caused by it, and any subsequent recovery, are not established.”

That update gives leadership something to act on without promising a return date. It also keeps the analytics discrepancy open for its own investigation instead of burying it under the technical finding.

If the content investigation later identifies pages needing a broader editorial decision, move that work into a separate SEO content audit. Do not turn a migration incident into an unapproved deletion program.

Make the next decision smaller and better supported

When organic traffic drops after a website migration, the most useful first deliverable is a clear explanation of what is known, what is broken and what evidence is still missing.

Name the measurement. Reassemble the old and new URLs around the same visitor tasks. Locate the loss before choosing the test set. Compare affected examples with relevant controls. Repair a verified condition at its source through an authorized release. Treat rollback as a separate deployment decision with its own risks.

For a Toronto enterprise or SaaS team, the difficulty is often the boundary between marketing evidence and engineering action. A strong investigation makes that boundary workable: one agreed cohort, reproducible examples, explicit owners and a closeout that distinguishes technical restoration from search and commercial outcomes.

If your team needs help turning a post-migration decline into a scoped investigation, discuss the evidence with Canada Create’s Toronto SEO team. Bring the launch date, the old-to-new URL map, the affected reporting exports and the release owner. The next step should follow what those records show.