Bauer Automate - Blog #ProjectPoint

The Timesheet You Reconstruct on Friday

Thu, 22 Oct 2026 10:00:00 -0600

It is late on Friday afternoon, and one of your most senior people is staring at an empty timesheet, trying to remember what Tuesday was. Whatever they type in the next twenty minutes becomes the record: the number the client is billed from, the number utilization is computed from, the number next quarter's staffing case stands on. And it is being written by memory, days after the fact, by someone in a hurry to go home.

This is not a discipline problem, and treating it as one is why it never gets fixed. Entering time is a separate chore from doing the work, so it loses to the work every single day, and memory becomes the fallback. The record is fiction not because anyone is careless, but

because reconstruction is the process.

Watch your best consultant instead

Every firm has one person whose hours nobody ever questions. Look closely at how they work and it is rarely superior memory. It is a habit: the timer starts when the work starts. The note gets written while the call is still fresh, so it reads like a billing narrative instead of a guess. When the invoice goes out, nothing on it has to be defended, because nothing on it was reconstructed.

That person is not more disciplined than the rest of the team. They have simply made capture part of the work instead of an errand after it. The fix for everyone else is not another reminder email. It is making that habit the path of least resistance.

What Friday memory actually produces

Reconstructed time has a recognisable shape. Hours cluster into neat round blocks, because memory does not do minutes. The half-hour that ran over on a call quietly vanishes, or lands on the wrong project. Notes collapse into "admin" and "misc", because the detail that was obvious on Tuesday is gone by Friday. Multiply that by every person, every week, and the distortion is not occasional. It is structural, and every downstream number inherits it.

Make the habit the default

ProjectPoint's time entry rides in a browser extension, in the side panel of Edge or Chrome, which means it is present on whatever tab the work is happening in. Starting a timer is one click. The notes field is right there while the work is in front of you, so the two-sentence description gets written when it costs nothing to write. The toolbar badge keeps the running total visible even with the panel closed, and if something did slip past the timer, a manual entry fills the gap in seconds.

There is no separate site to remember to visit, no app to switch to, and nothing to install beyond the extension itself. The entry lands as a row in your own SharePoint list, using the sign-in the person already has.

The date is the day the work happened

One small design decision says a lot about the whole approach: a Friday timer saved on Monday belongs to Friday. The record keeps the day the work actually happened, not the day somebody got around to filing it. That is the difference between a system built for capture and a

system built for catch-up.

Less time entering time

The point of all this is not tracking for its own sake, and it is certainly not watching people work. It is that accurate time, captured as it happens, is the cheapest version of the truth your firm runs on. Invoices go out without a wince. Utilization means something. Estimates for the next engagement are built on what the last one actually took. And the twenty-minute Friday reconstruction ritual simply disappears, for every person, every week.

Your team spends less time entering time, and more time driving the business forward. The A-tier habit stops being a personality trait and becomes the default, because the tool finally made it the easiest option.

Get in touch, and we will show you the timer your best consultant already wishes they had.

Book A FREE Discovery Call

The Day With Nothing Logged

Tue, 20 Oct 2026 10:00:00 -0600

Somewhere in your organisation, every single week, the same message goes out: timesheets, please. It is sent by someone senior enough to have better things to do, to people senior enough to resent receiving it, and it works just well enough to guarantee it will be sent again next week. The chase is so routine that nobody thinks of it as a cost. It is a standing tax on a manager's week, paid to compensate for a record nobody can see the holes in.

That is the actual root of the ritual. It is not that people refuse to log time. It is that an incomplete week looks exactly like a complete one, to the person who lived it and to the person chasing it. Nobody can fix a gap they cannot see, so the gap gets found late, by the person assembling the invoice, which is the most expensive possible moment to find it.

The chase is a symptom

