Portal Integrators — Writing

Why Your LinkedIn Links Are Quietly Broken, and How to Catch It Before You Post

Thu, 30 Jul 2026 00:00:00 GMT

Click through an external link on a LinkedIn post recently and land on a blank page or an error screen? It happens far more often than people realize, and the person who posted it usually has no idea, because the post itself looks completely fine.

That's the actual problem. Not that links break. Links break everywhere, on every platform. The problem is that LinkedIn's preview box gives you no signal when it happens, so a broken link can sit on your profile for months, quietly undermining every piece of content attached to it.

Why the preview lies to you

When you paste a URL into a post, LinkedIn builds a visual card: an image, a headline, a snippet of text. That card looks correct in your draft, so you assume the link behind it is correct too. Three things break that assumption, all invisibly.

The redirect wrapper. LinkedIn doesn't publish your raw URL. It rewrites it through its own shortener, an lnkd.in link that redirects to your real destination. Most of the time this is invisible plumbing. When that redirect step hiccups, your link dies, and nothing in your draft ever showed you the wrapper existed.

Mobile rendering differences. A link that opens cleanly in a desktop browser can fail inside LinkedIn's own mobile app, often over a certificate mismatch the desktop version never encounters. You tested it once, on your laptop, and moved on. A meaningful share of your audience is opening it on a phone, inside the app, where you never tested it at all.

The cached preview. LinkedIn can keep showing an old image and an old title long after the actual page has changed, moved, or gone down entirely. The card in your draft isn't necessarily reading your site right now. It might be reading a cached memory of your site from whenever LinkedIn first crawled that URL.

Put those three together and you get the actual failure mode: you rarely click your own links after publishing, the preview gives you no reason to, and the gap between what a link looks like and what it does can persist indefinitely.

The three checks, before you publish

None of this requires LinkedIn to fix anything, which is good, because there's no indication they're prioritizing it. Ten seconds of verification before you post is simply cheaper than a dead link reaching your network.

Run it through Post Inspector. LinkedIn's own free tool at linkedin.com/post-inspector forces a fresh crawl of your URL and clears whatever it had cached. Paste your link there before you paste it into a post.

Open it incognito, right after publishing. Not in the browser tab where you're already logged in and half-remembering what the page looked like last time. A fresh, logged-out window, ideally on a phone, is the closest thing to what a stranger in your network actually experiences when they click.

Write the full https:// explicitly. Leaving off the protocol is the single most common cause of a link silently mangling into something that doesn't resolve the way you intended.

It's not just a human problem anymore

Everything earlier in this series has made one argument from different angles: the AI systems now answering questions about you and citing your content only know what they can actually reach. A dead link is that same failure in miniature, and it's not limited to the human who clicks it.

When an AI system crawls your posts, your articles, or your site, and follows a link that resolves to nothing, that source simply drops out of whatever picture it's building of you. It doesn't flag the miss or ask you about it, the same way a human reader doesn't leave a comment saying your link is broken. It just quietly moves on to whichever source did resolve, and that source, not yours, shapes the answer.

This is the same mechanism as an AI crawler hitting a JavaScript-rendered page and finding nothing to read, just at a smaller scale and a faster failure rate, because links rot constantly and nobody's checking. A business with excellent, accurate content behind a broken link is functionally identical, to both a human and an AI, to a business with no content there at all.

The habit worth keeping

This is a small, boring discipline, and boring is exactly why it works, which is the theme running through this entire series. A ten-second check before you publish is the difference between a post that represents you accurately and one that quietly doesn't, for as long as nobody, human or AI, happens to click it. Accuracy isn't just what you say. It's whether everything you point people toward still says it back.

Copilot Isn't Enough: Where Microsoft 365 AI Ends and Custom AI Begins

Tue, 21 Jul 2026 00:00:00 GMT

I've written six books about Microsoft 365, so let me start by defending it: Copilot is not hype. If your team lives in Outlook, Teams, Word, and Excel, Copilot removes real friction from real work. Summarizing a thread you were cc'd into too late, drafting the first pass of a document, catching you up on a meeting you missed. That's genuine value, and for a lot of knowledge work it's plenty.

