Requests & Approvals
The form is the start. It is not the process.
Someone submits. Then the real work moves into inboxes, direct messages and a spreadsheet that tracks who has said yes. Eddy keeps the request, the decision and the fulfillment on one Map.
After submit, the request falls into the inbox
The form did its job. Now someone forwards it, someone else asks for context and the original attachment is three threads back.
Status lives with the person who remembered. The record, if it exists, is assembled later.
Collect, route, decide, complete
One Map holds the path. A request can branch — approve, send back, fulfill — without leaving the Session.
Collect
The requester submits once. What they entered stays attached as the work moves.
Route
The next Map Role sees the request with the previous context. They do not reconstruct it from email.
Decide
Approve, return or refuse on the stage where the decision belongs. The choice is part of the Session.
Complete
Fulfillment happens on the same path. The completed Session leaves one structured row.
The request and the decision stay together
Who asked, what they asked for, who decided, what they decided and whether it was fulfilled belong in one row. There is no second admin pass to paste the outcome into a tracker.
Eddy is not a form builder. It does not promise integrations, service levels or automated decisions that are not shipped.
Run one request that currently lives in email
Start with a purchase, an access request or an exception you already handle. Lay out the stages, the decision and the handoff as one Eddy Map.