Inspect the output
See what useful work can look like.
These fictional examples explain the proposed delivery format. They are not client case studies, completed engagements or measured customer results. Your scope and outputs are agreed in a proposal.
Illustrative sample
An incoming-inquiry pilot
- Situation
- Illustrative business: incoming web inquiries are copied into a CRM manually, and some lack a next-action owner.
- Scope
- One form, one CRM connection, one routing rule set and a named operator. Calendar booking and outbound campaigns are excluded from this example.
- Workflow
- Validate required fields → check for an existing record → create or update the inquiry → assign the approved owner → queue uncertain matches for review.
- Acceptance examples
- A valid inquiry reaches the intended owner. Retrying the same submission does not create a duplicate. A CRM outage creates a visible retry or exception, and an ambiguous match goes to a person.
- Evaluation record
- Record eligible inquiries, time to assignment, completed next steps, failures and operator minutes before and during the pilot. Compare equivalent periods; do not count created records as revenue.
Illustrative sample
An assessment finding
- Scope
- Fictional staging application, test accounts and expressly authorized access-control checks. No customer system was tested for this sample.
- Finding
- A test user can view another test user’s record by changing its identifier. Evidence would identify the affected endpoint, request, response and expected access rule, with sensitive data removed.
- Risk and priority
- Impact depends on the record’s sensitivity and exposure. Confirm those facts before assigning a severity; a sample cannot establish a risk rating for your system.
- Remediation
- Enforce record-level authorization on the server. Add negative access tests for different roles and tenants. Assign the application owner and an agreed due date.
- Verification
- Repeat the authorized request as the wrong user and confirm access is denied, then check legitimate access still works. Record the retest date and evidence if retesting is in scope.
Illustrative sample
A bounded software prototype
- Before
- Illustrative operations team receives job requests and retypes their details into a spreadsheet. Missing fields require follow-up.
- Prototype
- A structured intake screen validates required information and sends an approved record to one destination. A review queue handles incomplete or conflicting entries.
- Acceptance
- Representative valid inputs arrive correctly. Invalid data explains what to fix. Retries do not create duplicate jobs. Failures remain visible to the operator.
- Handoff
- Workflow map, prototype demonstration, known limitations, architecture decision and acceptance record. The proposal defines access, source-code rights and third-party dependencies.
- Next decision
- Review demonstrated fit and running costs before authorizing production hardening, migration or additional integrations. No time savings are claimed without measuring the actual process.
Illustrative sample
A technology decision brief
- Question
- Illustrative decision: should a team buy an existing intake tool or commission a custom workflow?
- Criteria
- Required tasks, integration fit, sensitive data, implementation effort, ongoing costs, support ownership and reversibility.
- Options and evidence
- Compare a configured existing tool, a small integration and a custom build. Record evidence for each required task and mark anything still untested.
- Conditional recommendation
- First test the option that meets the mandatory requirements with the least implementation effort. Commission a build only if the documented gaps justify its delivery and operating costs.
- Action register
- Assign an owner to the representative-task trial, set a review date, confirm total costs, then record the decision and remaining risks.