The trouble starts when Copilot becomes the entire AI strategy. "We have Copilot" turns into the answer to every AI question, and problems that Copilot cannot touch get quietly filed under "solved." I see this constantly in operations, because operations is exactly where Copilot's boundaries live.

What Copilot is actually for

Copilot, meaning the assistant itself, as distinct from Copilot Studio agents, which I'll come to, is an assistant for a person working inside a Microsoft document or conversation. That sentence sounds obvious, but every word of it is a boundary.

A person. The assistant activates when a human asks it something. It doesn't run on its own at 6 a.m. because a shipment file arrived.

Working inside. It assists the work happening in the app in front of you. It's not watching your queue, your inbox, and your vendor portal simultaneously.

A Microsoft document or conversation. Its native ground is your M365 content. The moment the work involves your ERP, your industry-specific system, a customer portal, or the database only your longest-tenured admin understands, you're at the edge of the map.

Take one concrete workflow and hold onto it, because we'll carry it through the whole framework: a purchase order arrives by email, gets validated against the ERP, updates a tracking sheet, and triggers a notification in Teams. Keep asking where that PO fits as we go.

Stay: further than most teams have gone

The first zone is the one that costs nothing extra, and it covers more ground than people expect. If the work is a person working in M365 content (writing, summarizing, searching your own documents, meeting recaps), stay put and get better at it. Most companies haven't extracted half of what the license already offers, and the two highest-leverage moves aren't features at all. Teach the team a handful of prompt patterns instead of a prompt library. And fix the content Copilot draws from, because a well-organized SharePoint is the difference between impressive answers and confident nonsense from the same product.

Where does the PO workflow fit here? Partially. Copilot will happily summarize the email thread about a problem PO, or answer "what did we agree with this vendor last quarter" from your files. A person, present, working in Microsoft content. That's real help at the edges of the workflow. It is not the workflow.

Extend: where most teams actually land

The second zone is the live decision for most operations teams, and it deserves more attention than it usually gets. When the workflow is mostly M365 work that needs a connection, a trigger, or a scoped agent, Microsoft's extension layer is genuinely productive: Copilot Studio for building agents grounded in specific content, Power Automate for trigger-and-flow automation, connectors for reaching into other systems. This is where "it answers policy questions in the Teams channel" lives, and "when the form is submitted, route it with a summary attached," and the scheduled report that drafts itself.

The simple version of the PO workflow can genuinely live here: a flow watches the inbox, an AI step extracts the fields, the tracking sheet updates, Teams gets notified. If your version is that clean, extend and be done. The zone is right when the process is simple, the volume is moderate, and you want to stay inside the licensing and governance you already have.

Its limit is complexity, and the limit announces itself. Exceptions accumulate, the flow chart stops fitting on one screen, and every "except when" adds a branch someone has to maintain. Past that point, extension projects start costing custom-app money while delivering flowchart-tool flexibility. When the PO validation logic has real rules in it (tolerance thresholds, vendor-specific handling, escalation conditions), you've hit the ceiling.

Build: when the workflow is the application

The third zone is for workflows that cross systems as their whole job, run on your own structured data, or embed decision logic you need to control and audit. The full PO workflow, with validation rules that must behave identically on Friday afternoon and Monday morning, is an application. That's not a Copilot limitation to file a complaint about; consistency and auditability are application properties, and no assistant licensing changes that.

What has changed is the price of admission. Building a focused operations app used to mean a six-figure project, which is why these workflows stayed manual for a decade. It doesn't anymore: a small team ships this class of application in weeks now, using a pipeline I've written up separately, and the leaders still making the stay-or-build call with 2019 prices in their heads are leaving the most valuable workflows unfixed.

The test I give clients

If you're unsure which zone a problem lives in, ask: could one person do this task entirely inside Microsoft apps, and is a human present every time it happens?