Think about what the weekly reminder actually is: a human being acting as a completeness check, by broadcast, with no information about who is missing what. The manager does not know whether Thursday is empty or the whole week is. The contributor opens the tool, sees a list of whatever they did enter, and honestly cannot tell either. Two people are now spending attention on a question a glance should answer.

Gaps are the point

ProjectPoint's time-entry extension answers it with a week strip: seven days, a bar per day against the day's target share, a per-project breakdown behind it. And one deliberate design choice does most of the work: a workday with nothing logged is hatched. The empty day is drawn as the anomaly it is, so the thing you forgot is the thing that stands out. Nobody has to ask whether their week is complete. It is visible before the question forms.

A week that matches how you actually work

Completeness views usually fail people whose week is not Monday to Friday, nine to five. This one adapts instead of nagging: weekend columns appear only when the week's own entries show weekend work, and the daily target share spreads across the days a person actually works. A part-time schedule or a compressed week fits without configuration, which matters, because a completeness view that flags someone's ordinary Friday off as a gap gets ignored by Wednesday.

Am I on pace

The same idea extends to the month. A month view shows the days filling in and answers the question people actually ask, which is not "what is my total" but "am I where I should be by now". The month-to-date pace is shown as a signed figure, ahead in green or behind in red, and the arithmetic behind it is shown rather than hidden, so the number earns trust instead of asking for it.

What the manager stops doing

When every person can see their own gaps, completeness stops being something a manager enforces and becomes something the record maintains itself. The Friday broadcast retires. The conversation that replaces it is a better one: not "fill in your timesheet" but "this project is absorbing more of the team's week than we planned". That is a conversation about the business, held on numbers everyone already trusts, and it costs less time entering time and chasing time, with more time spent driving the business forward.

One limit worth stating plainly: this is each person's view of their own week, not an approval chain. Nothing here routes a submitted timesheet to a manager for sign-off, and we will not pretend otherwise in a demo.

Get in touch, and we will show you a week where the gaps show themselves.

Book A FREE Discovery Call

Two Timers, One Hour, and a Total That Still Adds Up

Tue, 13 Oct 2026 10:00:00 -0600

The total at the bottom of a timesheet is a claim, and sooner or later somebody checks it. A client's finance team adds up a month of entries and finds a day that contains eleven billable hours of remembered work. Nobody lied. Somebody worked on two things at once, logged both in full, and the tool added them up without blinking. The invoice is now wrong in the one direction that costs trust, and the person explaining it is you.

It happens because real delivery work overlaps and most time tools pretend it does not. You are on a call for one client while a deployment runs for another. Both matter, both deserve time, and a tool that lets two full-length timers run in parallel has quietly decided that one hour of your afternoon can become two hours of billing.

Even split, by construction

ProjectPoint's time-entry extension allows several timers at once, because that is how the work actually happens, and then it refuses to inflate the result: when more than one timer runs, the wall clock is split evenly among them. The spec's own worked example is the whole idea in four numbers. Start timer A; ten minutes later start timer B; let both run ten more minutes; stop. A gets fifteen minutes, B gets five, and the total is twenty, which is exactly how much time actually passed. The total always equals real elapsed time, not because anyone was careful, but because the arithmetic will not allow anything else.

One click, one row

The same philosophy covers the smaller lie of the double entry. The endpoint SharePoint exposes for writing a list item has no way to recognise a second call as a repeat of the first, so an impatient double click in a lesser tool becomes two identical rows and a double-counted timesheet someone discovers at month end. Here, one click produces one row, and a second click cannot produce a second one, because the duplicate is stopped before the request ever leaves the browser.

Notes that keep up with the hours

An eight-hour entry with a three-word note is a reconciliation argument waiting to happen. The extension expects notes to keep pace with the size of the entry: the more hours a row claims, the more description it takes to save it. Because the note is written in the side panel while the work is still on screen, meeting that bar costs seconds, and what lands in the record reads like a billing narrative rather than a shrug. Where a project genuinely does not need descriptions, its own project list can say so, and the rule steps aside for exactly those projects.

