The first 30 days of a Proximity deployment

The first 30 days of a Proximity deployment should feel practical.

Not theatrical. Not like a company-wide AI transformation programme. The right starting point is one operating area where better preparation, source visibility, and review would change the work.

The goal of the first month is to build a repeatable review rhythm around real work.

The Starting Principle

Start with one workflow.

That workflow should be recurring, source-heavy, reviewable, painful, and bounded. A weekly matter review, renewal review, project handover, client follow-up review, or research packet is usually a better starting point than broad automation.

The first deployment should answer:

• What work object are we modelling?
• Which sources matter?
• Who owns the decision?
• What should the system prepare?
• What must remain behind approval?
• How will we know the packet is useful?

Week 1: Map The Operating Area

The first week is about understanding the work.

For a matter review, the work object may be a matter. For finance, it may be a renewal. For relationship-led teams, it may be a client commitment. For project teams, it may be a site question or project decision.

The mapping should identify:

• the recurring review rhythm;
• the people involved;
• the sources used today;
• the current preparation burden;
• the decisions made in review;
• the follow-ups created;
• the actions that require approval.

This stage is not about asking people to describe an ideal system. It is about observing the workflow that already exists.

Week 2: Review Sources And Boundaries

The second week focuses on source access, permission, and authority.

The team should decide:

• which systems and folders are in scope;
• which source types are authoritative;
• which material is sensitive or restricted;
• which roles can see what;
• which actions the system may prepare;
• which actions it must not take.

This is where many AI pilots become real. A model can summarise anything it sees, but professional work requires boundaries. The system needs to know which sources are allowed, which are stale, which are draft, and which require careful handling.

Week 3: Prepare The First Review Packet

The first review packet should be useful even if it is imperfect.

It should show:

• current state;
• changed items;
• source evidence;
• missing information;
• open decisions;
• responsible owners;
• proposed next steps;
• approval boundaries.

The team should review the packet in the actual workflow, not as a standalone demo. If the workflow is a weekly review, use it in the weekly review. If it is renewal review, use it for real renewals.

The question is not "is the AI impressive?" The question is "did this make review better?"

Week 4: Turn Feedback Into Rhythm

The fourth week is about iteration.

Reviewers should mark:

• missing sources;
• incorrect assumptions;
• useful sections;
• confusing sections;
• decisions that needed escalation;
• follow-ups that should become tasks;
• parts of the workflow that may become repeatable.

Those corrections become the system's next version. The workflow improves because the team can see what the system prepared, what people changed, and what should happen next time.

What Success Looks Like After 30 Days

Success is not full automation.

Success is a working operating rhythm:

• one workflow is modelled clearly;
• the system can prepare a reviewable packet;
• sources and boundaries are visible;
• reviewers know what to inspect;
• follow-ups are clearer;
• the team can compare the new process against the old one;
• the next improvement is obvious.

This is enough to make a real decision about expansion.

What Not To Do

Do not begin by connecting every system.

Do not begin by automating external action.

Do not begin by asking the model to replace professional judgment.

Do not judge the pilot only by a polished demo.

The first 30 days should make the work clearer, not more mysterious.

How This Expands

Once one review rhythm works, expansion becomes more disciplined.

The team can ask:

• Should this workflow move from draft to recommendation?
• Which parts are stable enough for approved action?
• Which sources need better structure?
• Which adjacent workflow uses the same operating object?
• Which team would benefit from the same packet pattern?

That is how a pilot becomes infrastructure.