Designing guided visit creation without hiding the process
A compact, fictional case: automation that saves effort without obscuring intent.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
One short guided entry that creates one correctly linked visit, with its follow-ups, and can be resumed if a step fails.
Logging a customer visit takes six screens—so sellers skip it, or create duplicates with half the context.
What can automation infer, and what must the seller still decide explicitly?
Infer context, keep purpose and outcome explicit, and create the visit and follow-ups as one unit with a resumable state.
Sellers log customer visits with the account, contacts, opportunity, purpose and follow-up actions. The data is used for coverage analysis and account planning. Today it takes several screens, contacts are linked inconsistently, and the same visit is sometimes logged twice from the calendar and the CRM.
A seller starts “Log visit” from an account, an opportunity or a calendar event.
- One visit linked to account, contacts and opportunity
- Purpose and outcome recorded by the seller
- Follow-up tasks created once
- No duplicate of a calendar-synced visit
02The reality · current state
What the automation does today.
- Sellers re-type context the CRM already knows
- Visits are linked to the wrong contacts or to none
- Duplicate visits from calendar sync and manual entry
- A failed follow-up task leaves the visit half-created
- Nobody can see why a visit was logged—only that it was
03Target steps
Each step with its mode, its actor and its guard.
- 01Prefill context
Account, contacts met, open opportunity and date from where the seller started.
- 02State the purpose
Why the visit happened and what came out of it—never inferred.
- 03Validate relationships
Contacts belong to the account; the opportunity is open.
- 04Create visit
Create or match the calendar-synced visit, then link.
- 05Suggest follow-ups
Proposed tasks from the outcome; the seller confirms.
04Key dimension · Inferred, explicit & validated input
What is inferred, what stays explicit
Automation saves typing, not thinking. Each field is either inferred from context, asked explicitly, or validated before anything is created.
- AccountInferred
From where the seller started; editable
- Date & attendeesInferred
From the calendar event when there is one
- Contacts metValidated
Must belong to the account; new ones created explicitly
- OpportunityValidated
Must be open and on the same account
- PurposeExplicit
Always chosen by the seller
- OutcomeExplicit
Written by the seller; drives suggested follow-ups
- Follow-up tasksExplicit
Suggested, confirmed by the seller
If a field changes what the organization believes happened, the seller states it. Everything else can be inferred.
05Execution safety
If it can run twice, it is designed to run twice.
Short and user-facing, but several records must be created together or not at all.
- Duplicate guard
- Account + date + organizer matches a synced visit
- Draft state
- An unfinished entry is saved and can be resumed
- Atomic creation
- Visit and links in one transaction
- Follow-ups
- Created after the visit; failures leave the visit intact and the task pending
06Exceptions & recovery
Not every failure is a retry.
- Contact not on the account ValidationRelationship checkAsk: link, create or removeSeller
- Visit already synced from calendar DuplicateDuplicate guardOpen the existing visit insteadNobody: absorbed
- Follow-up task fails Transient · retryError after visit creationVisit kept; task retried; seller sees “pending”Automation
07The trade-offs
Credible options, judged against these premises.
Keep the standard screens
Occasional visits
Cost: Skipped logging; inconsistent linksFully automatic logging from the calendar
Coverage counts only
Cost: No purpose or outcome; noiseGuided creation: infer context, explicit intent, resumable
Visits that feed planning
Cost: A guided screen to build and maintain08The second layer
Questions that change the design.
Inference
- Which values can be inferred?
- What must remain explicit?
- What does automation save without obscuring intent?
Creation
- When is the record created?
- What happens if one downstream action fails?
- Can the user resume?
Duplicates
- How is a calendar-synced visit recognised?
- Who resolves a probable duplicate?
- What does the seller see?
09Decisions & outputs
What the work produces.
- 01Field inference map
- 02Validation rules
- 03Duplicate guard
- 04Draft & resume design
- 05Follow-up suggestion rule