The timer that ran all weekend

Honest tooling also plans for the dishonest-looking accident. Everyone eventually leaves a timer running over a weekend and comes back to a sixty-six hour entry. Fixing it is one edit to the total, not a card-by-card archaeology session. The date stays the day the work actually happened, a Friday timer saved on Monday belongs to Friday, and a deleted entry goes to the site recycle bin rather than into thin air, so a mistake can be restored by a site owner instead of argued about.

Numbers that survive scrutiny

Add it up and the result is quiet: a timesheet where the total equals the time that actually passed, where no row exists twice, where big entries carry real descriptions, and where the history of a correction is recoverable. Finance stops re-deriving the numbers, clients stop finding eleven-hour days, and the team spends less time defending time entries and more time driving the business forward.

Get in touch, and we will show you a timesheet total you do not have to re-check.

Book A FREE Discovery Call

The Time Tracker IT Never Has to Install

Tue, 06 Oct 2026 10:00:00 -0600

A time-tracking rollout usually lands on your desk as a project. There is a vendor security questionnaire to fill in, an Entra app registration asking for consent to scopes somebody has to actually read, a provisioning connector to stand up, and at the end of it, a new pipe carrying your organisation's working data to a cloud you do not run. All of that for a tool whose job is writing down hours.

It is worth asking why the ceremony exists at all. It exists because the tool lives outside your tenant, so identity has to be bridged in and data has to be piped out. Remove that one architectural decision and most of the project disappears with it.

What zero setup actually means

ProjectPoint's time-entry surface is a browser extension for Edge and Chrome, and its requirements from IT are, precisely: nothing. No Entra app registration. No admin consent. No API permissions to review. It never reads cookies; it rides the user's existing signed-in SharePoint session, the one governed by the conditional-access and MFA policies you already enforce. This is not a marketing rounding of "almost nothing": the claim was verified on a vanilla tenant, with a normal user account holding only list-level permissions, with no admin action taken anywhere.

It can only see what they can already see

The extension writes time entries as rows in a SharePoint list, using the user's own permissions. It has no service account, no elevated identity, and no reach beyond *.sharepoint.com. If a person cannot edit the list, the extension cannot either. There is no new permission surface to audit, because no new permissions exist. Under Manifest V3 it runs no remotely hosted code, and its browser permission set is short enough to read in one breath: storage, alarms, the side panel, and SharePoint itself.

The record stays in the tenant

Because entries are ordinary SharePoint list items in your own site, everything you already do to SharePoint data applies to them automatically. Your retention policies, your backup posture, your eDiscovery scope, your audit trail: all of it covers the timesheet record with no extra configuration, because the record never left. There is no vendor copy to reason about, and nothing to repatriate if the relationship ends. Deleted entries go to the site recycle bin, where a site owner can restore them.

Governed from a list, not a console

Central control, where you want it, comes from a plain SharePoint Settings list on the site rather than a vendor console living in your tenant. A row can be a rule, enforced for every user and shown locked in their preferences, or a starting point that seeds new installs and then leaves people alone. The same list carries your brand colours, so both surfaces render in company colours before first paint. You govern the tool with list permissions you already understand, and there is nothing else installed to govern.

One component of a suite that thinks this way

The extension ships as the time-entry surface of ProjectPoint, and its setup story is the suite's philosophy in miniature: a user pastes the ProjectPoint site address, clicks Connect, and the extension finds the lists ProjectPoint installs by itself. The full ProjectPoint solution is a complete project management suite on SharePoint, the governed project workspace, the registry, the project registers, and time and budget capture, built on as much vanilla Microsoft 365 as possible, precisely so that questions like "where does the data live" and "what did we just consent to" keep having boring answers.