Yes to both: stay, and get better at it. Yes to the first, no to the second: extend, and watch the complexity ceiling. No to the first: you're in build territory, and no amount of Copilot licensing will change that. Naming that boundary honestly is how you stop paying assistant prices for application problems, and application prices for assistant problems.

Where does your version of the PO workflow sit: stay, extend, or build? If you can't tell, that's usually a one-conversation answer. Ask me.

Five AI Use Cases Ops Teams Can Ship This Quarter

Tue, 21 Jul 2026 00:00:00 GMT

The AI use cases that make keynotes are the wrong ones to start with. The right ones are boring: high-frequency, pattern-shaped work that eats hours every single week and that nobody will miss doing by hand. Here are five that recur most reliably across operations teams, with honest notes on what each replaces, what it needs from you, and the effort in weeks.

The rule that generates the list matters more than the list. Every use case here has the same anatomy: unstructured stuff arrives (emails, documents, transcripts), a human currently reads it and turns it into structured action, and the pattern repeats constantly. That reading-and-structuring step is what current AI does well. Anywhere you find that anatomy in your operation, you've found a candidate, including ones I haven't listed.

1. Document intake

What it replaces: a person opening every incoming PO, invoice, work order, or application; reading it; and retyping its contents into a system or spreadsheet.

How it works: documents arrive (email inbox, upload, folder), AI extracts the fields you care about into structured records, and anything below a confidence threshold routes to a human for review instead of guessing.

What it needs from you: twenty or thirty representative sample documents, including the ugly ones, and a written list of the fields that matter. The human-review lane is not optional; it's what makes the system trustworthy on day one instead of month six.

Effort: 3 to 5 weeks. The extraction works out of the box with today's models; the weeks go to the review workflow and wiring the output into wherever the data goes.

2. Status report assembly

What it replaces: the person, often a senior person, who spends a chunk of every Friday pulling numbers from three systems and narrating them into the weekly update.

How it works: the report generates itself on schedule from live data, with AI writing the narrative summary: what changed, what's off-plan, what needs a decision. A human reviews and sends. The review step stays, the assembly disappears.

What it needs from you: access to the source data and, crucially, three or four examples of past reports you considered good. The AI's narrative is only as sharp as the examples that define it.

Effort: 1 to 2 weeks if your data is queryable. The hard part is usually data access, not AI. The fastest win on this list.

3. Meeting-to-task capture

What it replaces: decisions and action items evaporating between the meeting and everyone's task lists, and the follow-up messages asking who owned what.

How it works: transcripts (Teams already produces them) run through an extraction pass that pulls decisions, owners, and deadlines, then creates the tasks in your actual tracker. Not a summary document nobody opens. Actual assigned tasks.

What it needs from you: transcription turned on, a task system with an API, and a light human confirm step so mis-attributed items get caught.

Effort: 2 to 3 weeks. The extraction is well within current model capability; the integration into your tracker is the bulk of the build.

4. Vendor email triage

What it replaces: a shared inbox where confirmations, delays, price changes, and disputes all look identical until a human opens each one, and where the urgent ones wait behind the routine ones.

How it works: each incoming message gets classified (routine / needs action / urgent), key facts get extracted (order number, new date, amount), routine confirmations auto-file against their orders, and the genuinely urgent items surface immediately with the relevant history attached.

What it needs from you: a few hundred historical emails to define the categories, and clear rules about what the system may do alone (file a confirmation) versus flag (anything involving money or commitments).

Effort: 4 to 6 weeks. Classification is easy; the trust rules and the order-matching are where the design thinking goes. This one also compounds: every extracted fact enriches your vendor history.

5. SOP and policy Q&A

What it replaces: the walk across the office to ask the one person who knows. Every operation has a handful of people who serve as the search engine for how things are done, and their interruption load is a real capacity cost, plus a genuine risk when they're out or leave.

How it works: your SOPs, policies, and process docs become a searchable knowledge base the team can question in plain language, with every answer citing the source document so people can verify rather than trust blindly.

