Presupuestando: User stories

Presupuestando (budgeting in Spanish) is the name of my little project. It's aim be a site in which a user can request a budget (for example, reparations in the customer house, car or maybe travels), and the companies can interact presenting its budgets to the user.

At the beginning of the project i have compelled (from my mind) the following user stories:

Customer stories

• A customer request for a budget in its own words
• There is only a filter of budget type (Travelling, Housekeeping...) 
• The user can add a new type but the Prespuestando admin have to approve it (and find vendors to do it), so in this case the interactions finish at this point.
• The customer can be an existing customer or a new one, but the form would be the same for the two types
• The customer can fill an expected range of money for the budget or not
• The customer's location is detected and shown in the form. The user can edit this location (or drop it), the customer also can restrict the budget request to vendors in a specified perimeter from this point.
• The customer is notified when a vendor applies for a budget,  at this moment can request a change in the budget, approve the budget or discard it.

Vendor stories

• A vendor is notified when a customer request for a budget in one of his areas of interest 
• A vendor is registered and assigned to one or more budget types, one of the vendor's data will be its location
• The registration of a vendor is approved by the site admin.
• A budget is described in general and in lines, in a flexible and UX based interface (this story will be detailed prior its development)
• A vendor can request intervention details to the customer
• Vendor can save a budget in database
• Vendor can send a budget to the customer or discard it
• Vendor can change a applied budget if customer request it.

Admin stories 

• An admin fills the types of budgets
• And admin approves the registration of a vendor

Additional notes:

• At this moment is not determined the channel selected to the communication vendor-customer. The easy solution would be the email, but a twitter solution will be studied
• The admin stories has a very low priority to the web application. The admin can introduce the types by hand in database and vendor approves can be automatically approves (and disabled via Database if case of problems)