Two honest notes for this audience. Distribution today is a team install, with the store listing in preparation, so deployment is a sideload your desktop team runs rather than a store click. And the extension speaks to *.sharepoint.com only: vanity SharePoint domains and GCC tenants are out of scope for v1, and we will say so rather than let you discover it.

Get in touch, and we will show you the whole setup. It fits in one sentence.

Book A FREE Discovery Call

The Column You Add Without Calling IT

Tue, 29 Sep 2026 10:00:00 -0600

Someone on your delivery team wants one more column on the risk register: an owner field, say, so every project captures who is carrying each risk. On most provisioning setups that one-line request is not a one-line change. It is a ticket, a scheduled release, and a person with elevated rights regenerating and republishing the template the whole organization provisions from. A field a project manager could describe in a sentence becomes a change only IT can make.

It works that way because of what the template actually is. In the classic SharePoint provisioning route the template is a generated artifact, a package of scripted instructions produced by a tool and run with PowerShell. You do not edit it the way you edit a site. You regenerate it, and the regenerated version arrives as a new artifact with a new identifier and freshly generated code, so anything pointing at the old one has to be repointed. The cost of the change is not the column. It is the machinery that has to move to carry the column.

The template that is really a program

This is the part worth being clear-eyed about, because it stays invisible until you need to change something. A scripted template is software. Updating a single list column means someone opens the tooling, changes the definition, regenerates the package, tests it, and republishes

it, and until they do, every new project keeps provisioning the old shape. The people who feel the gap, your project managers, are not the people who can close it. So the column waits, or the register quietly grows a fifth spreadsheet nobody provisioned at all.

Ours is a site you open and edit

ProjectPoint takes the opposite approach, and it is the load-bearing design decision in the whole product. The master site is not a package. It is a real, live SharePoint site, sitting in your own tenant, that your project manager maintains like any other site they own. Want another column on the risk register, a different default folder structure, a new content type, a tidier set of libraries? Change it on the master site the way you would change any site. There is no build step, because there is nothing to build. The site is the template.

When the next new client needs a site, the provisioning engine copies that master site, as it stands that day, into the client's new site, where each project gets its own folder. The improved register is simply there, because it was there on the master site when the copy ran. No ticket, no republish, no new identifier to repoint, and no waiting for a release window. Editing a site is something a project manager already knows how to do, and that is precisely the skill the design leans on.

Who holds the pen

The quiet shift here is about ownership, not features. On the scripted route, the shape of every future client site is held by whoever owns the provisioning code, which is almost always IT. On this one, it is held by whoever maintains the master site, which is your PMO. The people
who actually run projects decide what a project workspace contains, and they change it themselves, in the tool they already use, on the afternoon they decide to, without anyone re-architecting a provisioning engine because a column moved.

That is why the list of what the master site carries is worth knowing: its site features, its permissions, its content types and site columns, its lists and libraries, its navigation, and its default folder content. Every one of those is edited the same way, on the master site, by the same person, and it is copied into the next client site exactly as it stands. The column is just the smallest example of a much larger pen you are being handed.

The one limit we will not dress up

There is a real boundary here and you should hear it from us rather than find it in month nine. Improving the master site changes every client site created after the change. It does not reach back. A site created in month one does not receive month nine's new column, and there is no drift detection and no re-apply to already-provisioned sites today. If a change has to land in sites that already exist, that is manual work, project by project, and it is the largest structural limit in the current design.

The honest other half is the half this post is about: making the change itself is trivial and takes effect on the very next provisioning run. The gap is retroactive application to old sites, not the cost of holding the pen. Most teams edit the template often in the first months and rarely once it settles, which is exactly the shape this design handles well.

Get in touch, and we will show you the master site, and let you add the column yourself.

Book A FREE Discovery Call

One Button, and the Whole Workspace Is There

Tue, 22 Sep 2026 10:00:00 -0600