What it needs from you: documentation that's reasonably current. This project has a way of exposing that it isn't, which is itself useful. You'll also want a feedback loop for flagging wrong or outdated answers.

Effort: 2 to 4 weeks, including content cleanup. The standard patterns for this are mature.

One caveat on the fifth: if your documents already live in SharePoint, check whether this is Copilot territory before building anything custom. The stay, extend, or build question applies, and "stay" is sometimes the honest answer.

The point of the list

The list was never really the point; the picking discipline is. Don't pick the most valuable use case. Pick the most provable: a workflow with an owner who wants it, a baseline number you can capture this week (hours spent, cycle time, backlog size), and a blast radius small enough that a rough first version embarrasses nobody. Then put a decision date on the calendar the day you start, four to six weeks out to match the effort column, and compare against the baseline when it arrives.

One from this list, done completely, beats all five started. Which one is hiding in your operation? And if you'd rather try one than build one, a few of these already run as working apps on the main site.

How I Ship AI Apps: My Lovable → Claude Code → Supabase Pipeline

Tue, 21 Jul 2026 00:00:00 GMT

People ask how a one-person shop ships working AI products alongside consulting work. The honest answer is a pipeline with three stages and very clear rules about what each stage is allowed to do. Here it is, breaks first where they belong, because the breaks are why you can trust the rest.

The stack in one paragraph

Lovable builds the first version of the product: UI, pages, flows, the thing you can click. Claude Code handles everything after that: refactoring, build tooling, real features, anything where I need to see every changed line. Supabase sits underneath the whole time, providing the database, auth, and Edge Functions, which is where the AI itself lives via the Claude API. Deployment stays simple: the repo is the source of truth, and pushes go live.

Each tool is excellent at one phase and mediocre at the others. The pipeline works because I stop using each tool at the point where it stops being the best option, and that discipline matters more than the tool choices themselves.

Stage one: Lovable, for product shape

Where it breaks

Ambitious prompts. Ask Lovable for a visual tweak, get a visual tweak. Ask it for a cross-cutting change like restructuring state or modifying how data flows, and you're gambling. Version history makes the gamble survivable (note your version number before every risky prompt), but past a certain project size I stop gambling entirely and move to stage two.

What it's for anyway

Lovable's superpower is speed to something real. In a day I can have an app with actual screens, actual navigation, and a Supabase backend wired in, which means in a day I can discover that my tile layout is wrong, the flow has a missing step, or the feature I was excited about is actually confusing. Finding that out in day one instead of week four is the entire value.

The rule I hold myself to: Lovable is for shaping the product, not engineering it. I prompt in product language (what a screen shows, what happens when the user does X) and I resist the urge to prompt architectural changes. Lovable will happily attempt them, and that's exactly when it rewrites things you didn't ask it to touch.

Stage two: Claude Code, for engineering

Where it breaks

Context. On a bigger codebase, Claude Code can make a locally sensible change that violates a project-wide convention it didn't have in view. The other failure mode is mine, not the tool's: accepting a diff I skimmed instead of read.

What holds it together

Once the product shape is right, I connect the Lovable project to GitHub and shift my center of gravity to Claude Code. Same repo, different relationship: now every change is a diff I review before it ships. This is where the unglamorous work happens. Cleaning up the generated code (Lovable output is fine but repetitive; components want consolidating), adding things Lovable is weak at (build scripts, static generation, testing, performance passes), and building the features with real logic in them.

Two habits do most of the heavy lifting, and both exist because of the breaks above. First, a maintained CLAUDE.md in every repo listing conventions, architecture decisions, and things Claude Code should never touch. I keep it standardized across projects so every session starts oriented instead of exploring; it's the direct answer to the context problem, and it earns its keep every single session. Second, plan-first prompting: I ask Claude Code to inspect the code and confirm its approach before writing anything. That one habit prevents most of the "technically what I asked for, not what I meant" category of rework.

The layer underneath: Supabase, and where the AI lives

