Owner
Product owner for Android native reply insertion.
Standard operating procedure
Android ReplyPilot Keyboard readiness SOP
An Android ReplyPilot Keyboard readiness SOP should start only after mobile web users copy useful drafts and report copy-back friction. The SOP verifies keyboard-shaped demand, permission clarity, selected editable insertion, fallback copy, and manual final posting. It is roadmap planning and should not be treated as current Google Play availability.
Cadence
Run after mobile web activation data shows selected copy and repeated Android use.
Last updated: July 12, 2026. The final platform action stays manual.
Inputs
Required inputs before the SOP starts
Visible source context
Use the actual visible post, comment, thread, or pasted text that the user wants to answer.
Saved marketing context
Use only saved product, audience, offer, voice, website, and soft CTA rules; do not invent proof.
Manual posting boundary
The process ends with selected editable text. The user still presses Reply, Post, or Comment manually.
Mobile surface status
Label whether the process is current mobile web, roadmap Android keyboard, roadmap iOS native flow, or browser fallback.
Procedure
Run the steps in order
Confirm Android demand
Segment mobile web sessions by Android and verify selected copied drafts are already happening.
Interview friction cases
Review users who liked the draft but disliked switching back to the social app.
Define keyboard boundary
Write the permission and posting boundary in plain language before any install prompt is tested.
Prototype selected insertion
Test selected editable draft insertion without implying hidden app reading or final posting control.
Keep copy fallback
Treat copy fallback as a valid completion path when keyboard insertion is constrained or confusing.
QA gates
What must pass before handoff
Specificity gate
The draft must include one detail from the source post or a clear reason it is asking for more context.
CTA pressure gate
Cold replies should usually have no CTA. Problem-aware replies can include one optional next step.
Proof gate
Remove unsupported statistics, testimonials, pricing, customer outcomes, review scores, store availability, or platform approval claims.
Manual approval gate
The operator must be able to point to the final human edit and manual platform action before the reply is published.
Fail conditions
What blocks the SOP
Auto-posting implication
Fail the SOP if copy says or implies TypeToSell clicks the final Reply, Post, Comment, or Publish button.
Hidden context assumption
Fail the SOP if it assumes a keyboard or extension can read private or unavailable social app content.
Unsupported availability
Fail the SOP if roadmap surfaces sound currently available in Google Play or the App Store without dated proof.
Guaranteed outcome claim
Fail the SOP if it promises replies, followers, leads, revenue, rankings, or platform safety guarantees.
Related execution pages
Connect this SOP to the rest of the system
Android keyboard workflow/workflows/android-replypilot-keyboard-workflowAndroid keyboard requirements/requirements/android-replypilot-keyboard-requirementsAndroid keyboard permission fix/fixes/android-keyboard-permission-anxiety-fixReplyPilot handoff templates/templates/replypilot-keyboard-handoff-templates
Quick answers
SOP questions
When is Android keyboard ready?
When Android mobile web users already select useful drafts and the remaining blocker is insertion friction.
What should the SOP say about permissions?
It should explain what the keyboard inserts, what it cannot read, and that final posting remains manual.
Is Android ReplyPilot Keyboard live?
No. This SOP is roadmap planning, not current Google Play availability.