A new project starts, and it needs a home: a site, a document library set up the right way, the content types your templates expect, navigation people can follow, a task board, and permissions that match who is on the team. Today, getting all of that usually means a ticket to IT and a wait, or an evening one of your project managers spends assembling it by hand. Either way the project waits on setup work done by someone who is not running the project.

The reason the wait exists is worth naming, because it is the thing ProjectPoint removes. Most tools that can build a SharePoint site to a standard need administrator rights to do it, so the person who needs the site is structurally not the person who can make it. Take that one

constraint away and the ticket, the queue, and the evening all go with it.

What one button does

In ProjectPoint, a project manager starts a workspace by pressing the button on the project's row in your Projects list. That single action runs the whole sequence. If the client has no site yet, one is created and joined to your ProjectPoint main site, which acts as the hub. The hub navigation updates, with audience targeting, so the right people

see it. Your master site is copied into it: site features, permissions, content types and site columns, the lists and libraries, the navigation, and the default folder content. The project gets its own folder and Teams channel in the client's site (a private or shared channel gets its own site, because Teams requires it), and a Planner board seeded with starting tasks. The client site's home page arrives ready. And the project record links itself to the new workspace and its board, and the button changes to Open, so the register stays the index of everything. It takes minutes, and the person who needs the site is the person who ran it.

Run by the project owner, not by an administrator

The design decision underneath that is the one worth understanding, because it is the product's strongest technical claim. The provisioning engine is a REST deployment tool that runs on connections owned by the site owner who installs it, calling SharePoint for actions that owner already has the right to perform. No tenant-wide application is consented into your directory, and no elevated role is required to run a provisioning. That is a deliberately precise claim: it is about the provisioning run, not about your whole tenant.

It matters because the alternatives ask for more. The commercial provisioning tools in this space generally require a global administrator to consent an application across the tenant before they will work at all. The free route got harder rather than easier, too: the widely used multi-tenant provisioning application many teams relied on was deleted on 2024-09-09, so even a scripted PowerShell approach now needs an application registered and admin-consented in your tenant. ProjectPoint asks for neither.

What that does not mean

One honest boundary keeps this claim clean. Whether people can create SharePoint sites at all is a single tenant-wide setting your IT team already controls. If they have turned it off, a site owner cannot create the target site no matter how the tool signs in, and that is exactly as it should be. Provisioning without an app consent is not the same as provisioning around a decision your administrators have already made, and we would never pitch it as the latter. It is a way to run project provisioning without new standing access, inside the rules IT already set.

Two honest notes for the reader who checks

Two things this reader will ask about, said plainly. A provisioning run is a sequence of steps, so a run that stops partway is picked up and finished by a person rather than rolled back on its own. And naming conventions and sensitivity labels stay with your standard tenant governance rather than being stamped by the engine at the moment of creation. Neither surprises a SharePoint team, and we would rather name them up front than have you meet them in a demo.

The reassuring half is real too. Two pieces of hardening, restricting and logging writes to the trigger column that starts a provisioning, and reviewing the engine's own identity for least privilege, sit inside the entry tier deliberately and are being completed before the first

sale, not deferred to a later one. This is the layer IT cares about most, and it is treated as launch work rather than roadmap.

Get in touch, and we will press the button on a row and let you watch the workspace build itself.

Book A FREE Discovery Call

The Timesheet That Isn't a Separate System

Tue, 15 Sep 2026 10:00:00 -0600

Your billable hours live in a time-tracking tool. The project they belong to lives somewhere else: a site, a plan, a folder of documents. And once a month somebody sits down and reconciles the two by hand, matching a row in one system to a project in another, so the invoice can go out. The record your firm's revenue stands on is kept in the one place that has no direct connection to the work it describes.

That gap is not an accident of your setup. It is the shape of the whole category. Time tracking grew up as its own kind of software, a product you buy on its own, so the hours and the project they were logged against were never meant to live in the same system. The reconciliation is not a step you do badly. It is a tax you pay for keeping two records of the same afternoon in two different places.