Where it breaks

Timeouts and streaming. Long AI generations bump against Edge Function limits, so anything heavy either streams to the client or gets broken into smaller calls. I learned both versions of that lesson in production.

The pattern that works

Supabase is the constant across both stages. Postgres, auth, row-level security, storage. But the piece worth dwelling on is Edge Functions, because that's where the actual AI runs.

Every AI feature in my products follows the same pattern: the client calls an Edge Function, the Edge Function calls the Claude API, shapes the response, and returns it. The API key lives server-side, never in the browser. The prompt lives server-side too, which matters more than people realize: it means I can improve the AI's behavior, tighten the output format, or handle a new edge case by redeploying one function, without touching the app at all.

Two hard-won details. Force JSON discipline: when a feature needs structured output, the system prompt demands raw JSON with no preamble, and the function still strips markdown fences and parses defensively, because the one time in fifty it wraps the response will otherwise be a production bug. And log the failures: every malformed response gets captured, because those logs are exactly the examples you need to fix the prompt.

What I wouldn't run through this pipeline

Honesty requires a boundary, so here's mine. This pipeline is built for focused business applications: an intake processor, a triage system, a tracker with AI features behind a clean seam. I wouldn't run it for real-time collaborative editing, native mobile, or anything where the data model belongs to a system I don't control and can't cleanly mirror. Those aren't "prompt harder" problems; they're architecture problems, and pretending a fast pipeline solves architecture is how fast pipelines get bad reputations.

Why this works for a small shop

The pattern underneath the pipeline: use the fast tool until precision matters, then switch to the precise tool and don't look back. Lovable gets me a real product in days. Claude Code makes it maintainable. Supabase means I never build auth or infrastructure from scratch. And the AI lives behind one clean seam, the Edge Functions, so it can improve independently of everything else.

None of this requires a team. It requires knowing what each stage is for, and the discipline to move on when you've reached its edge.

The kind of thing this pipeline actually ships is boring on purpose. Five real examples are here.

If you're building on a similar stack, I compare notes gladly; the contact form on the main site reaches me.

The Real Cost of an AI Pilot That Never Ships

Tue, 21 Jul 2026 00:00:00 GMT

When an AI pilot fizzles, the accounting is usually one line: we spent $X on licenses, it didn't pan out, lesson learned. Cheap tuition, everyone moves on.

That accounting is wrong by roughly an order of magnitude. The license fee is the smallest and least important number in a failed pilot, and because it's the only number anyone writes down, organizations keep concluding that failed pilots are cheap. They aren't.

What follows is an illustrative tally, not survey data. The assumptions: fifteen participants plus a project lead, a ten-week pilot, a blended $60 an hour. Swap in your own numbers; the shape survives.

The visible number

Say a mid-sized operations team pilots an AI tool: fifteen seats for three months at $40 a seat. $1,800. That's the number in the postmortem, and if it were the real cost, running loose pilots would be a perfectly rational strategy. Spray, pray, and shrug.

Now the numbers that don't make the postmortem.

The invisible numbers

Staff hours. A pilot consumes people even when it's failing. Especially when it's failing, because ambiguity generates meetings. Vendor evaluation and demos, a kickoff, training sessions, the weekly check-in that runs for ten weeks, the IT and security review, the manager quietly nudging people to "give the tool a chance," and the individual hours spent fumbling with a workflow that has both an old path and a new path. Tally it honestly for fifteen participants plus a project lead and you land somewhere between 250 and 400 person-hours. At the blended $60, that's $15,000 to $24,000, which with the licenses puts the true cost of the pilot in the neighborhood of twenty thousand dollars, not eighteen hundred. Paid, worse, in the most constrained currency an operations team has: its people's attention.

Opportunity cost. These are the same hours as above, viewed from the other side: not what they cost, but what they could have produced instead. Count them once in your total; feel them twice. Pointed at a well-chosen workflow, three months of that attention is enough to fully automate one intake process or one reporting cycle. If the workflow you didn't fix wastes ten hours a week, the stall cost you roughly 130 recovered hours per quarter, every quarter, going forward. That number compounds while the license fee doesn't.

