Written answers to the questions buyers actually type. Each one opens with a summary that stands on its own, and is dated so you know how current it is.
The project ends on a Friday. On Monday somebody emails a screenshot of a number they do not like, and nobody has decided who reads that email.
Most BI programmes fund delivery and assume support. What actually happens is that whoever built the thing keeps answering questions, informally and without capacity, until they leave or stop replying. A workable model has three tiers with a written boundary between them, a named owner per dashboard, and an explicit rule for the request type that is really a new build. Two of the three tiers can be substantially automated. The middle one cannot, and it is where the cost is.
The report is right, the platform is right, and the client is right to be annoyed. All three can be true at once.
A client compares your dashboard to the platform, finds a different number, and stops trusting the report. In most cases nothing is broken: the two are looking at different date ranges for reasons Looker Studio does not surface. Default ranges vary by connector, today is excluded unless you check a box, weeks start on Sunday unless you pick a different preset, the date dimension may not be the field the client means, and a control only governs the page it sits on. Each of these is documented. Each takes a minute to fix, and none of them fixes itself.
Preview is not production with a debugger attached. It is a different session, on a different container state, with different permissions.
A tag that fires in preview and not in production is not mysterious, it is a short list. The version was never published, preview attached to a workspace rather than the live container, your own session behaves differently from a visitor's, a security policy blocks something in one context, an ad blocker is only present in one, consent was granted only in the test, or the server-side preview server is running a different configuration. Each has distinguishing evidence.
Green in DebugView is evidence about your browser in the last minute. It is not evidence about your customers.
DebugView shows events from devices with debug mode enabled, with full parameter detail, which makes it the right tool for verifying a tag you are building. Realtime shows activity from everyone in the last thirty minutes with far less detail, which makes it the right tool for confirming a deployment is live. Both perform only limited attribution analysis, both hide events where consent was refused, and neither tells you whether a parameter will ever appear in a report.
A budget alert tells you that you crossed a line. It does not tell you how fast you were going, and it does not stop the car.
A Cloud Billing budget defaults to alerting at 50, 90 and 100 percent of the amount, by email, to Billing Account Administrators and Billing Account Users. Each of those defaults is wrong for an agency running client warehouses: the thresholds are percentages of a month rather than a rate, the recipients are usually finance rather than the person who can fix it, and the alert is lagging. Add a rate-based alert, route it to a named human, and put a hard quota underneath.
Most of what gets called deduplication is three unrelated problems wearing the same word.
One order can appear as several conversions for five different reasons, and only one of them is fixed by a deduplication key. A transaction ID matches duplicates within a single conversion action. It does nothing about two conversion actions counting the same outcome, and nothing at all across two platforms that never shared an identifier. Naming which kind you have is most of the work, because four of the five have no dedupe key available and need a different fix entirely.
The increase is not the hard part. The hard part is that you never told them one was coming.
A price increase lands badly when it arrives as news. It lands normally when the agreement anticipated it, the basis is stated in advance, and the evidence is public. Index-linked increases are the easiest to defend because the reference data is published by someone other than you. Value-based increases are stronger but require evidence you have to have been collecting all year.
Most capacity plans fail at the first line, because they start from a number of weekdays nobody will ever work.
A capacity plan is a subtraction, not a forecast. Start from calendar weekdays, remove statutory time off, remove the non-delivery work your team is already committed to, and what remains is what you can sell. The Ontario Employment Standards Act fixes several of the deductions, so those rows can be filled in exactly. Everything else has to be measured rather than assumed, and this article says which is which.
A cadence you announce is a preference. A cadence your tooling enforces is a standard.
Ad-hoc client interruption is not a discipline problem, it is a design problem. Clients interrupt when they do not know when the next scheduled contact is, or when the scheduled contact does not carry the information they need. The fix is a small number of commitments that a tool can actually enforce: a working calendar attached to response targets, a scheduled delivery with a known date, and a stated rule for what counts as urgent.
The report is not changing its mind. It is finishing a sentence it started three weeks ago.
Google Ads records a conversion against the date of the ad interaction that led to it, not the date it happened. Recent periods are therefore incomplete by definition, and they keep filling in for as long as the conversion window allows. Once you measure your own lag, most arguments about numbers that changed since last week resolve themselves, and several bidding and reporting decisions get better.
The clock starts the day the request arrives, not the day somebody forwards it to the person who can act on it.
Under federal privacy law an individual can ask an organisation what personal information it holds about them, how it has been used, and which organisations it has been disclosed to. The response is due in 30 calendar days, with a single extension available in defined circumstances. Most marketing teams have never tested whether they could produce that answer, and the systems that make it hard are the ones nobody thinks of as customer records.
Every rule you add is a permanent, invisible transformation that lives in one vendor's interface and is not in any repository you control. That is not a reason never to use one.
Feed rules in Merchant Center let you rewrite product data on the way in, which makes them the fastest fix available for most feed defects. The cost is that the correction now lives in a place your engineering team does not read, does not version, and cannot test. The right decision depends on whether the defect is a data problem or a channel problem, and on how many rules the account already carries.
The import is good. The problem is that it is good enough that nobody checks the parts it could not bring.
Microsoft's Google Ads import moves campaigns, ads, targets and extensions across in one job, and it can be scheduled to repeat. What it cannot do is tell you what it left behind. This walks the documented behaviour: the credential scope that invalidates without warning, the budget adjustment options, the entity types that get added to future imports without you opting in, and the tracking templates that arrive intact and resolve to nonsense.
The old theming logic assumed a keyword was a promise about which queries would arrive. It has not been that for years, and the ad groups built on it are quietly mismatched.
Google matches an exact match keyword to close variants of it, and the reporting keeps those in separate categories from the literal match. That breaks theming built on exact strings, because two keywords in different ad groups can pull the same query and serve different ads. The replacement is to theme by the thing that is still under your control: the landing page and the intent it serves. Ad groups become message and destination units, and the keyword list becomes the coarse steering mechanism it now is.
A bilingual customer is not half an English customer and half a French one. They are one person who chooses a language per search.
Language targeting in Google Ads does not partition a Canadian audience, because a large share of the audience understands both official languages and picks one per search. That single fact decides most of the structural choices: separate campaigns rather than separate ad groups, keyword lists sourced from French copy rather than translated from English, and reporting that keeps the French programme visible when its volume is a fraction of the English one.
The cheapest extract to build is usually the most expensive one to keep working.
There are five practical routes for getting SAP data into an analytics platform, and they trade off along the same axis: how much work the SAP system does, versus how much your team does, versus how likely the extract is to break at the next upgrade. Direct table reads are the fastest to build and the fastest to break. Extraction-enabled views cost more up front and survive. Choose knowingly.
The load will partially fail. Design for that before you start, not at 2am when it does.
Above a few thousand records, the synchronous Salesforce APIs stop being appropriate and the asynchronous Bulk API takes over. It accepts CSV, processes in batches, and returns per-record results, which means partial failure is the normal case rather than an exception. This covers when to switch, how the two Bulk API versions differ, the pre-flight checks that prevent most incidents, and what to do with the failed rows.
The transformation that produces the revenue number is edited in a browser, by one person, with no review and no way back.
Analytics work is code with none of the engineering practice around it: no review, no test, no history, no rollback. A pipeline for SQL and measurement configuration is worth building, but the pipeline is not the control. Branch policy is. A required reviewer on the branch that feeds production catches more defects than any automated check, and it costs nothing. Start with one check and one protected branch rather than a full deployment pipeline.
The problem with risk registers is never the template. It is that nothing in the week forces anyone to open one.
A risk register survives when the process around it is designed, not when the spreadsheet is well formatted. That means a hard cap on rows, one named owner per risk, review triggered by events rather than by calendar, a rule for closing risks, and a visible link between a risk and a decision someone made. Registers with forty rows and no owners are abandoned within a month, every time.
Nobody complains about the information architecture. They complain that they cannot find the thing, which is the same complaint.
Confluence rarely fails because the hierarchy is wrong. It fails because there are three plausible places a document could live, nobody agreed which one, and search returns four versions of the same page with no way to tell which is current. The fixes are unglamorous: fewer spaces, one hierarchy rather than two, labels doing the cross-cutting work, templates carrying the labels automatically, and an archiving habit that somebody actually owns.
Write the article that answers the question you have already answered eleven times, and nothing else.
A knowledge base is not a documentation project. It is a targeted attack on the handful of questions that consume the most repeated time, and the only honest measure of it is whether those questions stop arriving. Built from a content plan, it becomes a graveyard. Built from the ticket queue, with a deliberate decision about what not to write, it pays back inside a quarter.
An assumption you cannot test on a given morning is not an assumption. It is a sentence you will lose an argument about in week nine.
An assumptions register only protects you if a broken assumption is detectable without a judgement call. That takes four fields per entry: the condition stated as a measurable event, an owner, a date or threshold, and the consequence priced in advance. This piece is the method behind the assumptions section of a scope document, plus what happens to the register after signature.
What clients call fixed scope is usually a fixed price and a fixed date. Those are far easier to honour.
The supposed conflict between agile delivery and fixed-price contracts comes from fixing the feature list. Clients rarely want a feature list; they want a defined outcome by a defined date for a defined price. Write the contract so the outcome, price and date are fixed and the implementation path is explicitly variable, then use the iteration boundary as the point where variation is agreed. The mechanism is a written trade at every boundary, not a change clause nobody invokes.
One page, enforced, beats twelve pages nobody has read. The obligations underneath it are not optional.
A small agency does not need a long AI policy. It needs a one-page document answering four questions: what client data may be sent to which tools, who approves output before it ships, when use must be disclosed, and what is recorded. The obligations underneath those answers come from Canadian privacy law rather than from vendor terms, and the Privacy Commissioner has published named principles that map cleanly onto a short internal policy.