Two records of one afternoon

Think about what a timesheet entry and a project record actually are. Both describe the same hour of the same person's work. One says how long and against what code; the other says what the work was part of, where its documents are, who is on it. Keeping them apart means every number has to be carried across the gap by a person, and the carrying is where the errors, the delay, and the month-end scramble come from. The hours matter most and sit furthest from the project.

One list, in the project's own site

ProjectPoint closes the gap by putting time where the project already is. An entry is a row in a SharePoint list in your own SharePoint, naming the project it belongs to, so it ties to that project's documents and registers. It is part of the project record, not a separate system pointing at it from outside.

The way that time gets captured is a shipped browser extension for Edge and Chrome, and it is good at the job. It rides in the browser side panel, so it is present on whatever tab the work is happening in. Start a timer with one click, run several at once when the work genuinely overlaps and watch the wall clock split evenly between them so the total never inflates, or log time by hand when the timer missed it. A week strip shows the days you have and have not logged, and a month view answers the question people actually ask, which is not "what is my total" but "am I on pace", with the projection shown rather than hidden. It captures time well, and every minute of it lands in your own list using the sign-in the person already has.

It holds up against the tools built only for this

The mature time-tracking products, Harvest, Ruddr, Clockify and the rest, are good software, and we will not pretend otherwise. But every one of them is vendor-hosted, so the honest capture they give you comes with the record living on someone else's servers, under someone else's subscription. ProjectPoint gives you the capture, concurrent timers that add up correctly, a completeness view, a pace projection, and keeps the record in your own tenant, because it was never anywhere else.

ProjectPoint's time entry names a project, with a category, and reports against it. Time broken down to individual tasks and sub-tasks, against a full work-breakdown structure, is the relational model at the Platform tier on Dataverse; when that is the job in front of you, it is
the Platform conversation to have.

One component of a platform, not a point tool

The reason the timesheet is not a separate system is that ProjectPoint is not a time tracker that grew a project feature. It is a project management platform on SharePoint, and time entry is one component of its middle tier, alongside the four project registers and the capture of time and budget feedback from both the project lead and the people doing the work. The point of putting time in the project is that it stops being a silo and starts being one more thing the project workspace knows, reported on next to the budget it burns and the risks it carries.

Where it goes when you bill at a rate

For a firm that bills client work, the next step up is the relational model at the top tier, on Dataverse: rates, billable versus non-billable classification, an invoicing-ready export, and row-level boundaries so a contributor sees only their own entries. That is the Platform conversation, and it is the one to have when time to rate to invoice is the job in front of you. The middle tier gets your hours captured against the right project, in your own tenant, and reported on in context; the top tier turns them into what finance sends the client.

Get in touch, and we will show you hours that already know which project they are on.

Book A FREE Discovery Call

The Report Your Tenant Is Already Holding

Thu, 10 Sep 2026 10:00:00 -0600

Two rituals repeat in every delivery organisation. Once a week, someone sends the "timesheets please" email. Once a month, someone rebuilds the same status report by hand, copying numbers out of a tool into a slide, so leadership can see where the projects stand. Both are work that produces nothing new. Both exist to compensate for the same missing thing: a clear view of your own data that you can simply read.

The reason you cannot simply read it is usually where the data lives. When the record sits on a vendor's servers, getting a report out of it means exporting on the vendor's terms, in the vendor's shape, and then rebuilding the view you actually wanted. The report is a reconstruction, not a read. And the weekly reminder exists for a related reason: completeness is invisible, so a person has to stand in for the check a system should perform.

The reminder is a symptom of a report you cannot see

Look at the weekly chase for what it is. A manager broadcasts "timesheets please" because they cannot see whose week is complete, and a contributor cannot tell either, so two people spend attention on a question a glance should answer. The monthly report is the same problem one level up: the numbers exist, but not in a form anyone can point a chart at, so they get carried across by hand every period. Neither is a discipline failure. Both are what you get when the data is somewhere you cannot query freely.