The credibility spend. This is the expensive one, and it never appears in any ledger. A failed pilot teaches your team a lesson, and the lesson is: AI initiatives here don't go anywhere. That lesson has a half-life measured in years. The next time someone proposes an AI project, the fifteen people from the last pilot are the skeptics in the room, reasonably, based on evidence you handed them. Attempt two now needs a champion with more political capital, a better tool, and a cleaner rollout just to reach the level of goodwill attempt one got for free. I have watched organizations still paying interest on a botched rollout five years later. I saw it repeatedly in the Microsoft 365 era, and the AI version is the same debt at a higher rate, because "we tried AI" generalizes across every AI proposal that follows.

Why this changes the strategy, not just the accounting

If failed pilots cost $1,800, the right strategy is to run many and see what sticks. If they cost twenty-some thousand dollars and a multi-year credibility debt, the right strategy inverts: run fewer pilots, choose them carefully, and design each one so it cannot end ambiguously.

Ambiguity is the actual killer. Most pilots don't fail loudly; they trail off, undecided, which means the organization pays full cost and receives no verdict. Even a clean kill would have been a win by comparison: a real answer, delivered before the invisible costs compound.

The question that protects the budget

Before your next pilot starts, ask the sponsor one question: what happens on day 31?

If the answer is specific ("we compare against the baseline and the ops manager decides"), you're about to spend money on an experiment, which is fine. If the answer is "we'll see how it's going," you're about to spend twenty-odd thousand dollars and a year of credibility to learn nothing, and the license fee will take the blame.

Structuring pilots so they can't end that way is usually what my first engagement with a client is. If yours starts this quarter, the cheap time to talk is before it kicks off.

The three questions that keep you out of this math in the first place are their own post.

You Bought a Tool When You Needed a Workflow Change

Tue, 21 Jul 2026 00:00:00 GMT

The version I've watched most often runs roughly like this. Someone senior gets excited about AI. A tool gets purchased, usually a good one. A pilot kicks off with real enthusiasm. A couple of months later, a handful of people are using it occasionally, nobody can say whether it's working, and by the next budget cycle it's quietly gone. The postmortem, if there is one, concludes that "the team wasn't ready" or "the tool wasn't quite right."

Neither is usually true. The tool was fine. The team was fine. What failed was the thing nobody owned: the workflow.

The fastest way I know to keep your organization out of that story is three questions, asked in writing, before you evaluate a single vendor. They take an afternoon and they'll save you a quarter. Here they are; the rest of this piece is why each one exists.

The three questions

1. What will we stop doing when it works? This is the question that kills a bad purchase in ten seconds, and it's the only one you can answer without any preparation. If the answer is "nothing, people will just have the tool available," stop here. You're about to buy shelfware. The honest answers sound like: we stop hand-building the Monday report, we stop routing every request through the one person who knows, we stop the Thursday sync because status is now visible. If nothing stops, nothing changed, and nothing changed is exactly what your last stalled initiative delivered.

2. Which specific workflow, and what does it cost us today? Not "customer service." The daily triage of vendor emails, the weekly status report assembly, the intake of new work orders. Pick something that happens frequently, follows a rough pattern, and annoys the people who do it. Then put a number on it: hours per week, or days of cycle time. That number is your baseline, and it's the only thing that will tell you later whether this worked.

3. Who owns the change, and can they retire the old way? One name. If that person can introduce the new step but can't remove the old one, they're set up to fail, because the pilot will run as a parallel option and parallel options lose. Give the owner both halves of the job.

Notice that none of these questions is about AI. That's the point, and it's why they work.

Why the first question exists: the tool-first mistake

The default way organizations approach AI is tool-first. We should be using AI, so which tool should we buy? It feels like progress because there's a decision to make, a vendor to evaluate, a line item to approve. Procurement is a familiar motion, so that's the motion teams run.

