Moving from a Sheet mirror to a working Dodge + CRM cockpit
A simple guide to what changes, what stays safe, and how the people doing the work should shape the system before it becomes the primary workspace.
What we are building, in plain English
The Google Sheet has been useful because everyone can see it and Juan's process already feeds it. But a Sheet is a poor place to manage ownership, review history, CRM relationships, reminders, protected decisions, and a growing team.
The cockpit gives the team one place to work from the same Dodge opportunity data without asking Juan's agent to become a CRM or changing the existing Dodge retrieval flow all at once.
Opportunity information enters through the process Juan already operates.
Retrieves, classifies, and publishes approved fields.
Validates the agreed columns. It does not write back to Dodge or the Sheet.
Review lanes, notes, suppression, history, owners, and change tracking.
Companies, contacts, follow-ups, and who knows whom.
The right way to get Juan's agent up to speed
Do not retrain or broadly rewrite the agent first. That creates the most risk in the part that already works. Bring it up to speed through a narrow contract and clear receipts.
Freeze the handoff contract
- Agree on the five required fields and exact tab meanings.
- Write down what each status means and who can change it.
- Keep sample source rows for regression tests.
Add a small export adapter
- Map Juan's current output into the approved contract.
- Do not force empty or irrelevant fields into every tab.
- Version the contract when a real workflow difference exists.
Return a receipt
- Source tabs and row counts.
- Accepted, rejected, changed, and duplicate rows.
- Contract version, timestamp, and failure reason.
Give the agent a small playbook
- Correct examples for A1, A2, A3, No-Go, and Deleted.
- Examples of fields it must never invent.
- Escalation rule when source structure changes.
What each person gets
A cleaner boundary around the agent
- Less pressure to make the Sheet behave like a CRM.
- Clear input/output rules and useful failure messages.
- The existing process remains the fallback while changes are tested.
A review queue she can trust
- See what needs attention without sorting a large Sheet.
- Record notes, decisions, and follow-up without losing context.
- Find recent changes and suppressed items quickly.
Clear ownership and visibility
- See active opportunities, next actions, and stalled work.
- Understand why a project moved lanes.
- Review team activity without rebuilding a report.
A system that can grow
- Real Dodge opportunity workflow plus real company/contact data.
- Protected human decisions survive future imports.
- UI and workflow can change without rebuilding the source pipeline.
A safe adoption plan
| Stage | What happens | Proof before moving on | Sheet status |
|---|---|---|---|
| 1 · Contract | Juan explains current tab logic. We resolve the missing-header mismatch without weakening validation. | Dry run accepts the intended source and reports exact counts. | Primary |
| 2 · Access | JB, Juan, Karen, and Logan receive real Clerk roles with least privilege. | Each person can see and change only what their role allows. | Primary |
| 3 · Parallel | Run one-shot imports while the team uses both Sheet and cockpit. | At least 10 clean daily runs and two review cycles with discrepancies resolved. | Primary + fallback |
| 4 · CRM | Import 40 unique companies and 57 contacts through an authenticated path. | Counts, relationships, notes, and follow-up samples read back correctly. | Still published |
| 5 · Promote | The team chooses whether the cockpit becomes the daily workspace. | Written acceptance from operators and JB's explicit decision. | Kept current during stabilization |
The humans should shape the UI
The current interface is a working starting point, not a final decree. In the review, avoid asking whether people "like the dashboard." Put real tasks in front of them and watch where they hesitate.
Where the system stands now
| Area | Current truth | Next action |
|---|---|---|
| Frontend | Updated cockpit and Clerk sign-in are live at dash.andromedacon.com. | Authorize real users and perform authenticated QA. |
| Dodge data | Latest dry run read 653 source rows and 628 unique opportunities. | Resolve the contract mismatch on A3, No-Go, and Deleted / Suppressed with Juan. |
| CRM | 57 contact rows reconcile to 40 unique company targets. Production still has five pilot companies and contacts. | Use a supported authenticated import, then read back counts and relationships. |
| Safety | No recurring sync, Dodge writeback, Sheet writeback, outreach, or bid action is enabled. | Keep those controls off through the proving window. |
| Operations | Juan's guide, backup, rollback, and source archive exist. | Run the team acceptance checklist and record discrepancies. |
Suggested 45-minute review
Leave with decisions, not general reactions
- 5 minutes: confirm the goal and the safety boundary.
- 10 minutes: Juan explains the five Sheet tabs and why the missing fields are absent.
- 15 minutes: Karen and Logan complete two real tasks in the cockpit while someone records friction.
- 10 minutes: rank UI changes as must-have before proving, useful during proving, or later.
- 5 minutes: assign owners and dates for access, contract repair, first import, and the next review.
Questions that require a decision
What is the authoritative meaning of each Sheet tab?
Juan should describe entry criteria, exit criteria, required fields, and whether the row can move between tabs. We encode that as a versioned contract rather than guessing from column names.
Who should have which role?
Suggested starting point: JB as admin; Juan as sync operator; Karen and Logan as operators. Confirm whether anyone needs permission to suppress, reassign, or manage contacts.
What must be true before the cockpit becomes primary?
Recommended gate: 10 clean daily imports, two operator review cycles, CRM count/relationship verification, no unresolved high-severity UX issues, and explicit acceptance from the people using it.
Which UI changes should happen first?
Prioritize changes that shorten a real daily task or prevent a bad decision. Cosmetic preferences can wait until the workflow is stable.