Back to Password Reset & Access Requests

Launch Plan

What FullSpec will build for you, what happens at each stage, and what your automation looks like once live.

4 pagesPDF · Operations
FS-DOC-01Operations

Launch Plan

Password Reset & Access Requests

[YourCompany.com] · IT Department · Prepared by FullSpec · [Today's Date]

This Launch Plan covers everything you need to know about how your Password Reset & Access Requests automation will be built, tested, and handed over. It is written for you as the process owner, not for a technical team. FullSpec handles the entire build end to end. Your role is to provide tool access, confirm one key decision before build starts, and review the live system once it is running.

01What you're launching

Right now, every password reset and access request lands in your IT team's inbox as an unstructured message, a Slack ping, or a helpdesk ticket raised manually. The IT person must verify the requester's identity, chase a manager for approval if the request is for a new system, log into multiple admin consoles to make the change, and then close the ticket by hand, often skipping the audit note when under pressure. Staff can wait hours to get unblocked. The automation being built replaces every step in that chain except for one human escalation path reserved for denied or failed verification cases. Requests arrive through a structured Slack command or web form, tickets are created instantly, identity is verified through Okta automatically, manager approvals happen via a single Slack button, and access changes are executed and logged across Okta, Google Workspace, and Jira without IT lifting a finger.

Process
Password Reset & Access Requests
Trigger
A staff member submits a password reset or access request via a Slack slash command or the intake web form
Final output
Access granted or password reset confirmed, requester notified via Slack, and Jira ticket closed with a full audit log entry
Agents being built
3 agents: Request Intake Agent, Verification and Approval Agent, Provisioning and Audit Agent
Tools involved
Slack, Jira, Okta, Microsoft Azure AD, Google Workspace
Volume
Approximately 60 access requests per month (around 62 confirmed this month)
Launch PlanPage 1 of 4
FS-DOC-01Operations

02How the build works

The build follows four sequential stages: Connect, Build, Test, and Launch. FullSpec leads every stage. Your time commitment across the entire build is low: you will be most involved in Connect, where credentials and configuration decisions are confirmed, and in Test, where you review the live flows before cutover. Each stage has a defined set of actions for FullSpec and a short list of things your team needs to do. The build runs to a fixed four-week delivery window for the Standard build.

Complexity level: Moderate (estimated 28 build hours across three agents). Delivery window: 4 weeks from the close of Connect. The delivery clock starts at the close of Connect, not payment.
1
Connect
Business days 1 to 3
Who
Actions
FullSpec
Kicks off the Connect session, walks you through the credential checklist, maps your existing Slack channels and request entry points, confirms the org-chart completeness in Okta and Azure AD, and sets up service accounts in Okta, Jira, and Google Workspace ready for the build.
You
Attend the Connect session (typically 45 to 60 minutes), provide admin credentials or grant service account access for each tool listed in Section 03, and confirm the one configuration decision outlined below. No technical preparation is needed beforehand.
2
Build
Business days 4 to 15
Who
Actions
FullSpec
Builds and tests the Request Intake Agent (Slack command, web form, Jira auto-creation, and request classification), then the Verification and Approval Agent (Okta identity challenge and Slack manager approval with one-click buttons and automated reminders), and finally the Provisioning and Audit Agent (Okta and Google Workspace API provisioning, Slack confirmation message, and Jira ticket close with audit log). All three agents are built and unit-tested internally before the Test stage.
You
No action required during Build. FullSpec may send one or two short questions by email if an edge case arises, such as a reporting-line gap in the directory. Replies within one business day keep the build on schedule.
3
Test
Business days 16 to 18
Who
Actions
FullSpec
Runs end-to-end tests across all three request types (password reset, new access approval, and failed or denied escalation), confirms audit logs are complete in Jira, validates the exception escalation path routes correctly to the IT queue, and prepares the SOP handover documentation.
You
Review two to three test requests submitted through the live system, confirm the Slack notifications look correct, and sign off that the audit log entries in Jira meet your compliance expectations. This review typically takes 20 to 30 minutes.
4
Launch
Business days 19 to 20
Who
Actions
FullSpec
Switches the automation to live, deactivates the old email-based intake route in coordination with your team, publishes the Slack slash command to your workspace, confirms all three agents are running on live traffic, and monitors the first 24 hours of production runs. Delivers the full SOP documentation and hands over the runbook.
You
Communicate the new process to staff (FullSpec provides a short Slack announcement template), confirm the old intake channels such as the generic IT email alias are redirected or retired, and let your IT Support Lead know the escalation queue is now the only manual step remaining.
Launch PlanPage 2 of 4
FS-DOC-01Operations

03What FullSpec needs from you

FullSpec needs only access to your existing tools. No technical knowledge is required from you or your team. All credentials are used solely to connect the automation platform to your systems. Nothing is changed in your tools without your knowledge, and access can be revoked at any time after the build is complete.

Tool
What we need
When
Okta
An Okta admin service account with permission to perform password resets, assign roles, and trigger identity challenges via the Okta API
Before Connect closes
Jira
A Jira admin account or API token with permission to create, update, and close tickets in the relevant project board
Before Connect closes
Slack
Permission to install a Slack app to your workspace and access to publish a slash command to the channels your staff use for IT requests
Before Connect closes
Google Workspace
A Google Workspace admin account with permission to manage group membership and shared drive access via the Admin SDK API
Before Connect closes
Microsoft Azure AD
Read access to your Azure AD directory so the automation can look up reporting lines and confirm user identity for approval routing
Before Connect closes
One decision to confirm before Connect closes: The manager approval flow relies on accurate reporting-line data in your Okta or Azure AD directory. Before the build starts, you need to confirm whether your org chart in these systems is up to date. If reporting lines are incomplete or inaccurate, approval messages may route to the wrong person during the first weeks of live operation. FullSpec will flag any gaps found during Connect, but the decision to clean up the directory or accept a short manual-correction period during go-live is yours to make. This is the single biggest factor that can affect day-one accuracy.

04Your role once live

Role
Ongoing responsibilities
What you no longer touch
You (business owner)
Review the weekly Jira ticket summary to confirm volumes look normal. Update the escalation contact in the runbook if the IT Support Lead changes. Notify FullSpec via support@gofullspec.com if a new system needs to be added to the provisioning scope or if access policies change materially. Handle any escalated tickets in the IT queue where a manager has denied a request or an identity challenge has failed.
Reading and triaging unstructured Slack messages for access requests. Manually creating Jira tickets. Chasing managers for approval responses. Logging into Okta, Google Workspace, or Azure AD to perform resets or provisioning changes. Writing audit notes by hand on closed tickets.
FullSpec
Monitors automation health and uptime. Investigates and resolves any workflow errors surfaced by the platform. Applies updates when a connected API changes in a way that breaks a step. Responds to support requests at support@gofullspec.com within one business day.
Not applicable.
Launch PlanPage 3 of 4
FS-DOC-01Operations

05What success looks like

Timeframe
What to expect
Sign of success
Week 1
The Slack slash command and web form are live. Staff begin submitting requests through the new channel. The first batch of tickets appear in Jira automatically, with classification and audit fields pre-populated. Your IT team handles only the exceptions that land in the escalation queue.
Zero manually created Jira tickets for standard requests. At least one password reset and one new access request processed end to end without IT involvement. Escalation queue correctly receives any denied or failed cases.
Month 1
Volumes normalise through the new intake channel. Manager approval response times improve because the one-click Slack button removes friction. IT staff time on access requests drops noticeably. The audit log in Jira is complete for every closed ticket.
IT hands-on time per request is under 2 minutes on average, down from 35 to 60 minutes manually. Staff wait time for access is under 10 minutes for standard requests. 100% of closed tickets carry a full audit trail in Jira.
Month 3
The process is running steadily with no manual intervention needed for routine requests. The automation has handled the equivalent of around 180 requests. Time savings are tracking toward the projected 5.5 hours per week recovered for the IT Support Specialist. The payback period of 4 months is on course.
Approximately 69 hours of IT time recovered in the first 90 days. Automation cost running at $780/year against an annual saving of $9,100/year. Zero compliance gaps in the Jira audit log. Your IT team is spending time on higher-value work rather than access administration.

Next step: FullSpec will send you a short Connect session invite within one business day of the build being confirmed. The session runs for 45 to 60 minutes and covers credential setup, the org-chart check, and the one configuration decision outlined in Section 03. Once Connect closes, the four-week build clock starts. If you have any questions before the session, reach out to the FullSpec team at support@gofullspec.com.

Launch PlanPage 4 of 4

More documents for this process

Every document generated for Password Reset & Access Requests.

ROI and Business Case
Finance · Owner
View
Process Runbook / SOP
Operations · Owner
View
Developer Handover Pack
Technical · Developer
View
Integration and API Spec
Technical · Developer
View
Test and QA Plan
Quality · Developer
View