But AI doesn't create value at the moment of purchase. It creates value at the moment a specific piece of work happens differently: an intake that used to take twenty minutes takes two, a report that someone assembled by hand assembles itself, a question that used to require finding the one person who knows now gets answered from the documents you already have. That's a workflow change, and workflow changes are a different project than tool purchases. They have an owner, a before-and-after, a specific group of people whose Tuesday looks different. When you start tool-first, you skip all of that and hope it self-organizes. It almost never does.

I know this pattern from the inside because I watched the previous version of it for a decade. Companies bought SharePoint and Teams licenses for everyone, announced them, and then wondered why people were still emailing attachments two years later. I built a career, and wrote six books, inside that gap between license and adoption. The licenses were never the adoption. The adoption was somebody redesigning how a document actually moved through the company, and that part rarely had a name attached to it. The AI version of this story is the same story with a larger invoice, which is why the first question is about stopping something: it forces the workflow change into view before the purchase, instead of hoping it appears after.

Why the other two exist: how pilots actually stall

When an AI pilot dies, it usually dies of one of three deficiencies, and often all three at once. The questions are their antidotes.

No owner. Not a sponsor; sponsors approve budgets. An owner is the person whose job it is to make one workflow work differently, who has the authority to change the process and the obligation to report whether it's better. If you can't name this person, you don't have a pilot. You have a subscription. Question three exists to force the name.

No changed process. The tool gets introduced alongside the existing way of working instead of replacing a step in it. Using the AI is optional, the old path still exists, and under deadline pressure everyone takes the path they know. Optional new tools lose to mandatory old habits every single time. A real pilot retires something (a form, a manual step, a status meeting) so the new way is the way. Question one exists to write the retirement list before the money moves.

Wrong measurement. Teams measure novelty: logins, messages sent to the chatbot, "engagement." Those numbers always look decent in week two and mean nothing. The only measurements that matter are operational. Hours recovered, cycle time shortened, error rate reduced, backlog cleared. If the pilot wasn't set up to capture a before-number, no after-number can save it, and the renewal conversation becomes a vibes debate. Question two exists so the before-number is on paper while the old way still exists to count.

Start smaller than feels impressive

The instinct, especially with executive attention on AI, is to launch something visible: a big platform, a company-wide rollout, a transformation initiative with a deck. Resist it. The big ones are the ones I've watched fail, and they fail precisely because they multiply the three deficiencies across many workflows at once.

The alternative is almost embarrassingly modest: one workflow, one owner, one baseline number, thirty days, and a decision at the end. Expand it, fix it, or kill it. Shipped small things compound. A team that has genuinely automated its report assembly believes the next project is possible, and now you're building on trust instead of spending it.

That's not a less ambitious path to AI adoption. It's the only one I've seen actually arrive.

If you want the full accounting of what skipping this costs, in actual dollars and actual hours, I've run that math separately in The Real Cost of an AI Pilot That Never Ships.

I help operations teams answer the three questions and make the change stick. First conversation is a working session, not a pitch. Get in touch.

Why I'm writing here

Mon, 13 Jul 2026 00:00:00 GMT

I've spent thirteen years helping operations teams get real work out of their software. First Microsoft 365, now AI. Along the way I've written six books for Wiley, sat through more failed pilots than I can count, and started building AI products of my own.

This section is where the longer-form thinking goes. Three things, mostly:

What actually works in AI adoption. Not the demo, but the Tuesday-afternoon reality: who owns the change, what the team does differently, why most pilots quietly die.

Where Microsoft 365 ends and custom AI begins. Copilot solves real problems. It also gets credit for problems it can't touch. I'll draw that line honestly, because I've worked both sides of it.

Build notes. I ship products with a small, fast stack, and I'll write about what breaks, what surprises me, and what I'd do differently. No polish, just the notebook.

No schedule promises here beyond this one: nothing gets published unless I'd want to read it twice.

If something lands or you're wrestling with a version of these problems in your own operation, reach out through the main site. I read everything.