The data is already list items in your own tenant

Here is the structural difference with ProjectPoint. Your Projects registry is a SharePoint list. Your time entries are SharePoint list items, in your own SharePoint sites. That is not a metaphor for "we can export it to you". It is the same data an executive roll-up reads, sitting in a place you already own the tools for, and ProjectPoint turns it into the views your week actually runs on.

The reports, and the reminders that carry their own answer

Every person entering time gets their own week strip, showing the days logged and unlogged, and a month view with a signed pace figure, ahead in green or behind in red, with the projection shown rather than hidden. That is reporting at the level of the individual, and it answers "am I on pace" without anyone sending an email.

Above it, ProjectPoint reports across the portfolio. A cross-project roll-up puts status and budget for every project in one view, built from the registry that already holds them. Scheduled digests land in inboxes showing who is on track and where a budget is heading, so the weekly reminder sends itself with the answer already attached instead of a manager chasing it. And a client-ready weekly progress summary is drafted for each project from the week's own entries, so a project manager sends it rather than assembling it by hand. Because your hours are ordinary list items in your own tenant, a Power BI report points straight at them, over data you already own, with nothing to export and no vendor copy to reconcile against.

The upgrade worth having

The entry tier gets your projects and your hours into your own tenant, correctly shaped and correctly owned. That is the foundation, and it is the part you buy first. The middle tier is where that owned data becomes the roll-up, the digest, and the summary that a delivery lead runs the week on. That is the upgrade worth having, and the reason it is worth having is the reason the whole thing is worth owning: the data underneath every one of those reports is yours, and it stays yours.

Get in touch, and we will point your own reporting at your own data.

Book A FREE Discovery Call

The Register That Still Knows Where Everything Is

Tue, 08 Sep 2026 10:00:00 -0600

Six months into the year, someone asks a simple question: where does the Henderson project keep its documents? If your project sites were built by hand, the honest answer is a search, a guess, and a message to whoever set it up, if they are still here. The site exists. The board exists. The register of risks exists. What does not exist is one place that reliably knows they all do, and how to get to each one.

That is the quiet failure of building sites one at a time. Each one is fine on the day it is made. But nothing holds the list of them all, so the map of your portfolio lives in people's heads and in half-remembered links, and it degrades a little with every project, every reorg, and every person who leaves. The problem was never making a project site. It was keeping a growing pile of them findable.

Making the site is the easy part

Provisioning a workspace is a one-time act. Keeping a portfolio of workspaces navigable, so any project can be found by someone who did not set it up, is the ongoing one, and it is the part hand-built sites never solve. A folder of bookmarks is not a map. A Teams message asking "what was the site for Henderson again" is the sound of the map having failed.

The register is the index, and it links back

ProjectPoint's answer is that the Projects list is not just where projects are started; it is the index that stays current by construction. When a project is set up, its record links itself to the project's workspace and its Planner board, and its button changes to Open. The register does not drift out of date, because the linking is part of the same run that creates the workspace, not a step someone has to remember afterwards. To find any project, you open the register, find the row, and follow the link. The list that starts your projects is the same list that always knows where they went.

The hub routes people, in your own navigation

Findability is not only the register's job. Each new client site joins your ProjectPoint main site, which acts as the hub, and the hub navigation updates so the client appears where people already look, with audience targeting so they see the clients and projects that are actually theirs rather than everyone's. Each client site's home page arrives ready, so a person opening it for the first time lands somewhere oriented instead of on an empty site they have to decode. The map is not a document you maintain. It is the way the sites were built.

Why this is the part you buy first

This is the entry tier of a project management platform, and it is deliberately the foundation. The registry and the provisioning engine are the component that is built, demonstrable, and buyable today, and the reason they come first is that everything else the platform adds, the

risk and decision registers, the time and budget capture, the reporting on top, is only worth putting inside a project site if the project site can be found later. The map has to hold before the things on the map are worth drawing.

The limit worth stating plainly

ProjectPoint creates client sites and project workspaces and keeps them indexed. It does not archive them, expire them, or decommission them when a project ends, and it has no sprawl reporting or permissions auditing across your tenant. If the problem you actually have is controlling the whole lifecycle of sites at scale, closing down the finished ones and policing who can see what, that is a different category of product with a different buyer, and those tools are usually complementary to this one rather than in competition with it. We would rather point you at them than pretend a provisioning engine is a governance platform.

Get in touch, and we will show you a register that still knows where everything is.

Book A FREE Discovery Call

The Same Shape for Every Client and Every Project

Wed, 02 Sep 2026 10:00:00 -0600

Open your last three project sites side by side. If they are three different shapes, that is not a tidiness problem. It is the reason nothing can be found in the same place twice, and the reason every governance conversation has to be had again on every project.

That inconsistency has a simple origin. Every one of those sites was built by whoever had time that week, structured however they happened to be thinking about the project that morning, with permissions set from memory rather than from a policy anyone wrote down. None of that is negligence. It is what happens when "stand up a project site" has no fixed answer, only a person doing their best against a deadline.

One office's habits become three

Now multiply that by three offices. One office's habit of naming a folder a certain way becomes three different habits, one per office, and none of the three people involved did anything wrong. Each is being reasonably consistent with themselves. The firm is not being consistent with itself, and because nobody individually caused the drift, nobody individually owns fixing it. It just accumulates, one project at a time, until "where do we usually put the meeting minutes" has three correct answers depending on which office you ask.

Careful is not a system

The instinct is to fix this with a memo: a naming convention, a checklist, a line in the kickoff agenda. It does not hold, for the same reason it never holds anywhere else in a firm's document practice. A consistency problem is not solved by asking people to be more careful under deadline pressure. It is solved by making the consistent version the only version anyone can produce. The site has to arrive built. Nobody should be assembling it by hand in the first place, no matter how careful they mean to be.

What actually gets copied

That is what a master site means in practice: copied in full every time a new client site is created, not handed over as a starting point for somebody to finish. The client site is created and joined to your ProjectPoint main site, which acts as the hub, and the hub navigation shows it to the people who need it. From there the copy runs layer by layer: the same site features, the same permissions, the same content types and site columns, the same list structure, the same library structure, the same navigation, the same default folder content already in place. Each project then gets its own folder and Teams channel in that site, and its own Planner board, seeded with starting tasks rather than handed over blank. The site's home page arrives ready, built from the master site. None of it is a scaffold somebody finishes later. It is the finished site, on day one, the same shape as the last one and the one before that, whichever office opened it.

A project list that stays true

There is a second piece that matters as much as the site itself. The project record that started the whole process, the row in the project registry, links automatically to the project's workspace and its board, and the button on that row changes to Open. That sounds small until you have watched a project list go stale the ordinary way: a project gets added, a site gets built by hand somewhere else, and six months later the two have drifted apart, or the link never gets made at all because making it was one more manual step nobody prioritized. Here the link is not a step somebody has to remember. It is a direct consequence of provisioning, which means the project list stays a true index of where the work actually lives instead of becoming one more record somebody has to reconcile against reality.

What this does not do yet

One limit is worth stating plainly, because a reader who discovers it later stops trusting everything else in this post. The master site improves over time. A client site created before an improvement lands does not receive it after the fact. There is no drift detection today, and no way to re-apply an updated master site to a client site that already exists. Every new client site gets the current master site. The ones already built keep the shape they were built with. That is a real gap, not a hidden one, and it is better to know it now than to discover it in a steering meeting.

Get in touch, and we will walk your last three project sites side by side.

Book A FREE Discovery Call